Documentation
Les bases no-code du workspace
Les bases no-code stockent les données de votre workspace dans des tables interrogeables, sans écrire de schéma SQL à la main. On y définit des tables, on les interroge, on ouvre un accès par clé API, et la même base peut alimenter à la fois les sites publiés et le studio no-code. Cette page explique l'organisation des tables et des requêtes, le rôle des clés API, et ce que recouvre la surface publique exposée aux applications qui consomment ces données.
Tables et requêtes
Une base regroupe des tables ; chaque table décrit un type d'enregistrement par ses colonnes (champs). Vous ajoutez, modifiez et supprimez des enregistrements, et vous les interrogez pour ne remonter que ce dont l'application a besoin : filtrer sur un champ, trier, paginer.
Tables et champs
Une table est un ensemble d'enregistrements de même forme. Ses champs typés définissent ce que chaque enregistrement peut contenir.
Requêtes de lecture
Filtrer, trier et paginer pour ne renvoyer que les enregistrements utiles, plutôt que de charger la table entière côté application.
Écritures
Création, mise à jour et suppression d'enregistrements, depuis l'éditeur no-code ou par l'API selon les droits de la clé utilisée.
Clés API
Une clé API donne à un programme un accès à la base sans passer par un compte utilisateur. Elle porte des droits : à quelles tables elle accède, et si elle peut seulement lire ou aussi écrire. C'est le mécanisme qui permet à un site publié ou à un service tiers de consommer les données.
| Aspect | Ce que la clé contrôle | Bonne pratique |
|---|---|---|
| Portée | Les tables et opérations autorisées | Une clé par usage, limitée au strict nécessaire |
| Sens | Lecture seule ou lecture-écriture | Réserver l'écriture aux clés qui en ont réellement besoin |
| Cycle de vie | Création et révocation | Révoquer sans attendre une clé exposée ou inutilisée |
Surface publique
La surface publique d'une base, c'est l'ensemble de ce qui est accessible par API depuis l'extérieur du workspace : les tables ouvertes à une clé et les opérations qu'elle autorise. Cette surface est le point de contact entre vos données et les applications qui les consomment.
Deux consommateurs de premier plan s'appuient dessus. Les sites publiés lisent la base pour afficher du contenu dynamique — voir /docs/plateforme-sites. Le studio no-code s'y branche pour construire des interfaces et des écrans qui lisent et écrivent les enregistrements — voir /docs/plateforme-studio. La même base peut donc servir un site vitrine en lecture et une application interne en lecture-écriture, à condition que les clés distinguent bien les deux usages.
- N'exposez à une clé publique que les tables et champs destinés à être vus de l'extérieur.
- Séparez les clés par consommateur : une pour le site publié en lecture, une autre pour le studio, plutôt qu'une clé unique tout-puissante.
- Traitez la surface publique comme un contrat : renommer ou retirer un champ consommé par un site ou le studio casse leur affichage.
- Auditez régulièrement les clés actives et révoquez celles qui ne correspondent plus à un usage vivant.