A technical deep-dive into AuraBoot's DSL engine — how declarative JSON maps to models, APIs, pages, permissions, and workflows.

How AuraBoot's DSL Engine Works

Most low-code platforms generate code or store configuration in a proprietary database. AuraBoot takes a different path: it uses a declarative DSL (Domain-Specific Language) that resolves at runtime into models, APIs, pages, permissions, and workflows. This article explains how.

The Core Idea: Configuration as Code

Every piece of business logic in AuraBoot is expressed as JSON. Models, fields, commands, pages, workflows, permissions, dictionaries, and i18n translations — all are declarative definitions that live in plugin directories and can be version-controlled with Git.

This isn't only a drag-and-drop abstraction. The DSL is meant to cover real business requirements while staying reviewable in Git:

{
  "code": "opportunity__close_won",
  "modelCode": "crm_opportunity",
  "actionType": "UPDATE",
  "triggerMode": "FORM",
  "permissionCode": "crm:opportunity:close",
  "confirmMessage": "$i18n:crm.opportunity.confirm_close",
  "businessValidation": {
    "rules": [
      { "field": "amount", "operator": "GT", "value": 0, "message": "Amount must be positive" }
    ]
  },
  "fieldDefaults": { "stage": "CLOSED_WON", "close_date": "${NOW}" },
  "sideEffects": [
    { "type": "CREATE", "targetModel": "crm_activity", "fieldMap": { "type": "DEAL_CLOSED" } }
  ]
}

This single command definition handles permission checking, user confirmation, business validation, field computation, record update, and side effect creation — all without writing imperative code.

The Six-Layer Model

AuraBoot's DSL operates across six layers, each building on the one below:

Layer 1: Data Model

Models define the structure of your business entities. Each model maps to a database table and includes metadata about soft delete, display fields, and tenant isolation.

Layer 2: Field Definitions

Fields go far beyond simple column definitions. Each field carries rendering hints (renderComponent), validation rules, dictionary bindings, reference relationships, JSONB virtual field mappings, and feature flags like rollUp for automatic aggregation.

Layer 3: Command Pipeline

Commands are the heart of AuraBoot. Instead of bare CRUD operations, every data mutation passes through a 20+ stage pipeline:

Permission Check
Request Parsing
Pre-Validation
Field Defaults
Business Validation
Computed Fields
Pre-Hooks
Data Mutation
Post-Hooks
Side Effects
Roll-Up Aggregation
Audit Logging
Event Publishing
Cache Invalidation
Notification
Webhook Dispatch

Each stage is configurable per-command through the DSL.

Layer 4: Page Schema

Pages are composed of blocks — tables, forms, detail views, stat cards, sub-tables, and custom components. The schema defines layout, field visibility, column order, filter configuration, and action buttons.

Layer 5: Workflow Integration

Commands can trigger BPMN workflows for approval processes, escalations, and multi-step operations. The workflow engine (SmartEngine) integrates natively with the command pipeline.

Layer 6: Plugin Composition

Plugins bundle all six layers into distributable packages. A CRM plugin, for example, includes models, fields, commands, pages, dictionaries, permissions, menus, roles, and i18n translations — everything needed for a complete feature set.

Runtime Compilation

When the platform boots, the DSL engine:

Scans plugin directories for JSON definitions
Validates each definition against JSON Schema
Resolves references between models, fields, commands, and pages
Creates database tables dynamically for new models
Registers REST endpoints automatically
Publishes permissions for RBAC enforcement
Compiles i18n keys through a three-layer resolution hierarchy

This process is idempotent — reimporting a plugin updates definitions without data loss.

Why DSL Beats Code Generation

Code generation seems appealing but has fundamental problems:

Drift: Generated code diverges from the model once developers edit it
Merge conflicts: Regenerating code creates massive diffs
Runtime changes: You can't modify generated code in production

AuraBoot's DSL avoids all three issues. The JSON definitions are the source of truth, interpreted at runtime. Changes are immediate, auditable, and reversible.

Expression Engine

The DSL includes an expression engine for dynamic values:

{
  "fieldDefaults": {
    "due_date": "${DATE_ADD(NOW, 30, 'DAY')}",
    "assigned_to": "${CURRENT_USER}",
    "total": "${SUM(items.amount)}"
  },
  "visibilityRules": {
    "discount_field": "${record.amount > 10000}"
  }
}

Expressions support arithmetic, date functions, conditional logic, aggregation, and context variables. They're evaluated server-side in the command pipeline and client-side in the form renderer.

Agent-Ready by Design

A unique advantage of the DSL approach is AI readiness. Because every model, field, command, and relationship is described in structured JSON, AI agents can understand your application without reverse-engineering code.

AuraBoot's AgentToolAutoGenerator reads model definitions and automatically creates tool bindings for AI agents. When you define a "Lead" model with a "status" field, AuraBot automatically knows how to:

List leads with filters
Create new leads with validation
Update lead status through the command pipeline
Query lead statistics

No additional integration work is needed. Every model you add to the DSL is immediately accessible to AI.

This is fundamentally different from traditional applications where AI integration requires building custom APIs, writing prompt templates, and manually mapping natural language to database operations.

Performance at Scale

A common concern with runtime interpretation is performance. AuraBoot addresses this through:

Schema caching: Compiled schemas are cached in Redis with invalidation on change
Named Queries: Pre-defined SQL queries with parameterized filters bypass dynamic query construction
Lazy loading: Page schemas load only the blocks visible in the current viewport
Connection pooling: HikariCP with optimized pool sizes per tenant

In production, AuraBoot handles thousands of concurrent users with sub-100ms response times for standard CRUD operations.

Conclusion

AuraBoot's DSL engine represents a shift from "generate code" to "interpret configuration." By keeping business logic declarative, version-controllable, and runtime-interpretable, it eliminates the boilerplate that makes enterprise development slow while maintaining the flexibility that makes it necessary.

The DSL approach represents a fundamental bet: that enterprise business logic is better expressed as data than as code. After building production applications with this engine — CRM, ERP, project management, manufacturing — the bet is paying off. Applications that took months now take days, and changes that required developers now require configuration updates.

Explore the DSL engine in our documentation or try building your first model with our quick start guide.