TotalApp Docs
Ctrl K
Home
EN | TR
Go to App

DSL Compiler

Write a small entity/relation DSL and deterministically generate SQL/Prisma/Mongoose schemas, TypeScript DTOs, an API controller, and Zod validation schemas.

Overview

DSL Compiler is a code-generation tool for backend API scaffolding. Define your data model with a small, purpose-built DSL — entities with typed fields and decorators, plus relations with cardinality — and the compiler deterministically generates a full backend contract for a chosen database and API framework: SQL DDL (or Prisma/Mongoose schemas), TypeScript DTOs (create/update/read), an API controller or router, and Zod validation schemas.

Compilation is deterministic, not AI-generated — the same DSL input always produces the same output for a given target. This makes DSL Compiler suitable for quickly bootstrapping consistent, typed backend code from a single source of truth.

Writing the DSL

An entity block declares fields with a type and optional decorators:

Example

entity User { id: uuid, email: string @unique, name: string, status: Enum(active, passive), createdAt: timestamp } relation User -> Post [1:N]

Supported field types: uuid, string, text, boolean, timestamp, integer, float, json, and Enum(value1, value2, ...). Supported decorators: @unique and @fk (foreign key). Relations use relation From -> To [cardinality], where cardinality is 1:N or N:M.

Compile Targets

Choose a database and API framework from the target dropdown in the toolbar before compiling:

CategoryOptions
DatabasePostgreSQL, MySQL, MongoDB, Prisma
API FrameworkNestJS, Express, Fastify

MongoDB targets generate Mongoose schemas instead of SQL DDL; Prisma targets generate a Prisma schema file instead of raw SQL. Both still produce matching TypeScript DTOs, a controller/router for the selected API framework, and Zod schemas.

Output Tabs

After compiling, the right panel shows five tabs:

  • Schema — the parsed entity/relation tree with field counts, plus a compile status banner
  • SQL / Prisma / Mongoose — the generated database schema for the selected target
  • TypeScript DTO — read, create, and update DTOs per entity
  • Controller / Router / Plugin — REST endpoints (GET/POST/PATCH/DELETE) for the selected API framework
  • Zod — runtime validation schemas, target-independent

Each code tab has a Copy button in the top-right corner. Changing the compile target clears the previous output and requires recompiling.

AI Assistant

Open the built-in AI Assistant from the tab on the right edge of the screen to get help with your schema. It has context on your live DSL source, the parsed entities/fields/relations, any parse errors, and your current compile target, so you can ask things like:

  • "Help me fix the parse error in my DSL"
  • "Review my schema for design issues"
  • "What will the generated output for this target contain?"
  • "What field type and decorators should I use for this?"

The assistant never invents entities or fields that aren't in your current DSL — it always grounds suggestions in the actual schema shown in the Schema tab. Replies you want to keep can be saved as a report with one click from the panel's bottom dock.

Frequently Asked Questions

Does DSL Compiler write to a real database?
No. Compilation is entirely local and produces text output (SQL, Prisma schema, TypeScript, Zod) that you copy into your own codebase or migration tooling. Nothing is executed against a live database.
What happens if my DSL has a syntax error?
The Schema tab shows a compile error banner listing what went wrong (e.g. "No valid entity definitions found"). Compilation of output tabs is skipped until the DSL parses cleanly — fix the syntax and click Compile again.
Can I switch targets without rewriting my DSL?
Yes — the DSL source is target-independent. Change the database or API framework in the target dropdown and recompile; the same entity/relation definitions regenerate correct output for the new target.
What does the @fk decorator do?
It marks a field as a foreign key reference, inferring the referenced table from the field name (e.g. authorId references the authors table). For SQL targets this generates an ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY statement.
How is an N:M relation represented in SQL?
As a junction table named {entityA}_{entityB} with a composite primary key of both foreign keys, each with ON DELETE CASCADE. MongoDB and Prisma targets do not generate a junction table since both handle many-to-many relations natively.