Les différences entre Go et PostgreSQL, et Node.js et Supabase

Un générateur d'IA peut produire un prototype SaaS convaincant avec l'une ou l'autre stack. La différence importante apparaît lorsque les clients créent des données incohérentes, que les reprises arrivent dans le désordre, qu'un plan de requête change et qu'il faut expliquer une panne en production. Choisissez la stack dont votre équipe peut voir et corriger les modes de défaillance, pas celle qui a produit le premier écran le plus vite.

Go avec PostgreSQL vous donne une frontière explicite entre l'application et la base de données. Vous décidez comment les requêtes entrent, où les transactions commencent, comment le SQL est conçu et comment le binaire s'exécute. Node.js avec Supabase associe un environnement JavaScript ou TypeScript à un ensemble managé de services centrés sur PostgreSQL : authentification, stockage, temps réel, API générées et exploitation hébergée. Cette option retire beaucoup de configuration, mais elle déplace aussi la logique applicative et les décisions opérationnelles qui vous reviennent.

Ce ne sont pas deux assemblages équivalents de langages. L'un est généralement un backend composé volontairement, l'autre une architecture de produit managée. Comparer leur syntaxe ou compter les fichiers générés ne répond pas à la question.

Comment les deux stacks répartissent les responsabilités

Le premier choix concerne la part du contrat backend que vous voulez posséder. Avec Go et PostgreSQL, votre service prend habituellement en charge HTTP, les décisions d'autorisation, la validation, les frontières transactionnelles, les tâches de fond et l'accès aux données. PostgreSQL gère l'état durable et les garanties de base de données. Hébergement, identité, stockage d'objets et déploiement restent des choix distincts, sauf si vous les ajoutez.

Une application Node.js et Supabase répartit ces responsabilités. Un service Node ou une fonction serverless peut contenir la logique spécifique, tandis que Supabase fournit PostgreSQL hébergé, Auth, Storage, Realtime, Edge Functions et une couche API générée depuis la base. Un client navigateur peut parfois communiquer directement avec Supabase sous Row Level Security (RLS). Cela retire du code d'endpoint courant, mais les politiques de base deviennent alors une partie de la frontière publique de l'application.

Cette distinction compte plus que Go contre TypeScript. Un gestionnaire REST généré en Go et un appel de table Supabase généré peuvent sembler tout aussi rapides. Le gestionnaire Go vous donne pourtant un endroit évident pour examiner une requête, appliquer une règle, ouvrir une transaction et émettre une trace. L'appel direct peut traverser une API générée et RLS avant d'atteindre les données. Le chemin est plus court dans le code source, pas forcément plus simple en production.

Considérez les fonctions managées comme des engagements architecturaux, pas comme des accessoires gratuits. Si Auth émet l'identité utilisée par RLS, que les politiques Storage utilisent cette même identité et que les abonnements Realtime dépendent des changements de base, remplacer une partie plus tard affecte plusieurs contrats. Ce couplage peut être tout à fait raisonnable, surtout pour une petite équipe qui gagne à acheter des services cohérents. Le problème commence lorsqu'elle croit n'avoir choisi qu'une base de données.

Go et PostgreSQL peuvent aussi cacher les dépendances si le générateur fabrique un framework interne rempli de dépôts, couches de services et aides génériques. Posséder le code n'aide que si les ingénieurs peuvent le suivre. Une abstraction générée peut rendre une mise à jour SQL simple plus difficile à trouver qu'une politique RLS. Demandez au générateur la frontière la plus petite et lisible, puis inspectez le résultat avant d'ajouter une couche.

La forme de la charge doit décider du runtime

Go convient aux services avec concurrence durable, tâches de fond variées, attentes mémoire prévisibles et endpoints dont la latence dépend de plusieurs opérations coordonnées. Les goroutines simplifient les E/S concurrentes, et un binaire compilé donne aux équipes d'exploitation une unité de déploiement compacte. Cela ne rend pas tous les services Go rapides. Un SQL médiocre, une concurrence sans limite et l'absence de délais d'expiration échouent de manière bien connue.

Node.js convient aux charges dominées par les E/S réseau, aux gestionnaires de requêtes courts, au traitement d'événements et aux équipes déjà efficaces en TypeScript. Sa boucle d'événements gère efficacement de nombreuses connexions en attente. Le calcul intensif bloque la progression s'il s'exécute sur le thread principal. Les transformations d'images, l'analyse de gros documents ou les calculs locaux liés à des modèles demandent donc des worker threads, des workers séparés ou un autre service. Le code généré ignore souvent cette frontière car les données de démonstration sont minuscules.

