Export
L'export transforme ton modèle Mockomat en fichiers qui t'appartiennent. Il existe deux formats :
| Format | Ce que tu obtiens | Disponible sur |
|---|---|---|
| Spécification OpenAPI | Un fichier YAML OpenAPI 3.0.3 avec un schéma par table | Tous les forfaits avec compte |
| Paquet de code | Un ZIP avec un backend NestJS généré pour tes tables | Professional et au-delà |
Les paquets de code nécessitent au moins le rôle Éditeur et un accès en modification au projet. L'export ne modifie jamais ton projet, et le code généré n'a aucune dépendance d'exécution envers Mockomat.
Assistant d'export avec les étapes de format et d'options.
Lancer un export
Ouvre Export dans l'application. L'assistant d'export te guide en quatre étapes :
- Projet — choisis le projet à exporter.
- Format d'export — spécification OpenAPI ou paquet de code.
- Configurer l'export — pour un paquet de code, cette étape affiche le paquet que comprend ton forfait.
- Vérifier et exporter — confirme. Un fichier OpenAPI se télécharge immédiatement ; un paquet de code est généré en arrière-plan et apparaît avec un lien de téléchargement dès qu'il est prêt.
Si ton application ne propose pas encore de paquets de code, exporte en attendant la spécification OpenAPI.
Choix du format d'export : spécification OpenAPI ou paquet de code.
Spécification OpenAPI
L'export OpenAPI écrit ton modèle sous forme de components.schemas : un schéma par table, avec ses attributs comme propriétés, les attributs obligatoires, les valeurs d'enum et les relations. Il ne contient aucun chemin (paths). Utilise-le pour partager le modèle de données avec d'autres outils, ou comme point de départ d'un contrat que ton équipe backend implémente.
Paquet de code
Le paquet de code est un projet généré que tu peux exécuter, modifier et déployer toi-même.
| Paquet | Forfaits | Contenu |
|---|---|---|
| Pro | Professional, Business | Backend NestJS |
| Enterprise | Enterprise | Backend NestJS + frontend Angular |
Ce que contient le backend
- Une application NestJS avec une API GraphQL (code-first), un module par table : entité, resolver, service et types d'entrée/sortie.
- Par table : une requête de liste paginée avec recherche, une requête par ID et des mutations pour créer, mettre à jour, supprimer et restaurer des enregistrements.
- Des entités TypeORM pour MySQL / MariaDB.
- Authentification : connexion avec JWT et un module utilisateur. Au premier démarrage, le backend crée un utilisateur admin et affiche une seule fois son mot de passe dans la console.
- Un fichier Docker Compose qui démarre MySQL et Redis, et un README avec les étapes d'installation.
Le générateur actuel a des limites à connaître avant de planifier avec le code :
- Il cible MySQL / MariaDB et inclut toujours l'authentification et le fichier Docker Compose. Les choix de base de données et d'options dans l'assistant ne modifient pas encore le paquet.
- Les relations entre tes tables ne sont pas générées. Ajoute-les toi-même aux entités et services générés.
- Les colonnes générées acceptent des valeurs vides : l'indicateur Obligatoire d'un attribut n'est pas encore appliqué.
L'exécuter en local
Le README du paquet liste les étapes. En bref, dans le dossier du backend :
npm install
cp .env.example .env # puis renseigne les identifiants de ta base de données
npm run migration:run
npm run start:devLe backend attend une base de données MySQL ou MariaDB et Redis.
Vue d'ensemble de la structure du projet backend généré.
Avant d'exporter
Parcours d'abord la checklist de validation runtime. Un modèle propre produit un code plus propre :
- Les noms suivent tes conventions — les noms de tables et d'attributs deviennent des noms de classes, de types et de champs.
- Les types d'attributs sont justes — ils deviennent des types de colonnes et de champs GraphQL.
- Les attributs recherchables deviennent les champs de recherche de la requête de liste générée, et les attributs triables sont marqués comme colonnes de liste triables.
Les opérations et paramètres que tu as conçus dans l'API Design (en anglais) façonnent ton API mock ; le backend généré apporte ses propres requêtes et mutations standard par table.
Ce qu'il faut vérifier après l'export
Limites des modules et nommage
- Chaque module correspond-il à une table de ton modèle ?
- Les noms de modules, services et resolvers sont-ils cohérents et parlants ?
Entrées et validation
- Les entrées de création et de mise à jour contiennent-elles les champs attendus ?
- Ajoute une validation pour les champs que ton application exige — les champs générés sont optionnels.
Relations
- Ajoute les relations de ton modèle aux entités générées, avec la direction et la cardinalité que tu as conçues.
- Charge les enregistrements liés dans les services comme ton application en a besoin.
Checklist de revue de code après l'export.
Checklist de passation après l'export
- Attribuer la responsabilité par module — chaque module a besoin d'un responsable chargé de l'étendre.
- Signaler ce qui est généré — indique quels fichiers sont de l'échafaudage généré et lesquels demandent une logique métier propre.
- Consigner les lacunes connues — règles métier, intégrations externes et tâches d'arrière-plan ne sont pas générées.
- Committer une base — committe le code généré comme version initiale et crée tes branches à partir de là.
- Configurer les environnements — connexions aux bases de données, variables d'environnement et pipelines de déploiement.
- Tester tôt — le code généré compile, mais vérifie le comportement tôt avec des tests d'intégration.
Premier lancement local et checklist de vérification.
Propriété du code
Le code généré t'appartient : aucune dépendance d'exécution envers Mockomat, aucune redevance sur le résultat, aucune restriction d'usage commercial. Modifie-le, exécute-le sur tes propres serveurs ou chez n'importe quel hébergeur, et partage-le avec tes clients ou partenaires.