The core idea behind CMMV is using contracts as the foundation of the application. Nowadays, modern communication formats like REST, GraphQL, and WebSocket follow a similar pattern: when you're exposing data, you need to keep things consistent — otherwise, any change can break the consumers. This becomes even more critical when other systems rely on your API. The market got used to JSON because it’s easy to use and implement in pretty much any language, but that doesn’t mean it’s ideal for everything.

If you’ve ever worked with strongly typed languages like C++ or C#, you know dealing with JSON is a pain. Too dynamic, validation is messy, conversions are manual, and in the end, things turn into chaos. That’s why systems that use well-defined contracts aren’t anything new. SOAP did that long ago with WSDL. Protobuf works the same way — it’s widely used in microservices with RPC for a reason. The idea is simple: you define the data in a clear, typed, structured way, and from there, everything needed for communication can be generated — in any language.

So what does that mean in practice? It means that instead of writing fetch, manually handling responses, headers, authentication, data transformation, etc., the contract handles all of that for you. In CMMV, you define the contract and that’s it — the system knows exactly what to send, what to receive, how to validate, transform, authenticate, and process everything. You only implement the specific logic you actually need. Everything else comes built-in.

On the frontend, this becomes a simple function call that gives you the data — no fetch, no axios, no manual parsing or validation. On the backend, you don’t need to create controllers, DTOs, services… nothing. The contract defines it all. You just plug in what needs custom behavior.

This cuts development time massively, reduces repetitive code, and guarantees that everything works the right way from the start. It’s real productivity, strong typing, and end-to-end communication — no hacks, no boilerplate, and no need to reinvent the wheel.

At a basic level, the CMMV contract works like a schema-first setup, similar to GraphQL. You define the structure, and optionally define specific resolvers when needed. But the CMMV contract goes much further. It already integrates data validation using class-validator, automatic transformation with class-transformer, and the core system generates interfaces, DTOs, and fast-json-stringify schemas by default. These schemas become the foundation for everything else that runs through the modules.

And this is where one of the strongest parts of the architecture comes in: each module can have one or more transpilers. These are pieces of code that read the project’s contracts and generate whatever is necessary for that module to work. For example, in the GraphQL module, it automatically generates resolvers, queries, mutations, types — so the API is already functional without you needing to write a single line of code beyond the contract.

Of course, for more complex scenarios, you’ll still need to implement parts of the logic manually. But for basic CRUD, import/export, access control, pagination, search filters — all of that comes out of the box, fully generated, and best of all: it respects everything defined in the contract, including validation, authentication, and field exposure rules.

At the end of the day, CMMV gives you an insanely productive starting point. You don’t waste time writing the same controller, DTO, or validator over and over. Everything is born from a single definition. Write the contract, and focus only on what really matters.

Transpilers and Modules

One of the key parts of the CMMV architecture is the concept of transpilers and modules. This is where the real magic happens. Once the contracts are defined, the transpilers step in to automatically generate the necessary code for each part of your application.

In CMMV, a module represents a specific functionality — like REST, GraphQL, Protobuf, WebSocket, SSR, database integration, and more. Each module can have one or more transpilers responsible for reading the project contracts and generating the exact code needed to make that module work seamlessly with the rest of the system.

For example, in the GraphQL module, transpilers automatically generate:

resolvers,
type definitions (typeDefs),
queries and mutations,
and base controllers for standard operations like CRUD.

All of that is built based on the contract you wrote — no need to write anything extra.

In the REST module, transpilers generate:

HTTP controllers,
fully validated endpoints,
route definitions,
and serialization schemas optimized with fast-json-stringify.

In the database module (MongoDB, SQLite, PostgreSQL, etc.), transpilers generate:

ORM or ODM schemas,
migrations,
and even commands to seed or transform data based on the contract.

On top of that, transpilers are also used to generate TypeScript interfaces for the frontend, RPC mixins, client-side validation, and any other kind of code that needs to stay in sync with the backend — all coming from the same centralized contract.

The best part: transpilers are fully modular and extensible. You can build your own transpilers to generate custom code tailored to your project’s needs. This gives you a huge amount of flexibility without breaking the core structure of the CMMV system.

At the end of the day, the formula is simple:
contract + module + transpiler = everything working without boilerplate.

If you’d like, I can follow this up with a practical example of how to create a custom module and plug your own transpiler into the system. Want to go down that path?

Contracts as the Core of the Application