Supabase peut retirer du travail applicatif pour l'accès courant aux données, les flux d'authentification, le stockage de fichiers et les mises à jour temps réel pilotées par la base. C'est adapté à un produit dont la première version repose surtout sur des comptes, formulaires, enregistrements, autorisations et notifications. C'est moins adapté lorsque chaque opération coordonne de nombreux systèmes externes, exige des tâches longues ou applique des règles métier qui ne tiennent pas dans des politiques de base ou de petites edge functions.

Posez-vous quatre questions avant de choisir :

• Une action utilisateur demande-t-elle une opération sur un enregistrement ou une transaction sur plusieurs agrégats ?
• Les requêtes attendront-elles surtout les réseaux, ou effectueront-elles un travail CPU significatif ?
• Des tâches survivent-elles à une requête HTTP et demandent-elles reprises, baux, annulation ou suivi d'avancement ?
• La base peut-elle exprimer clairement l'autorisation, ou l'autorisation dépend-elle d'un état externe et de l'historique d'un workflow ?

Un import de facturation illustre cette séparation. Téléverser un fichier, stocker ses métadonnées et afficher l'avancement conviennent aux deux stacks. Analyser des milliers de lignes irrégulières, dédupliquer par rapport aux factures existantes, appliquer des règles propres à chaque compte et reprendre après une panne partielle demandent un modèle de tâche explicite. Go convient bien à ce worker. Node est aussi viable si l'équipe isole le calcul CPU et dispose d'une file durable. Supabase reste utile comme couche de base et stockage, mais il ne fait pas disparaître la sémantique des tâches.

Ne choisissez pas Go uniquement parce que les performances pourraient compter. La plupart des jeunes SaaS rencontrent des erreurs de requêtes, de produit et d'exploitation avant que le débit du runtime ne devienne une contrainte. Choisissez-le lorsque la forme du service bénéficie d'une concurrence explicite et de processus durables. Ne choisissez pas Node seulement parce qu'un modèle d'IA produit du TypeScript avec aisance. Choisissez-le lorsque la charge et les personnes qui l'exploitent profitent d'un langage unique à la frontière web.

Les compétences de l'équipe changent le coût du code généré

La meilleure stack est celle que votre équipe peut déboguer après une erreur du générateur. La vitesse de génération vaut peu si les relecteurs ne reconnaissent pas une mise à jour perdue, une politique dangereuse ou une promesse jamais attendue.

Une équipe expérimentée en production avec Go préférera souvent des gestionnaires explicites, des structures métier typées, l'annulation via context.Context et du SQL direct. Le compilateur Go détecte une classe utile d'erreurs de câblage, mais il ne peut pas prouver qu'une transaction protège les bonnes lignes ni qu'un contrôle d'autorisation respecte la règle métier. Les relecteurs ont toujours besoin de discernement sur les bases de données.

Une équipe centrée sur TypeScript peut avancer rapidement dans une base Node et Supabase, car les types du frontend et du backend utilisent des outils familiers. Les types de base générés par Supabase améliorent le retour de l'éditeur quand le schéma fait foi. Les types n'imposent pas seuls une validation à l'exécution, et une assertion de type peut taire l'avertissement dont un relecteur avait besoin. Le code généré suppose volontiers que l'entrée externe a déjà la forme attendue.

La compétence comprend aussi le vocabulaire opérationnel. Quelqu'un sait-il lire EXPLAIN (ANALYZE, BUFFERS) sans deviner ? Distinguer une expression RLS USING de WITH CHECK ? Suivre un gestionnaire Node asynchrone à travers des promesses rejetées ? Examiner la saturation du pool de connexions Go et propager l'annulation ? La stack qui obtient le plus de réponses positives présente moins de risque opérationnel.

Les petites équipes doivent compter les changements de contexte. Go avec PostgreSQL peut demander des choix distincts pour les migrations, l'authentification, le stockage, les files, l'observabilité et l'hébergement. Chaque choix peut être bon tout en ajoutant de l'intégration. Node avec Supabase concentre davantage cette surface dans un seul produit et maintient TypeScript près du frontend. L'attention économisée est réelle.

