Workspace

Le workspace est l'endroit où les décisions de domaine, d'API et de runtime restent connectées dans un flux opérationnel unique. C'est l'environnement central dans lequel tu crées, configures, valides et itères sur ton projet d'API mock.

Cette page guide à travers chaque zone importante du workspace et explique ce que chacune fait, comment l'utiliser efficacement et ce à quoi faire attention.

Zones du workspace

Le workspace est divisé en différentes zones, chacune focalisée sur une partie spécifique du workflow de modélisation et de conception d'API. Tu peux basculer entre ces zones à tout moment — les modifications dans une zone sont immédiatement reflétées dans les autres.

1. Contexte projet et navigation

Le contexte de workspace de niveau supérieur contrôle le projet sur lequel tu travailles et comment tu navigues entre les différentes vues.

Ce que tu peux faire

• Changer de projet actif — si tu as plusieurs projets, le sélecteur de projet te permet de changer de contexte sans perdre ta position.
• Maintenir le contexte de modélisation stable — le workspace se souvient de la table, vue ou panneau de configuration que tu avais ouvert.
• Basculer entre les vues — navigue entre le board de modélisation, l'éditeur de tables, la conception API et la prévisualisation runtime.

Paramètres du projet

Chaque projet a un slug unique qui détermine l'URL de son endpoint API :

POST /mock/{slug}/graphql

Le slug est automatiquement généré à partir du nom de ton projet, mais peut être personnalisé. Garde les slugs courts, en minuscules et avec des tirets (ex. customer-portal, ecommerce-demo).

ws-01-project-switcherMissing

Barre de contexte projet et changement de vue.

2. Board de modélisation

Le board de modélisation est la zone de conception structurelle — un canevas visuel où tu crées et organises tes entités de domaine et leurs connexions.

Travailler avec les tables

Le board affiche chaque entité comme une carte de table. Tu peux :

• Créer de nouvelles tables — ajouter des entités représentant des concepts métier (ex. Product, Customer, Order).
• Positionner les tables — glisser-déposer les cartes de table pour les disposer spatialement. Grouper les entités liées pour plus de clarté visuelle.
• Éditer les propriétés des tables — renommer les tables, configurer les options d'affichage et gérer les métadonnées.
• Supprimer des tables — retirer les entités devenues inutiles.

Lignes de relations visuelles

Les relations entre tables sont représentées par des lignes visuelles connectant les entités liées. Les lignes indiquent :

• Direction — quelle entité possède la relation (direction de la flèche).
• Cardinalité — le type de relation (1:1, 1:n, m:n) représenté par des annotations de ligne.
• Points de connexion — quelles colonnes sont impliquées dans la relation.

Cette représentation visuelle facilite la vérification de ta structure de domaine en un coup d'oeil et la détection de relations manquantes ou incorrectes.

Contrôles du board

• Zoom et panoramique — navigue dans les grands boards avec le zoom à la molette et le glisser pour panoramiquer.
• Accrochage à la grille — alignement optionnel à la grille pour des positions ordonnées.
• Mise en page automatique — dispose automatiquement les tables pour une lisibilité optimale.

ws-02-modelling-boardMissing

Board de modélisation avec entités de domaine connectées.

Limites du board

Free User

Les utilisateurs free et invités ont un accès complet au board de modélisation. La complexité du board est limitée uniquement par le nombre de projets autorisés par ton forfait, pas par le nombre de tables au sein d'un projet.

3. Configuration des tables et attributs

Lorsque tu sélectionnes une table sur le board de modélisation, le panneau d'éditeur de table s'ouvre avec des options de configuration détaillées pour l'entité et ses attributs.

Propriétés de la table

Chaque table devrait avoir :

• Un nom clair — utilise des noms singuliers correspondant à ton vocabulaire métier (Invoice, pas invoices_table).
• Une description — optionnelle mais utile pour la communication d'équipe et la documentation.

Configuration des attributs

Pour chaque attribut (colonne), tu configures :

Propriété	Description	Impact
Nom	L'identifiant du champ	Devient le nom de champ GraphQL
Type	string, number, boolean, date, json	Détermine les opérateurs de filtre et la validation
Obligatoire	Si le champ doit avoir une valeur	Affecte la nullabilité GraphQL
Triable	Si le champ supporte les opérations de tri	Active le paramètre sort dans les requêtes
Recherchable	Si le champ participe à la recherche	Inclus dans la résolution des requêtes de recherche
Filtrable	Si le champ supporte les expressions de filtre	Active le paramètre filter dans les requêtes
Association	Source de données : OFF_FIELD, FAKE ou CONST	Détermine quelles données le champ retourne

