API REST Node.js documentée en OpenAPI, pour développeurs et CTO.
Vous décrivez vos ressources et leurs règles ; l'IA écrit les collections et les routes sur un socle qui a déjà les comptes, Dev et Prod, l'hébergement et le HTTPS. La spécification OpenAPI 3.0 s'exporte dès que le front ou l'équipe mobile la réclame, et chaque requête se suit dans l'Atelier jusqu'à la collection qu'elle écrit.
Mis à jour le
Démo : Comptoir Bio, chaîne fictive de douze épiceries bio à Lyon, dont l'API et le site de click & collect sont construits avec Kubbler.
Le front, section par section
L'accueil de Comptoir Bio dans l'ordre du rendu : Home rail, Process steps grid, Story split, chaque section avec son bloc et son identifiant.
Les champs à la place des valeurs
Sur le canevas, un bloc relié à l'API affiche ses expressions plutôt que des données : le bouton du hero attend le nom du magasin choisi.
orderFlow et ses routes
Le bloc orderFlow, relié aux routes listStores et listSlots, puis aux collections stores, stocks et orders. createOrder, setOrderStatus et productStock suivent dans la colonne des routes.
Le stock de Croix-Rousse, en ligne
Le site lit la même API que l'app mobile : 56 produits en rayon, 6 en rupture, prochain retrait possible lundi à 10 h.
Comptoir Bio, une démo construite avec Kubbler.
Comptoir Bio réunit douze épiceries bio à Lyon et dans sa métropole, et son app mobile de click & collect n'avait pas d'API propre. Celle-ci sert le catalogue, le stock de chaque magasin et les commandes ; le site de retrait est bâti dessus.
12 magasins, 62 produits d'octobre, un stock par produit et par magasin
Contrôleurs stores, products et orders, réponses déclarées champ par champ pour l'export OpenAPI 3.0
Retrait toutes les 30 minutes, de 10 h à 19 h 30 ; sans paiement, le stock revient au rayon après 30 minutes
Les douze magasins, leurs clients et leurs stocks sont inventés, la chaîne aussi ; le paiement tourne sur Stripe en mode test.
Le site en entier, page par page
Chaque vignette est une page complète de la démo, telle qu'un visiteur la voit. Sur ordinateur, passez dessus pour la faire défiler.
Un panier à Croix-Rousse, du stock affiché au 409.
Pour chaque geste de l'utilisateur, ce que vous lisez dans Kubbler au même moment : la route appelée, la règle appliquée, la ligne écrite.
Le rayon de son magasin
Croix-Rousse est sélectionné : 56 produits en rayon, 6 en rupture. Changer de magasin change le stock affiché, servi par la route que l'app mobile appelle aussi.
D'où vient chaque donnée affichée
Dans l'Atelier, l'accueil et son arborescence. Sur le canevas, les blocs reliés à l'API montrent leurs champs : vous savez quelle section dépend de quelle route avant de toucher au code.
Le dernier sachet de châtaignes
Cinq produits, 23,25 €, retrait aujourd'hui à 17 h 30. Sur les châtaignes d'Ardèche, le panier prévient : tout le rayon y est déjà, 1 en stock.
Le POST, avant d'écrire
Dans les Mécanismes, orderFlow et les routes qu'il appelle. À l'envoi, createOrder ne retire une quantité que s'il en reste assez dans ce magasin, en une seule opération : deux clients ne repartent pas avec le même dernier sachet.
Un autre client est passé avant
Au moment de payer, les châtaignes portent « Rupture ici ». Rien n'est débité ; le message cite Monplaisir (23) et Part-Dieu (22), où il en reste.
La commande, ligne par ligne en Dev
Dans orders : magasin, client, articles, créneau, total, état du paiement, stock rendu ou non. Vous filtrez en conditions ou en JSON Mongo ; côté Prod, la table s'ouvre sans écriture possible.
Captures : le site de Comptoir Bio pour le magasin Croix-Rousse, et le projet comptoirbio dans l'Atelier, environnement Dev.
Samedi à Croix-Rousse, 17 commandes payées et pas un sachet vendu deux fois.
Chacune de ces commandes est passée par POST /orders, qui retire le stock du magasin dans la même opération qu'il le vérifie. Quand le dernier sachet de châtaignes est parti, le panier suivant a reçu un 409 outOfStock avec le produit, le stock restant et les magasins qui en ont encore, et rien de ce refus n'arrive sur l'écran de préparation. L'équipe mobile récupère ces routes décrites en OpenAPI 3.0.
Le compte du samedi
En haut à droite : 8 commandes à préparer, 3 prêtes, 6 retirées, soit 17 commandes payées pour 301,58 €.
Un créneau, ses sacs
À 10 h, Mathilde Garnier et Karim Benali, 4 articles chacun, déjà retirés. Une commande impayée n'apparaît jamais ici.
Le magasin, en onglets
Les douze magasins sont en tête de liste ; chaque équipe ouvre le sien et fait avancer ses commandes par la route setOrderStatus, réservée aux administrateurs.
Le socle sous chaque projet, votre code au-dessus.
Les comptes et l'infrastructure sont identiques d'un projet à l'autre, et vous n'avez pas à les maintenir. Le modèle de données, les routes et leurs règles se décident et se relisent de votre côté.
Notre part
Le code réécrit à chaque projet précédent, déjà en place dans celui-ci.
L'authentification complète
Inscription, vérification de l'email, connexion, mot de passe oublié et double authentification, routes et écrans compris. Le plan les marque comme inclus : l'IA ne les régénère pas.
Dev, Prod et hébergement
Deux environnements, chacun avec sa base propre au projet. OVHcloud en France, HTTPS, sauvegardes automatiques : aucun pipeline de déploiement à écrire.
Cookies et pages légales
Un bandeau qui refuse tout par défaut, des mentions légales et une politique de confidentialité rédigées à partir de l'identité de l'éditeur, à faire relire.
Votre part
Ce qui distingue votre produit, lisible dans l'Atelier et modifiable à la main.
Le modèle de données
Collections, champs, types, champs requis, relations : décidés dans le plan, puis modifiés dans l'éditeur de données, avec un schéma versionné.
Routes et tâches planifiées
Une route sur mesure ou une tâche planifiée s'écrit à la main et s'essaie dans le bac à sable de l'API. Chaque fichier enregistré est vérifié avant d'être accepté.
La spécification OpenAPI
Exportée à tout moment en OpenAPI 3.0, en page Swagger ou en collection Postman, pour le front, l'app mobile ou le partenaire qui intègre votre API.
Troisième semaine du projet, et pas encore une route métier.
La règle qui fait le produit tient souvent en une ligne : une salle ne se réserve pas deux fois sur le même créneau, un devis expire au bout de trente jours. Avant de l'écrire, il faut l'inscription et la vérification de l'email, le mot de passe oublié, la double authentification, une base pour Dev et une pour Prod, un déploiement, un certificat, puis la documentation que l'équipe mobile attend pour commencer. Le même travail qu'au projet précédent, réécrit une fois de plus, et qu'on ne remarque que le jour où il casse.
Chaque raccourci habituel a son coût. Un boilerplate Next.js ou Express démarre vite, puis s'éloigne de son modèle dès la première semaine, et ses correctifs de sécurité sont à reporter à la main. Un backend en tant que service fournit les comptes et la base en un après-midi, mais la logique métier se disperse entre règles d'accès, fonctions et code client, et la documentation reste à écrire. Une plateforme low-code va plus vite encore, jusqu'au jour où il faut dire précisément quelle route écrit dans quelle table. Un générateur de code par IA, lui, livre à chaque projet sa propre authentification, à relire ligne par ligne.
Dans Kubbler, les comptes, les environnements, l'hébergement et le consentement viennent d'un socle commun à tous les projets, maintenu par notre équipe, que vous voyez sans pouvoir le modifier. Votre projet commence à la règle métier : l'IA écrit les collections, les routes et les tâches de fond sur Node.js et MongoDB, et le front en Next.js. Vous relisez chaque maillon dans l'Atelier, vous écrivez à la main les routes qui le demandent, et la spécification OpenAPI 3.0 s'exporte à tout moment depuis la configuration du projet.
Ce que ça coûte
Un projet et 500 sparks par mois, le budget qui paie les générations de l'IA. Des packs s'ajoutent si vous en voulez plus.
Avec votre nom de domaine : 44 € HT par mois.
Sans engagement. Le nom de domaine lui-même se paie à part.
Voir tous les tarifsCe qu'il faut préparer
Les règles qui ne se négocient pas : ce que l'API doit refuser, et dans quel cas.
Vos ressources et leurs champs, même en simple liste.
Une spécification existante, s'il y en a une : OpenAPI 3.0, Swagger 2.0 ou collection Postman s'importent.
Les clés de vos services tiers, à ranger dans l'onglet Env.
Le nom de domaine du projet, si vous l'avez déjà.
Rien d'autre : ni cahier des charges, ni maquette.
Les questions qu'on nous pose.
Y compris celles dont la réponse est « pas encore ».
Node.js et Express sur MongoDB côté serveur, Next.js et React côté front. Les routes se déclarent en configuration JSON, les contrôleurs et les modules s'écrivent en JavaScript, et chaque projet a sa propre base de données.
Pas encore. Le socle reste chez nous et il n'y a pas de dépôt à brancher. La description de l'API, elle, s'exporte quand vous le voulez au format OpenAPI 3.0, Swagger ou Postman. Vos données sont à vous : en fin de contrat, le DPA prévoit leur restitution ou leur destruction.
Non. Le socle est commun à tous les projets et apparaît en lecture seule dans l'Atelier, sous le nom de Services Kubbler : vous voyez ce que votre projet lui emprunte, sans pouvoir le changer. S'il manque à votre produit un comportement que le socle n'a pas, écrivez-nous.
Deux rôles, administrateur et utilisateur, et chaque route est publique ou demande une connexion. Pas de rôles plus fins ni de permissions par ressource pour l'instant. Dans Kubbler, chaque membre de votre équipe est lecteur, éditeur ou administrateur, et seuls les administrateurs mettent en production.
L'abonnement Starter est à 29 € HT par mois, plus l'hébergement : 5 € HT par mois avec une adresse en kubbler.app, 15 € HT par mois avec votre nom de domaine. Sans engagement. L'abonnement comprend un projet et un budget mensuel de sparks pour les générations de l'IA.
Commencez par la règle que vous repoussez depuis trois semaines.
Dans le Studio, décrivez vos ressources et ce qui doit être refusé. Kubbler propose un plan, vous le validez, puis vous suivez une requête dans l'Atelier et vous ouvrez la spécification dans Postman.
Vous l'écrivez dans l'éditeur de code du projet et vous l'essayez dans le bac à sable de l'API. À l'enregistrement, chaque fichier est vérifié avant d'être accepté, une revue de sécurité relit la modification (elle se décompte en sparks), puis elle rejoint l'historique du projet, lisible en diff à côté des changements de l'IA.