Le coût inverse est une connaissance spécialisée. L'accès direct du navigateur sous RLS demande à chaque relecteur de comprendre la politique de base comme une autorisation applicative. Les edge functions introduisent une frontière d'exécution distincte d'un serveur Node classique. Les tableaux de bord hébergés facilitent le travail courant, mais peuvent inciter à modifier la production hors migrations versionnées. Rien de cela n'écarte Supabase. Intégrez-le à l'estimation.

Quand personne dans l'équipe n'a exploité l'une ou l'autre stack, privilégiez le design comportant le moins de pièces indépendantes et notez un chemin de sortie. Pour un SaaS orienté enregistrements, ce sera souvent Supabase. Pour un backend fondé sur des tâches, intégrations et workflows personnalisés, un petit service Go avec PostgreSQL managé peut être plus facile à comprendre qu'une logique répartie entre appels client, politiques, fonctions et triggers.

Le contrôle des requêtes devient le contrôle du produit

Choisissez Go avec accès direct à PostgreSQL lorsque la forme du SQL et le comportement transactionnel sont au cœur du produit. Choisissez l'accès aux données généré par Supabase lorsque le CRUD ordinaire domine et que RLS exprime le modèle de sécurité sans contorsions.

La documentation PostgreSQL est précise sur l'isolation des transactions : Read Committed est le niveau par défaut, et deux commandes successives dans une transaction peuvent voir des données validées différentes. Les équipes répètent souvent qu'une transaction rend les opérations sûres sans préciser le niveau d'isolation ni le verrouillage. Une transaction regroupe du travail. Elle n'empêche pas automatiquement toutes les courses.

Supposons que deux workers prennent la prochaine exportation en attente. Une lecture suivie d'une mise à jour peut leur permettre d'observer la même ligne. Transformez la prise en une seule opération de base et utilisez le verrouillage volontairement :

BEGIN;

