Export

Export bridges model intent and owned backend implementation. It takes your validated Mockomat project and generates a production-ready NestJS backend that you fully own — no runtime dependency on Mockomat, no vendor lock-in.

The generated code is yours. You can modify, extend, deploy, and commercialize it without restrictions.

Export Goals

Export should produce a starter backend that is:

• Readable — clean, well-structured code that follows NestJS conventions and best practices.
• Structured — organized by domain modules with clear separation of concerns.
• Traceable — every generated module, entity, and resolver maps back to your Mockomat model.
• Ready for team ownership — code quality that a development team can immediately build upon.

The goal is not to replace backend development — it is to eliminate the repetitive scaffolding phase and let your team focus on business logic from day one.

ex-01-export-configMissing

Export configuration panel with target options.

Input Sources

Export can generate a backend from two sources:

Mockomat Native Project

Use your existing project metadata — all entities, attributes, relations, mappings, and API configurations are used as the generation input. This is the recommended path for most users.

OpenAPI Import

Upload an OpenAPI specification (JSON or YAML) and generate a backend directly from the spec. This is useful when you already have an API contract defined outside of Mockomat and want to generate the implementation.

ex-01b-input-sourcesMissing

Export source selection: Mockomat project or OpenAPI import.

Export Options

When starting an export, you configure several options that determine the shape of the generated backend:

API Style

Option	Description
GraphQL (code-first)	Generates resolvers, object types, and input types using NestJS GraphQL decorators.
REST (OpenAPI-based)	Generates controllers with route decorators and Swagger annotations.
Both	Generates both GraphQL resolvers and REST controllers for the same domain models.

Persistence Layer

Option	Description
TypeORM (SQL)	Generates entities with TypeORM decorators targeting relational databases (PostgreSQL, MySQL, MariaDB).
Mongoose (MongoDB)	Generates schemas and models for MongoDB via Mongoose.
In-memory	Generates simple in-memory stores for quick prototyping without database setup.

Authentication Scaffolding

The generated project includes optional JWT authentication scaffolding:

• A basic User entity stub
• JWT guard configuration
• Protected endpoint decorators
• Login and registration endpoint stubs

This scaffolding provides a starting point — you replace the stubs with your actual authentication logic.

What Gets Generated

The export produces a complete, runnable NestJS project:

/nestjs-backend
  /src
    /modules
      /customer
        customer.module.ts
        customer.controller.ts    (REST) or customer.resolver.ts (GraphQL)
        customer.service.ts
        customer.entity.ts
        /dto
          create-customer.dto.ts
          update-customer.dto.ts
      /order
        order.module.ts
        order.controller.ts
        order.service.ts
        order.entity.ts
        /dto
          create-order.dto.ts
          update-order.dto.ts
    /common
      /filters
      /interceptors
      /pipes
    app.module.ts
    main.ts
  package.json
  tsconfig.json
  README.md

What Each File Contains

File	Purpose
Entity	Database schema definition with decorators (TypeORM or Mongoose)
Service	Business logic layer with CRUD operations and relation handling
Controller/Resolver	API layer exposing endpoints with input validation
DTOs	Data transfer objects with class-validator decorators for input validation
Module	NestJS module wiring together the service, controller, and entity
Common	Shared filters, interceptors, and pipes used across modules

Typical Export Flow

1. Validate Model and Runtime Readiness

Before exporting, run through the runtime validation checklist. Confirm that:

• All entities have complete attribute mappings.
• Relations resolve correctly in preview.
• Filter and sort operations work as expected.
• No unresolved hints remain.

A clean runtime validation pass dramatically increases the quality of generated code.

2. Choose Export Options

Select your API style, persistence layer, and authentication preferences. If you are unsure, start with GraphQL + TypeORM — this is the most common configuration for NestJS backends.

3. Generate the Package

Click generate and wait for the backend project to be built. The generation process reads your full model configuration and produces all files in a single pass.

4. Download and Run Locally

The generated project is delivered as a .zip file. Extract it and run:

npm install
npm run start:dev

The backend starts on a local port with hot reload enabled. You can immediately test the API using your preferred GraphQL client or REST tool.

5. Hand Over to Implementation Team

The generated project is a starting point, not a finished product. Hand it to your development team with clear context about:

• What was generated and why
• Which parts are ready for production
• Which parts need custom implementation

ex-02-generated-structureMissing

Generated backend project structure overview.

What to Review After Export

After generating your backend, review these areas before building on top of it:

Module Boundaries and Naming

• Does each module correspond to a domain entity from your Mockomat model?
• Are the module, service, and controller names consistent and meaningful?
• Does the file organization match your team's conventions?

DTO and Validation Coverage

• Do the DTOs include all required fields?
• Are class-validator decorators applied correctly (e.g., @IsString(), @IsNumber(), @IsOptional())?
• Do create and update DTOs differ appropriately (create requires all fields, update allows partial)?

Resolver/Controller Structure

• Are all intended endpoints generated?
• Do the route paths or query names match your API design?
• Are guards and decorators applied correctly?

Relation Handling

• Are entity relations defined with the correct decorators (@OneToMany, @ManyToOne, @ManyToMany)?
• Does the service layer handle relation loading (eager vs lazy)?
• Are cascading options configured appropriately?

ex-02b-code-reviewMissing

Post-export code review checklist view.

Post-Export Handoff Checklist

Use this checklist when handing the generated project to your implementation team:

• Assign ownership by module/domain — each module should have a clear owner responsible for extending it.
• Define what remains generated vs custom — mark which files are generated scaffolding and which need custom business logic.
• Capture known gaps — document features that Mockomat does not generate (complex business rules, external integrations, background jobs).
• Set up version control — commit the generated code as your initial baseline and branch from there.
• Configure environments — set up database connections, environment variables, and deployment pipelines.
• Run the full test suite — even though generated code compiles, verify behavior with integration tests early.

ex-03-post-export-runMissing

First local run and verification checklist.

Code Ownership

Generated code is 100% owned by you. There is no runtime dependency on Mockomat, no license fees on the generated output, and no restrictions on commercial use. You can:

• Modify every line of the generated code
• Deploy to any infrastructure (AWS, GCP, Azure, on-premise)
• Use in commercial products without attribution
• Share with clients, partners, or open-source communities

The generated project is a standard NestJS application. Any NestJS developer can extend it immediately.

Paid user tip

Paid User

Use export at stable milestones, not after every minor change. This keeps code reviews focused and reduces churn. A good cadence is to export after major domain changes, not after individual attribute tweaks.

Enterprise tip

Enterprise User

Treat export artifacts as governed deliverables. Attach release notes and decision context for auditability. Include the Mockomat project version and a summary of model changes since the last export in your release documentation.

Integrator deployment note

Developer / Integrator

The generated backend follows standard NestJS patterns and deploys to any Node.js hosting environment. For containerized deployments, add a Dockerfile and adjust the main.ts configuration for your target platform. No Mockomat-specific runtime or SDK is required.