Created by Github action
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Adds a full French documentation set covering developers (API,
webhooks, backend/frontend, self‑hosting) and user guide (CRM
essentials, data model, workflows, settings, integrations, pricing,
reporting).
>
> - **Docs (FR i18n)**:
> - **Developers**: Add `API`, `Webhooks`, backend (best practices,
custom objects, feature flags, architecture, commands, Zapier), frontend
(best practices, architecture, commands, hotkeys, style guide,
Storybook, Figma), self‑hosting (Docker Compose, upgrade guide, cloud
providers), introduction.
> - **User Guide**: Add getting started (what is Twenty,
create/configure workspace, migration, import/export), CRM essentials
(contacts/accounts, pipelines, views), data model (objects, fields,
relations, table views), collaboration (emails/calendars, notes, tasks),
integrations API (overview, integrations), workflows (getting started,
features, credits, internal automations, services), settings (profile,
permissions, members, domains, releases, email/calendar setup), pricing
(billing/FAQ), reporting overview, resources (GitHub, glossary),
introduction.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
9ba8c24571. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: github-actions <github-actions@twenty.com>
Co-authored-by: Félix Malfait <felix@twenty.com>
131 lines
4.4 KiB
Plaintext
131 lines
4.4 KiB
Plaintext
---
|
|
title: Architecture des Dossiers
|
|
info: Un regard détaillé sur l'architecture des dossiers de notre serveur
|
|
image: /images/user-guide/fields/field.png
|
|
---
|
|
|
|
<Frame>
|
|
<img src="/images/user-guide/fields/field.png" alt="Header" />
|
|
</Frame>
|
|
|
|
La structure du répertoire backend est la suivante :
|
|
|
|
```
|
|
server
|
|
└───ability
|
|
└───constants
|
|
└───core
|
|
└───database
|
|
└───decorators
|
|
└───filters
|
|
└───guards
|
|
└───health
|
|
└───integrations
|
|
└───metadata
|
|
└───workspace
|
|
└───utils
|
|
```
|
|
|
|
## Capacité
|
|
|
|
Définit les permissions et inclut des gestionnaires pour chaque entité.
|
|
|
|
## Décorateurs
|
|
|
|
Définit des décorateurs personnalisés dans NestJS pour des fonctionnalités supplémentaires.
|
|
|
|
Voir [décorateurs personnalisés](https://docs.nestjs.com/custom-decorators) pour plus de détails.
|
|
|
|
## Filtres
|
|
|
|
Inclut des filtres d'exception pour gérer les exceptions qui pourraient se produire dans les points de terminaison GraphQL.
|
|
|
|
## Gardes
|
|
|
|
Voir [gardiens](https://docs.nestjs.com/guards) pour plus de détails.
|
|
|
|
## Santé
|
|
|
|
Inclut une API REST disponible publiquement (healthz) qui renvoie un JSON pour confirmer si la base de données fonctionne comme prévu.
|
|
|
|
## Métadonnées
|
|
|
|
Définit des objets personnalisés et met une API GraphQL à disposition (graphql/metadata).
|
|
|
|
## Espace de travail
|
|
|
|
Génère et sert un schéma GraphQL personnalisé basé sur les métadonnées.
|
|
|
|
### Structure du répertoire de l'espace de travail
|
|
|
|
```
|
|
workspace
|
|
|
|
└───workspace-schema-builder
|
|
└───factories
|
|
└───graphql-types
|
|
└───database
|
|
└───interfaces
|
|
└───object-definitions
|
|
└───services
|
|
└───storage
|
|
└───utils
|
|
└───workspace-resolver-builder
|
|
└───factories
|
|
└───interfaces
|
|
└───workspace-query-builder
|
|
└───factories
|
|
└───interfaces
|
|
└───workspace-query-runner
|
|
└───interfaces
|
|
└───utils
|
|
└───workspace-datasource
|
|
└───workspace-manager
|
|
└───workspace-migration-runner
|
|
└───utils
|
|
└───workspace.module.ts
|
|
└───workspace.factory.spec.ts
|
|
└───workspace.factory.ts
|
|
```
|
|
|
|
La racine du répertoire de l'espace de travail inclut le fichier `workspace.factory.ts`, qui contient la fonction `createGraphQLSchema`. Cette fonction génère un schéma spécifique à l'espace de travail en utilisant les métadonnées pour adapter un schéma pour chaque espace de travail. En séparant la construction du schéma et du résolveur, nous utilisons la fonction `makeExecutableSchema`, qui combine ces éléments distincts.
|
|
|
|
Cette stratégie n'est pas seulement une question d'organisation, mais aide également à l'optimisation, comme la mise en cache des définitions de type générées pour améliorer les performances et la scalabilité.
|
|
|
|
### Constructeur de schéma d'espace de travail
|
|
|
|
Génère le schéma GraphQL, et inclut :
|
|
|
|
#### Usines :
|
|
|
|
Constructeurs spécialisés pour générer des constructions liées à GraphQL.
|
|
|
|
- La type.factory traduit les métadonnées de champs en types GraphQL en utilisant le `TypeMapperService`.
|
|
- La type-definition.factory crée des objets d'entrée ou de sortie GraphQL dérivés de `objectMetadata`.
|
|
|
|
#### Types GraphQL
|
|
|
|
Inclut des énumérations, des entrées, des objets et des scalaires, et sert de blocs de construction pour la construction du schéma.
|
|
|
|
#### Interfaces et définitions d'objets
|
|
|
|
Contient les plans pour les entités GraphQL, et inclut à la fois des types prédéfinis et personnalisés comme `MONEY` ou `URL`.
|
|
|
|
#### Services
|
|
|
|
Contient le service responsable de l'association du FieldMetadataType avec son type scalaire ou modificateur de requête GraphQL approprié.
|
|
|
|
#### Stockage
|
|
|
|
Inclut la classe `TypeDefinitionsStorage` qui contient des définitions de type réutilisables, empêchant la duplication des types GraphQL.
|
|
|
|
### Constructeur de résolveur d'espace de travail
|
|
|
|
Crée des fonctions de résolveur pour interroger et modifier le schéma GraphQL.
|
|
|
|
Chaque usine de ce répertoire est responsable de la production d'un type de résolveur distinct, comme le `FindManyResolverFactory`, conçu pour une application adaptable à plusieurs tables.
|
|
|
|
### Exécuteur de requêtes d'espace de travail
|
|
|
|
Exécute les requêtes générées sur la base de données et analyse le résultat.
|