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 ; les appels depuis ton propre code portent une clé API du projet (voir Intégrateurs) :

POST /mock/{slug}/graphql
Authorization: Bearer mck_your_api_key

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

Tous les forfaits, sessions invité comprises, ont un accès complet au board de modélisation. Le nombre de tables par projet et d'attributs par table dépend de ton forfait — voir [Compte et forfaits](/fr/account/).

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	par ex. String, Integer, Float, Boolean, Date, JSON, Enum	Type dans les exports ; choisis le type des données liées
Obligatoire	Si le champ doit avoir une valeur	Marqué comme requis dans l'export OpenAPI
Triable	Enregistré avec le modèle	Marque des colonnes de liste triables dans l'export de code ; l'API mock trie par tout attribut associé (sortField)
Recherchable	Si le champ participe à la recherche	Inclus dans la recherche searchTerm des opérations de liste
Filtrable	Enregistré avec le modèle	Aucun effet sur l'API mock — le filtrage passe par les paramètres d'opération
Association	Source de données : SOURCE ou CONSTANT ; COMPUTED uniquement sur les attributs qui l'ont déjà (non évalué)	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

Associer les données

Dans le panneau Mappings du board, tu lies d'abord la table à une table du pool de données (Table canonique) — Suggérer en propose une, ou tu cherches toi-même dans toutes les tables. Ensuite, tu lies ses attributs à ses colonnes (SOURCE) ; Adopter … sûres reprend d'un coup toutes les suggestions sûres. Les attributs qui doivent rester vides se marquent avec Aucun mappage nécessaire. Détails : Data Sources & Field Mapping (en anglais).

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(pageSize: 5) {
    items {
      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 — définir la taille de page par défaut (au plus 100 enregistrements par page) et le tri par défaut.

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. Utilise l'état actuel de ton modèle, de tes associations et de tes opérations.
2. Exécute l'opération de liste de la table sur les données importées.
3. Affiche les données, avec une indication si quelque chose manque.

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
Non associée à des données importées	La table n'est pas liée à des données importées ; l'API ne renvoie aucune ligne pour elle	Lier la table et ses attributs dans le panneau Mappings
Aucune liaison API	La vue n'est liée à aucune opération de liste ; aucune donnée ne se charge	Lier une opération de liste dans les réglages de la vue
Aucun champ d'identification	La vue n'a pas de champ d'identification ; un clic sur une ligne n'ouvre pas de vue détaillée	Définir le champ d'identification dans les réglages de la vue

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.