How to Implement CQRS and High-Performance APIs Without Writing Controllers

From Database to API in 1 Line: Zero Complexity, Maximum Performance.

By Cesar Romero

If you develop corporate backends today, you probably suffer from “Boilerplate Fatigue”. To create a simple CRUD for a Customers table, modern architecture forces us to create a procession of files: a Controller, a DTO, a Service, a Repository, a Validator, and finally, the Entity.

Multiply this by 50 tables and you have weeks of repetitive work that adds no real value to the business.

What if I told you it is possible to have clean architecture, security, and superior performance compared to manual coding, by writing just one line of code?

Welcome to Database as API by Dext.

Zero Complexity

Dext removes the bureaucracy from API development. It understands that, most of the time, you just want to expose your data securely and in a standard way, without having to “ask for permission” from five architectural layers.

See how we define an entity in Dext. It’s pure Delphi code, clean and strongly typed:

type
  [Table('customers')]
  TCustomer = class(TEntity)
  private
    FId: Integer;
    FName: string;
    FEmail: string;
    FActive: Boolean;
  public
    [PK, AutoInc]
    property Id: Integer read FId write FId;

    [Column('name'), Required, MaxLength(100)]
    property Name: string read FName write FName;

    [Column('email'), MaxLength(255)]
    property Email: string read FEmail write FEmail;

    [Column('active')]
    property Active: Boolean read FActive write FActive;
  end;

Traditionally, you would now start writing the CustomerController. In Dext, you go straight to Startup and do this:

// Maps the TCustomer entity to a full REST API
TDataApiHandler<TCustomer>.Map(ABuilder, '/api/customers', FDbContext);

Done. Dext sets up endpoints for GET, POST, PUT, and DELETE, with HTTP status handling, JSON serialization, and parameter binding. No fuss, no extra files.

Maximum Performance with Implicit CQRS

Here is where we separate “simple code generators” from software engineering tools.

Many frameworks try to facilitate CRUD using heavy Reflection that instantiates objects, copies properties, and then serializes. This kills performance. Others do a direct dump from the database, exposing ugly column names or sensitive data.

Dext adopts an Implicit CQRS (Command Query Responsibility Segregation) approach with total respect for your Mapping:

1. Read Pipeline (GET): Direct-to-JSON Streaming When you call GET /api/customers, Dext creates an optimized pipeline between the IDbReader (database) and the Response.Body (Network). Memory consumption is near zero.
2. The Mapping is Sovereign Even in high-performance mode, Dext respects your mapping attributes.

• Have a [JsonIgnore] attribute? The field won’t go to the JSON.
• Have a Naming strategy configured (e.g., camelCase)? Dext applies key/value transformations at streaming time, ensuring your API contract is respected without sacrificing speed.

3. Write Pipeline (POST/PUT): Domain Safety On writing, security is paramount. Dext receives the JSON, hydrates the TCustomer entity, runs domain validations, and persists via DbContext.

You gain the performance of a Micro-ORM on reads and the safety of an Enterprise ORM on writes.

An API that Speaks the Front-end Language

Another common problem is the “Backend for Frontend” (BFF). The Front-end asks for an endpoint to filter by name. Then another to filter by status. Then another with pagination.

Database as API delivers a native Queryable API. Without writing any extra line of code, your /api/customers endpoint already supports dynamic filters via query string:

• Filters: /api/customers?active=true&name=John
• Pagination: /api/customers?_limit=10&_offset=20
• Selection: Dext translates URL parameters into optimized SQL queries automatically.

But What About Security?

“Exposing the database is dangerous!”, skeptics would say. And they would be right, if Dext hadn’t been designed with Security-First.

Although the basic example is open to facilitate learning, in production you shield your API with RBAC (Role-Based Access Control) in a fluent line:

TDataApiHandler<TCustomer>.Map(App, '/api/customers', FDbContext,
  TDataApiOptions<TCustomer>.Create
    .RequireReadRole('User,Admin')   // Broad reading: Viewer, User or Admin
    .RequireWriteRole('Editor,Admin') // Restricted writing: Editor or Admin
);

Conclusion

Dext is not just making API creation easier; it is giving the developer back the ability to focus on what matters.

It eliminates accidental complexity (repetitive controllers, mirror DTOs) and keeps what is essential: your Business Rules, your Mapping, and your Security.

If you want the performance of an optimized architecture without the complexity of verbose frameworks, Dext is your new working tool.

---

Liked it? Download the complete DatabaseAsApi.dpr example in the official repository and see the magic happen. https://github.com/cesarliws/dext