Conventions de nommage

Un nommage cohérent rend ton modèle lisible et ton code généré prévisible :

• Attributs — utilise camelCase (ex. firstName, totalAmount, isActive)
• Tables — utilise PascalCase singulier (ex. Customer, OrderItem)
• Évite les abréviations — description est mieux que desc, quantity est mieux que qty

Sélection d'objet de données

Lors de l'association d'un attribut à un champ de jeu de données réel (OFF_FIELD), un panneau latéral s'ouvre avec :

• Recherche — trouver des objets de données par nom ou tag
• Filtres par tags — affiner les résultats par catégorie
• Aperçu d'exemples — voir des valeurs d'exemple avant de valider une association

Cela garantit que tu choisis la bonne source de données pour chaque attribut.

ws-03-table-editorMissing

Éditeur de table avec panneau de configuration des attributs.

ws-03b-data-object-selectorMissing

Panneau de sélection d'objet de données avec recherche et aperçu.

4. Définition des relations

Les relations connectent tes entités et définissent comment les données circulent entre elles. Configurer correctement les relations est crucial — elles déterminent comment les requêtes imbriquées sont résolues au runtime.

Types de relations

Type	Exemple	Signification
Un-à-un (1:1)	User → Profile	Chaque utilisateur a exactement un profil
Un-à-plusieurs (1:n)	Customer → Order[]	Chaque client a plusieurs commandes
Plusieurs-à-plusieurs (m:n)	Product ↔ Category	Les produits appartiennent à plusieurs catégories et vice versa

Liste de contrôle qualité

Avant de finaliser une relation, pose ces questions :

• Propriété ou référence ? — Cette relation représente-t-elle une propriété réelle (un client possède ses commandes) ou une référence (une commande référence un mode de paiement) ?
• Clarté directionnelle — Est-il évident quelle entité est le parent et laquelle est l'enfant ?
• Comportement de résolution — Lors de l'interrogation du parent, les données enfants doivent-elles être incluses par défaut ? Et dans la direction inverse ?
• Exactitude de la cardinalité — Est-ce vraiment du 1:n, ou pourrait-ce devenir du m:n à l'avenir ?

Comment les relations affectent le runtime

Au runtime, les relations déterminent comment le moteur de requêtes assemble les données imbriquées. Lorsque tu interroges :

query {
  customers(limit: 5) {
    id
    name
    orders {
      id
      totalAmount
    }
  }
}

Le runtime utilise la définition de relation pour rechercher les enregistrements Order associés à chaque Customer. Si la relation est mal configurée (mauvaise direction, référence de clé étrangère manquante), les données imbriquées seront vides ou incorrectes.

ws-04-relation-editorMissing

Configuration de relation et cardinalité.

5. Intégration de la conception API

La zone de conception API te permet de contrôler comment ton modèle de domaine est exposé en tant qu'API GraphQL. Toutes les entités ou opérations n'ont pas besoin d'être publiques — la vue de conception API t'aide à n'exposer que ce qui est pertinent pour la phase actuelle.

Nommage des requêtes

Mockomat génère automatiquement les noms de requêtes à partir de tes noms d'entités, mais tu peux les personnaliser :

• Requête de liste — par défaut la forme plurielle (ex. products, customers)
• Requête de détail — par défaut la forme singulière (ex. product, customer)

Choisis des noms qui correspondent à la façon dont ton équipe frontend pense aux données. Le nom de requête devient le point d'entrée dans chaque requête GraphQL.

Exposition des opérations

Tu contrôles quelles opérations sont disponibles :

• Activer/désactiver les requêtes de liste — décider si les consommateurs peuvent récupérer des collections.
• Activer/désactiver les requêtes de détail — décider si les consommateurs peuvent récupérer des enregistrements individuels.
• Configurer les valeurs par défaut de pagination — définir la taille de page par défaut et les limites maximales.

Principes de conception