WITH next_job AS (
  SELECT id
  FROM export_jobs
  WHERE status = 'pending'
  ORDER BY created_at
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
UPDATE export_jobs AS j
SET status = 'running',
    started_at = now(),
    worker_id = $1
FROM next_job
WHERE j.id = next_job.id
RETURNING j.id, j.account_id, j.payload;

COMMIT;

Le résultat contient soit une ligne prise avec id, account_id et payload, soit zéro ligne lorsqu'aucune tâche n'est disponible. SKIP LOCKED convient aux consommateurs de type file qui peuvent prendre des lignes différentes. Ce n'est pas un remède général aux lectures côté utilisateur, car il omet volontairement les lignes verrouillées.

En Go, cette instruction peut vivre dans un dépôt ou paquet de requêtes, avec transaction explicite et délai d'annulation. En Node, un client de base côté serveur peut exécuter une fonction ou un appel SQL équivalent. Avec une API Supabase générée, la logique de verrouillage complexe se déplace souvent dans une fonction PostgreSQL exposée via RPC. C'est toujours du PostgreSQL solide, mais les relecteurs doivent chercher dans les migrations et fonctions de base plutôt que dans le gestionnaire de requête.

RLS mérite la même précision. PostgreSQL évalue les politiques par table et par commande. Une clause USING contrôle les lignes existantes qu'une commande peut voir, tandis que WITH CHECK contrôle les lignes nouvelles ou modifiées qu'elle peut créer. Une politique qui filtre les lectures n'exprime pas automatiquement tous les invariants pour insertions et mises à jour. Testez au minimum une identité anonyme, un membre normal, un membre d'un autre tenant et un rôle de service privilégié.

Le CRUD généré est séduisant car il enlève le code répétitif des endpoints. Gardez-le pour les opérations dont le contrat a réellement la forme d'une table. Placez les invariants multi-enregistrements, l'idempotence et les transitions de workflow derrière une frontière serveur ou une fonction de base conçue avec soin. Si la règle produit demande un paragraphe d'explication, l'éparpiller entre code client et plusieurs politiques RLS rallongera le prochain incident.

La portabilité dépend de la frontière préservée

Go et PostgreSQL offrent généralement une sortie de déploiement plus claire : l'application est un binaire et la base parle les protocoles PostgreSQL standards. Vous pouvez exécuter le service dans un conteneur ou directement sur un hôte et choisir parmi de nombreux fournisseurs PostgreSQL. La portabilité dépend toujours de l'absence d'extensions propres au fournisseur, d'infrastructure non documentée et d'hypothèses d'environnement.

Supabase utilise PostgreSQL, ce qui lui donne une bien meilleure sortie de données qu'une base propriétaire. Un export de base peut préserver tables, index, fonctions, triggers et une grande partie du modèle de politiques. L'application complète peut toutefois dépendre aussi des revendications des jetons Auth, des conventions d'objets Storage, du comportement de Realtime, des edge functions, de la sémantique de l'API générée, des secrets et de la configuration de déploiement. Déplacer la base ne revient pas à déplacer le système.

Créez un inventaire de portabilité avant le lancement. Notez chaque dépendance sous base de données, identité, fichiers, travail asynchrone, runtime et déploiement. Pour chacune, indiquez le contrat consommé par le code et le coût de remplacement. La question utile n'est pas de savoir si la migration est possible. Presque tout l'est avec assez de temps. Demandez-vous si une équipe de livraison ordinaire peut la faire tout en continuant à livrer le produit.

L'export du code source compte pour un SaaS généré par IA, car l'application générée n'est utile que si vous pouvez inspecter et exécuter ce que vous possédez. Koder.ai prend en charge l'export du code source, le déploiement et l'hébergement. Une équipe peut donc relire l'application React et Go/PostgreSQL générée au lieu de traiter la génération comme un point opaque. Cela ne dispense pas de tester une compilation propre hors de l'environnement de génération.

Faites cette compilation tôt. Partez d'une machine vide ou d'un conteneur minimal, restaurez une base depuis les migrations, fournissez les variables d'environnement documentées, lancez les tests et servez une requête représentative. Restaurez ensuite une vraie sauvegarde dans un environnement hors production. Les équipes qui attendent un changement de fournisseur ou une panne pour tester la portabilité ont déjà fait le choix coûteux.

L'emplacement des données peut aussi déterminer la portabilité. Si des contrats exigent que l'application s'exécute dans un pays donné, vérifiez que runtime, base, sauvegardes, journaux, stockage d'objets et accès support respectent tous cette exigence. Déplacer seulement le processus web ne déplace pas le système de données. Koder.ai peut exécuter des applications dans différents pays pour répondre aux besoins de confidentialité et de transfert transfrontalier, mais les équipes doivent cartographier chaque composant portant des données dans leur propre architecture.

Le débogage révèle où la complexité est partie

Go et PostgreSQL concentrent souvent le débogage dans les traces de requêtes, journaux de services, sessions de base et workers. Node.js et Supabase peuvent répartir la même enquête entre appels navigateur, processus Node ou edge function, journaux d'API générée, Auth, RLS, Realtime et PostgreSQL. Moins de lignes de code applicatif peut signifier plus de frontières à inspecter.

Une panne courante commence par un changement de schéma anodin. Une application générée ajoute un organization_id nullable, remplit certaines lignes existantes, active une politique RLS et modifie la requête client. Le compte du parcours heureux fonctionne. Une ancienne ligne reste nulle, la politique la masque, le client reçoit un résultat vide au lieu d'une erreur d'autorisation explicite et affiche un état vide. Un abonnement temps réel utilise un filtre différent et continue d'annoncer des changements. Le support voit un écran qui se repeuple parfois après actualisation.

Rien dans cette chaîne n'est exotique. La difficulté consiste à observer chaque décision. L'enquêteur a besoin du sujet authentifié, des revendications du jeton, de l'identifiant de requête, du rôle de base, du SQL ou de l'opération d'API générée, du résultat de politique, du nombre de lignes, du canal d'abonnement et de la version de schéma déployée. Si ces faits vivent dans des tableaux de bord sans valeur commune de corrélation pour requête ou utilisateur, l'équipe reconstitue l'incident à partir des horodatages.

Un endpoint Go classique peut transformer l'organisation absente en erreur métier avant la requête, journaliser un événement structuré et renvoyer un statut défini. Cette explicitation est utile, mais suppose que le gestionnaire soit le seul chemin vers la table. Un endpoint d'administration ou worker oublié peut contourner la même autorisation si la base n'impose pas un invariant correspondant.

Le design Supabase peut imposer l'isolation des tenants dans PostgreSQL pour chaque chemin client. C'est également utile. Son mode de défaillance est l'invisibilité de politique : un ensemble vide peut venir d'un filtrage correct, d'un mauvais contexte d'identité, de données de migration incomplètes ou d'un bug de requête. Créez des opérations de diagnostic qui distinguent ces cas sans désactiver RLS en production.

Pour les deux stacks, exigez quatre champs dans chaque chemin backend généré : identifiant de corrélation, identifiant de l'acteur authentifié, nom de l'opération et version du schéma ou de la release. Enregistrez durées et nombres de lignes lorsqu'ils ne révèlent pas de données sensibles. Conservez la cause d'erreur d'origine tout en la convertissant en réponse client sûre. En Node, traitez les promesses rejetées à la frontière de requête et ne considérez pas un gestionnaire au niveau du processus comme une récupération. En Go, transmettez le contexte de requête aux appels de base et distinguez l'annulation par délai d'une panne de base.

La capacité de débogage est une propriété du design. Si le générateur produit du code que les opérateurs ne peuvent pas suivre, demandez-lui de simplifier le flux de contrôle avant de lui demander d'ajouter des journaux partout.

La commodité de déploiement et la responsabilité opérationnelle diffèrent

Supabase gagne généralement le premier tour opérationnel. Une équipe peut créer un projet et recevoir une base avec des services intégrés sans assembler chaque composant. Sauvegardes, mises à niveau, disponibilité des services et supervision de plateforme disposent de valeurs managées ou de contrôles produits. Consultez la documentation actuelle du plan et du fournisseur pour les limites et la rétention exactes, car elles peuvent changer.

Managé ne signifie pas sans surveillance. L'équipe application possède toujours le schéma, les index, les requêtes coûteuses, le comportement des connexions, la rétention des données, la justesse de RLS, les secrets, la supervision applicative et les tests de récupération. Elle doit aussi connaître les quotas et les pannes qui demandent le support du fournisseur. Un tableau de bord indiquant que la base est saine ne dira pas qu'un rapport d'un tenant fait accidentellement un scan séquentiel.

Go et PostgreSQL rendent la responsabilité plus visible. Avec PostgreSQL managé, le fournisseur peut gérer une grande part de la mécanique de base pendant que votre équipe possède le runtime du service. Si vous auto-hébergez les deux, vous possédez aussi correctifs, basculement, sauvegardes, exercices de restauration, capacité et réponse aux incidents. L'auto-hébergement n'est pas un signe de sérieux. C'est une charge d'exploitation qui demande des personnes et des répétitions.

La gestion des connexions piège les deux stacks. Un service Go durable utilise un pool et exige des limites explicites de connexions ouvertes et inactives, de durée de vie et de délais de requête. Des fonctions Node serverless peuvent créer une rafale de clients qui submerge PostgreSQL si l'architecture n'utilise pas un pooler adapté et ne respecte pas les limites du mode transaction. Un code généré qui ouvre un nouveau client par requête peut survivre à une démo et s'effondrer lors d'un pic.

Les migrations ont besoin d'une autorité unique. Exécutez des migrations ordonnées et versionnées depuis une étape de déploiement contrôlée. Ne laissez pas chaque instance de service modifier le schéma au démarrage, et ne laissez pas les modifications de tableau de bord devenir la vérité de production non documentée. Les changements d'extension puis de retrait réduisent le couplage : ajoutez une colonne ou table compatible, déployez du code qui gère les deux formes, remplissez l'historique, basculez les lectures, puis retirez l'ancienne forme dans une release ultérieure.

Les sauvegardes ne comptent qu'après une restauration réussie. Planifiez une restauration dans un environnement isolé et vérifiez des faits au niveau application : les utilisateurs peuvent s'authentifier, les frontières des tenants restent intactes, les fichiers correspondent encore aux références de base, les tâches planifiées ne s'exécutent pas deux fois et un workflow représentatif se termine. Ce travail existe pour les deux stacks. L'option managée change qui fait tourner la mécanique de sauvegarde, pas qui décide si le produit restauré est correct.

La vitesse du prototype peut fournir de mauvaises preuves

Le premier prototype mesure la vitesse avec laquelle une stack traite le chemin que le générateur a reçu en prompt. Il ne mesure pas la gestion de la contention, des pannes partielles, de l'évolution des politiques, des restaurations ou de l'enquête d'un nouvel ingénieur six mois plus tard.

Node.js et Supabase offrent souvent le chemin le plus court vers un produit crédible orienté enregistrements. Authentification, accès aux données, stockage et temps réel sont disponibles sans sélectionner ni intégrer séparément des fournisseurs. Un générateur TypeScript dispose de nombreux modèles à imiter. Pour un fondateur qui veut valider l'intérêt d'un workflow, cette vitesse peut l'emporter sur les préoccupations théoriques de portabilité.

Go et PostgreSQL fournissent souvent de meilleures preuves lorsque le risque du produit se trouve dans le comportement backend. Une API et un worker explicites permettent de tester tôt idempotence, verrouillage, limites de débit, reprises d'intégration et frontières métier. L'interface initiale n'arrivera peut-être pas plus vite, mais le prototype exerce la partie la plus susceptible d'échouer.

Le conseil populaire de commencer avec Supabase puis de réécrire plus tard est trop désinvolte. Il est répandu parce que de nombreux produits n'ont jamais besoin de réécriture et que la validation précoce compte. Il devient faux lorsque le prototype place l'autorisation dans RLS, le workflow dans les triggers, l'identité dans les revendications du fournisseur, les fichiers dans les conventions Storage et le comportement événementiel dans les abonnements Realtime, tout en appelant cela temporaire. La réécriture traverse alors tous les contrats importants en même temps.

Le conseil inverse, construire dès maintenant un service Go propre parce que l'échelle arrivera, est tout aussi faible. Il peut consommer un temps rare en plomberie d'endpoints, déploiement et frontières de service avant de savoir si le produit les mérite. Une architecture inutilisée a une disponibilité parfaite.

Prototypez le risque, pas les écrans. Si la politique de tenant est difficile, créez des règles RLS représentatives et attaquez-les avec des tests inter-tenants. Si le traitement de fond est difficile, faites passer les workers par livraison dupliquée, délai, annulation et redémarrage. Si la portabilité est contractuelle, restaurez la base et déployez l'application dans un second environnement. Si des fondateurs non techniques doivent maintenir le produit, demandez-leur d'effectuer un vrai changement de schéma et workflow via l'interface de génération, puis inspectez le diff obtenu.

Le mode planification, les instantanés et le retour en arrière peuvent rendre l'itération générée plus sûre, mais ils ne transforment pas un retour de base en machine à remonter le temps. Un changement de schéma qui supprime ou réécrit des données clients demande une sauvegarde et un plan de récupération vers l'avant, même si le code applicatif peut revenir à un instantané antérieur.

Une matrice de décision pour le système après lancement

Choisissez Go avec PostgreSQL lorsque le comportement serveur personnalisé est la partie difficile du produit, que l'équipe sait exploiter Go, que le contrôle SQL importe et que vous voulez des composants de déploiement aux contrats remplaçables. Choisissez Node.js avec Supabase lorsque le produit se compose surtout de workflows de données authentifiés, que l'équipe maîtrise TypeScript, que les services intégrés retirent une configuration significative et que RLS exprime clairement les autorisations.

Notez le produit réel de un à cinq sur ces critères, puis discutez chaque note où les membres de l'équipe diffèrent de plus d'un point :

N'additionnez pas aveuglément les colonnes. Pondérez les deux ou trois critères qui peuvent tuer le produit. Un workflow de santé peut placer emplacement des données et autorisation au-dessus de la vitesse de développement. Un outil interne d'approbation peut privilégier la rapidité de livraison et TypeScript familier. Un produit d'import de données peut dépendre de la récupération des workers et du contrôle des requêtes.

Les designs hybrides sont légitimes lorsque la frontière est explicite. Un worker Go peut traiter des tâches longues sur PostgreSQL de Supabase pendant qu'une application web TypeScript utilise Auth et les API de table courantes. Un service frontend Node peut appeler une API Go qui possède les workflows transactionnels. L'hybride devient nocif lorsque les deux côtés peuvent modifier le même état sans propriétaire unique de l'invariant.

Écrivez une fiche d'architecture d'une page avant la génération. Indiquez la charge, l'autorité de chaque invariant, la frontière transactionnelle, le modèle de tâches asynchrones, la source d'identité, la propriété des fichiers, la cible de déploiement, la méthode de récupération et la contrainte de portabilité. Faites ensuite en sorte que le code généré prouve ces choix. La qualité du prompt aide, mais une fiche d'architecture empêche le générateur de décider discrètement les points difficiles selon l'exemple qu'il a rencontré le plus souvent.

La décision de stack est terminée lorsque l'équipe peut expliquer une requête échouée, restaurer l'état client et modifier une règle métier sans deviner où elle vit. Choisissez le design qui rend ces trois tâches ordinaires.