Export
L'export fait le pont entre l'intention du modèle et l'implémentation backend dont tu es propriétaire. Il prend ton projet Mockomat validé et génère un backend NestJS prêt pour la production que tu possèdes entièrement — aucune dépendance runtime envers Mockomat, aucun verrouillage fournisseur.
Le code généré est le vôtre. Tu peux le modifier, l'étendre, le déployer et le commercialiser sans restrictions.
Objectifs de l'export
L'export devrait produire un backend de démarrage qui est :
- Lisible — code propre et bien structuré suivant les conventions et bonnes pratiques NestJS.
- Structuré — organisé par modules de domaine avec une séparation claire des responsabilités.
- Traçable — chaque module, entité et resolver généré correspond à ton modèle Mockomat.
- Prêt pour l'ownership d'équipe — qualité de code sur laquelle une équipe de développement peut immédiatement s'appuyer.
L'objectif n'est pas de remplacer le développement backend — c'est d'éliminer la phase de scaffolding répétitive et de permettre à ton équipe de se concentrer sur la logique métier dès le premier jour.
Panneau de configuration d'export avec options cibles.
Sources d'entrée
L'export peut générer un backend à partir de deux sources :
Projet natif Mockomat
Utilise les métadonnées de ton projet existant — toutes les entités, attributs, relations, associations et configurations API sont utilisées comme entrée de génération. C'est le chemin recommandé pour la plupart des utilisateurs.
Import OpenAPI
Télécharge une spécification OpenAPI (JSON ou YAML) et génère un backend directement à partir de la spec. Utile lorsque tu as déjà un contrat API défini en dehors de Mockomat et souhaites générer l'implémentation.
Sélection de source d'export : projet Mockomat ou import OpenAPI.
Options d'export
Lors du démarrage d'un export, tu configures plusieurs options qui déterminent la forme du backend généré :
Style d'API
| Option | Description |
|---|---|
| GraphQL (code-first) | Génère des resolvers, types d'objets et types d'entrée avec les décorateurs GraphQL NestJS. |
| REST (basé OpenAPI) | Génère des controllers avec des décorateurs de routes et des annotations Swagger. |
| Les deux | Génère à la fois des resolvers GraphQL et des controllers REST pour les mêmes modèles de domaine. |
Couche de persistance
| Option | Description |
|---|---|
| TypeORM (SQL) | Génère des entités avec des décorateurs TypeORM ciblant les bases de données relationnelles (PostgreSQL, MySQL, MariaDB). |
| Mongoose (MongoDB) | Génère des schémas et modèles pour MongoDB via Mongoose. |
| En mémoire | Génère des stores en mémoire simples pour un prototypage rapide sans configuration de base de données. |
Scaffolding d'authentification
Le projet généré inclut un scaffolding d'authentification JWT optionnel :
- Un stub d'entité
Userbasique - Configuration du guard JWT
- Décorateurs d'endpoints protégés
- Stubs d'endpoints de login et d'inscription
Ce scaffolding fournit un point de départ — tu remplaces les stubs par ta logique d'authentification réelle.
Ce qui est généré
L'export produit un projet NestJS complet et exécutable :
/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.mdCe que contient chaque fichier
| Fichier | Objectif |
|---|---|
| Entity | Définition du schéma de base de données avec décorateurs (TypeORM ou Mongoose) |
| Service | Couche de logique métier avec opérations CRUD et gestion des relations |
| Controller/Resolver | Couche API exposant les endpoints avec validation des entrées |
| DTOs | Objets de transfert de données avec décorateurs class-validator pour la validation des entrées |
| Module | Module NestJS reliant le service, le controller et l'entité |
| Common | Filtres, interceptors et pipes partagés utilisés entre modules |
Flux d'export typique
1. Valider le modèle et la disponibilité runtime
Avant d'exporter, parcours la liste de contrôle de validation runtime. Confirme que :
- Toutes les entités ont des associations d'attributs complètes.
- Les relations se résolvent correctement en prévisualisation.
- Les opérations de filtrage et de tri fonctionnent comme attendu.
- Aucune indication non résolue ne subsiste.
Un passage de validation runtime propre augmente significativement la qualité du code généré.
2. Choisir les options d'export
Sélectionne ton style d'API, couche de persistance et préférences d'authentification. En cas de doute, commence par GraphQL + TypeORM — c'est la configuration la plus courante pour les backends NestJS.
3. Générer le package
Clique sur générer et attends que le projet backend soit construit. Le processus de génération lit ta configuration de modèle complète et produit tous les fichiers en un seul passage.
4. Télécharger et exécuter localement
Le projet généré est livré sous forme de fichier .zip. Extraye-le et exécute :
npm install
npm run start:devLe backend démarre sur un port local avec le hot reload activé. Tu peux immédiatement tester l'API avec ton client GraphQL ou outil REST préféré.
5. Transférer à l'équipe d'implémentation
Le projet généré est un point de départ, pas un produit fini. Transfère-le à ton équipe de développement avec un contexte clair sur :
- Ce qui a été généré et pourquoi
- Quelles parties sont prêtes pour la production
- Quelles parties nécessitent une implémentation personnalisée
Aperçu de la structure du projet backend généré.
Ce qu'il faut vérifier après l'export
Après la génération de ton backend, vérifie ces domaines avant de construire dessus :
Limites de modules et nommage
- Chaque module correspond-il à une entité de domaine de ton modèle Mockomat ?
- Les noms de modules, services et controllers sont-ils cohérents et significatifs ?
- L'organisation des fichiers correspond-elle aux conventions de ton équipe ?
Couverture DTOs et validation
- Les DTOs incluent-ils tous les champs obligatoires ?
- Les décorateurs class-validator sont-ils correctement appliqués (ex.
@IsString(),@IsNumber(),@IsOptional()) ? - Les DTOs de création et de mise à jour diffèrent-ils de manière appropriée ?
Structure resolver/controller
- Tous les endpoints prévus sont-ils générés ?
- Les chemins de routes ou noms de requêtes correspondent-ils à ta conception API ?
- Les guards et décorateurs sont-ils correctement appliqués ?
Gestion des relations
- Les relations d'entités sont-elles définies avec les décorateurs corrects (
@OneToMany,@ManyToOne,@ManyToMany) ? - La couche service gère-t-elle le chargement des relations (eager vs lazy) ?
- Les options de cascade sont-elles configurées de manière appropriée ?
Vue de liste de contrôle de revue de code post-export.
Liste de contrôle de transfert post-export
Utilise cette liste lors du transfert du projet généré à ton équipe d'implémentation :
- Assigner la responsabilité par module/domaine — chaque module devrait avoir un responsable clair chargé de l'étendre.
- Définir ce qui reste généré vs personnalisé — marquer quels fichiers sont du scaffolding généré et lesquels nécessitent une logique métier personnalisée.
- Capturer les lacunes connues — documenter les fonctionnalités que Mockomat ne génère pas (règles métier complexes, intégrations externes, jobs en arrière-plan).
- Mettre en place le contrôle de version — commiter le code généré comme ta baseline initiale et brancher à partir de là.
- Configurer les environnements — mettre en place les connexions de base de données, variables d'environnement et pipelines de déploiement.
- Exécuter la suite de tests complète — même si le code généré compile, vérifie le comportement tôt avec des tests d'intégration.
Premier démarrage local et liste de contrôle de vérification.
Propriété du code
Le code généré t'appartient à 100%. Il n'y a aucune dépendance runtime envers Mockomat, aucun frais de licence sur la sortie générée et aucune restriction sur l'utilisation commerciale. Tu peux :
- Modifier chaque ligne du code généré
- Déployer sur n'importe quelle infrastructure (AWS, GCP, Azure, on-premise)
- Utiliser dans des produits commerciaux sans attribution
- Partager avec des clients, partenaires ou communautés open-source
Le projet généré est une application NestJS standard. Tout développeur NestJS peut l'étendre immédiatement.