• Commencer étroit — exposer d'abord moins d'opérations, puis élargir lorsque le modèle se stabilise.
• Nommer avec intention — les noms de requêtes font partie de ton contrat API. Les changer plus tard affecte tous les consommateurs.
• Valider avant d'exposer — utiliser la prévisualisation pour confirmer le comportement avant de partager l'endpoint avec ton équipe.

ws-05-api-designMissing

Vue de conception API alignée sur les tables du modèle.

6. Workflow de prévisualisation et d'indications

La prévisualisation devrait faire partie de chaque itération de modélisation, pas une étape finale. C'est la boucle de retour d'information qui maintient l'honnêteté de ton modèle.

Comment fonctionne la prévisualisation

Lorsque tu ouvres la prévisualisation, Mockomat :

1. Génère un schéma GraphQL à partir de ton modèle actuel.
2. Exécute une requête d'exemple contre tes données associées.
3. Retourne les résultats accompagnés d'indications de disponibilité.

La prévisualisation affiche à la fois la réponse de données et les problèmes nécessitant ton attention.

Types d'indications

Les indications sont des signaux actionnables qui t'aident à identifier et corriger les problèmes de modèle :

Indication	Signification	Action
Attribut non associé	Un champ n'a pas de source de données configurée	Assigner une association OFF_FIELD, FAKE ou CONST
Métadonnées d'endpoint manquantes	Une requête ou opération manque de configuration requise	Ouvrir la vue de conception API et compléter la configuration
Écart de configuration	Un champ est marqué comme triable mais n'a pas un type de données compatible	Vérifier la combinaison type d'attribut et flag
Avertissement de relation	Une entité ou colonne cible de relation est manquante	Vérifier la définition de relation dans l'éditeur de table

Workflow d'itération

Le workflow le plus productif suit une boucle serrée :

1. Effectuer un changement de modèle — ajouter une table, modifier un attribut, créer une relation.
2. Ouvrir la prévisualisation — exécuter une requête et inspecter les résultats.
3. Vérifier les indications — corriger tous les avertissements ou erreurs.
4. Mettre à jour la conception API — ajuster les noms de requêtes ou l'exposition des opérations si nécessaire.
5. Répéter — continuer jusqu'à ce que le modèle soit stable et la prévisualisation propre.

Ce cycle devrait prendre des secondes, pas des minutes. Plus tu itères rapidement, plus la qualité de ton modèle final sera élevée.

ws-06-preview-hintsMissing

Vue de prévisualisation avec indications actionnables de disponibilité.

7. Vues et navigation par liens croisés

Les vues offrent différentes perspectives sur le même modèle sous-jacent. Au lieu de naviguer dans des menus, tu peux basculer entre les contextes liés via des liens croisés.

Vues disponibles

• Vue board — le canevas visuel de modélisation avec tables et relations.
• Vue détail de table — vue focalisée sur une seule entité avec configuration complète des attributs.
• Vue conception API — configuration des requêtes et opérations pour l'entité sélectionnée.
• Prévisualisation runtime — exécution de requêtes en direct et inspection des réponses.

Navigation par liens croisés

Lorsque tu travailles dans une vue, des liens vers les contextes liés sont disponibles en ligne. Par exemple :

• Depuis une vue détail de table, tu peux sauter directement à la prévisualisation runtime pour tester les requêtes de cette table.
• Depuis la prévisualisation runtime, tu peux revenir à l'éditeur de table si tu remarques un problème de champ.
• Depuis la vue conception API, tu peux sauter au board de modélisation pour revoir la structure complète du domaine.

Ce modèle de navigation te maintient dans le flux — tu n'as jamais besoin de revenir au « tableau de bord » pour changer de contexte.

ws-07-views-navigationMissing

Navigation par liens croisés entre les vues du workspace.

Conseil workflow pour utilisateurs registered

Registered User

Crée des cycles d'itération courts : mise à jour du modèle → vérification de la prévisualisation → mise à jour de l'API. Cela maintient les progrès mesurables et évite la découverte tardive d'écarts. Utilise la navigation entre vues pour basculer rapidement entre les contextes liés.

Conseil workflow pour utilisateurs paid

Paid User

Définis des conventions au niveau de l'équipe pour le nommage et les modèles de relations. Réutilise ces conventions entre les projets pour un onboarding et des revues plus rapides. Documente tes conventions dans la description du projet pour que les nouveaux membres de l'équipe puissent les suivre immédiatement.