Ce que VULK construit derrière une app full-stack : base de données, connexion et API, vérifiées en direct

Vérifié le 10 octobre 2026, sur le code que VULK fait tourner aujourd'hui et sur des endpoints en ligne.

Quand tu demandes à VULK une app qui doit retenir des choses, comme une boutique, un outil de réservation ou un CRM, il ne s'arrête pas aux écrans. Il construit trois choses derrière eux : une base de données propre au projet, un système de connexion pour les personnes qui utiliseront l'app, et une API REST avec laquelle les écrans communiquent. Les trois tournent sur le backend géré de VULK, à api-backend.vulk.dev, et tu n'as ni serveur, ni base de données, ni fournisseur d'authentification à configurer.

Cet article montre chaque partie telle qu'elle fonctionne vraiment. Chaque chiffre ci-dessous vient de l'une de trois sources : le code qui génère et sert ces apps (lu le 10 octobre 2026), l'endpoint de santé public du backend, et des requêtes en direct sur une boutique publique de la vitrine VULK. Rien ici n'est un benchmark que nous aurions lancé sur le produit de quelqu'un d'autre.

Le frontend que VULK écrit

Une app web sort sous la forme d'un projet React construit avec Vite. Les versions sont figées dans le générateur au lieu d'être laissées libres, donc le projet que tu prévisualises est celui que tu exportes :

Quand une app a besoin de données, VULK ajoute au projet un fichier client typé. Les écrans ne construisent jamais d'URL ni de token à la main : ils appellent ce client, et c'est le client qui appelle le backend.

Une base de données par projet

Le backend donne à chaque projet sa propre base de données PostgreSQL, identifiée par un id court : proj_ suivi des huit premiers caractères hexadécimaux de la conversation qui a construit l'app. L'id reste le même à chaque modification, donc ton app garde ses données quand tu demandes un changement.

Le backend publie un endpoint de santé que tout le monde peut lire. Le 10 octobre 2026 à 22 h 34 UTC, il a répondu :

{
  "status": "ok",
  "service": "vulk-api-engine",
  "database": "connected",
  "projects": 1440
}

Soit 1 440 bases de données de projet provisionnées sur le moteur à ce moment-là.

À quoi ressemble une table générée

VULK choisit les tables d'après ce dont ton app a besoin (produits, commandes, rendez-vous) et ajoute trois colonnes qui lui sont propres :

• id, une clé primaire de type texte
• created_at, un horodatage rempli par la base de données
• user_id sur les tables où chaque ligne appartient à une seule personne connectée

Toutes les autres colonnes prennent l'un de cinq types : texte, nombre, entier, booléen ou date-heure. Les noms de tables et de colonnes utilisent des minuscules, des chiffres et des underscores, commencent par une lettre et s'arrêtent à 48 caractères. L'API répond en camelCase, donc created_at arrive à tes écrans sous la forme createdAt.

Les changements de schéma ne font qu'ajouter. Quand une modification demande une nouvelle table ou une nouvelle colonne, le backend l'ajoute. Supprimer une colonne ou changer son type ne se fait jamais automatiquement, parce que c'est ce changement-là qui efface des données.

L'API REST, route par route

Chaque table reçoit le même jeu de routes sous l'adresse du projet :

Les listes reviennent dans une seule enveloppe, { data, meta: { total, page, perPage, totalPages } }. Le client généré lit 100 lignes par page et s'arrête à 1 000, et il envoie les insertions en masse par lots de 1 000. Chaque projet accepte 100 requêtes par minute par adresse client, et le backend l'annonce dans chaque réponse avec un en-tête X-RateLimit-Limit: 100.

Qui peut lire et écrire quoi

C'est la partie que les backends générés ratent le plus souvent, alors autant être précis. Une table sans politique d'accès déclarée est fermée. VULK donne d'abord à toute l'app l'une de quatre formes :

• Comptes privés : chaque personne se connecte et ne voit que ses propres lignes.
• Comptes d'équipe : une équipe travaille sur les mêmes lignes, et on la rejoint sur invitation.
• Public : aucun compte.
• Panneau propriétaire : des visiteurs, plus un espace que seul le propriétaire peut ouvrir.

Ensuite, il règle chaque table séparément. Une table peut être lue publiquement, avec la clé API du projet, par un utilisateur connecté ou uniquement par le propriétaire, et les écritures ont les mêmes options plus « n'importe qui », pour des choses comme un formulaire de contact. Les écritures anonymes sont plafonnées à 20 par minute et par adresse. Les champs sont privés sauf si le plan de l'app en décide autrement.

Voici cette politique sur une app en ligne. LUMA est une boutique de mode de la vitrine qui tourne sur ce backend, à proj_266b7c3c. Nous avons envoyé ces requêtes sans nous connecter, le 10 octobre 2026 :

Le catalogue est public, parce qu'une boutique doit montrer ses produits. Les commandes exigent un client connecté. La table des comptes n'est même pas exposée en tant que table.

La connexion pour les personnes qui utilisent ton app

Chaque app full-stack a ses propres comptes utilisateurs, séparés de ton compte VULK. Le client généré couvre l'inscription, la connexion, « qui suis-je » et la réinitialisation du mot de passe. Le backend a aussi des routes pour le rafraîchissement, la déconnexion et le changement de mot de passe :

• Les mots de passe sont hachés avec PBKDF2-SHA256, 100 000 itérations et un sel aléatoire de 16 octets.
• La session vit dans le navigateur et part sous forme de bearer token. Toute réponse 401 l'efface, donc l'app ne garde jamais une session que le serveur a déjà rejetée.
• La personne propriétaire du projet est l'admin ; toutes celles qui s'inscrivent sont des utilisateurs normaux.
• L'inscription peut être ouverte, ou sur invitation seulement, avec des codes à usage unique qui expirent au bout de sept jours.

Dans le studio, le tableau de bord de chaque projet a un onglet Backend avec une vue d'ensemble, la base de données, les utilisateurs de l'app, l'API et ses secrets.

Clés et secrets

Chaque projet reçoit une clé API de la forme vk_ suivi de 64 caractères hexadécimaux, stockée chiffrée avec AES-256-GCM. Le bundle publié ne contient aucune clé : l'adresse du backend est injectée dans la page au chargement, et rien de ce qui permettrait à un visiteur d'agir comme le propriétaire n'est envoyé au navigateur. Les secrets dont ton app a besoin, comme un token d'API tierce, sont en écriture seule. Tu peux en définir ou en remplacer un, mais personne ne peut le relire, et chacun est limité à 8 Ko.

Publier et emporter le code

Publier, c'est un clic. VULK construit la version de production dans la même machine isolée qui a fait tourner ton aperçu, puis la sert à <name>.vulk.space en HTTPS. Le nom que tu choisis reste à toi. Si tu dépublies, le site passe hors ligne et l'adresse reste réservée à ce projet. L'adresse du backend est liée à la fois à l'aperçu et au build publié, donc l'app publiée parle à la même base de données que celle que tu as testée.

Le code est à toi aussi. Chaque plan payant peut télécharger tout le projet en ZIP ou le pousser vers un nouveau dépôt GitHub, privé ou public. L'export GitHub ne fait jamais de force-push, et il accepte jusqu'à 1 000 fichiers et 8 Mo par push.