Choisissez autour des contraintes du produit
Notez ce dont le produit a besoin avant de comparer les noms de frameworks. Un tableau de bord web, un outil mobile hors ligne et un flux de recherche long ont des contraintes différentes. Décidez quels clients vous servent, quelles données appartiennent à chaque client et quelles opérations doivent continuer après la fermeture d'un onglet.
Considérez l'expérience de votre équipe en parallèle des listes de fonctionnalités. Une stack familière avec des limites claires peut être plus facile à maintenir qu'une combinaison plus récente qui exige d'apprendre en même temps l'authentification, le déploiement et les conventions de persistance. Comptez le travail continu des mises à jour et du débogage, pas seulement la première installation.
- Les surfaces client nécessaires dès le premier jour — web seul, ou mobile et bureau aussi.
- Les données qui appartiennent à chaque client, et si des équipes partagent des espaces de travail.
- Les opérations qui doivent survivre à un onglet de navigateur : jobs en file, travail planifié, tâches longues.
- Ce que vous facturerez — abonnements, sièges, usage — et qui paie.
- La surface opérationnelle que votre équipe peut réellement faire tourner : bases de données, files, fournisseurs.
Évaluez les couches sous le framework
Les noms de frameworks décrivent la surface. Les couches en dessous décident si le produit tient ensemble. Parcourez-les une par une et posez la même question à chacune : qui possède cette décision, et où est-elle appliquée ?
Traitez toute couche qu'une stack laisse vide comme du travail auquel vous vous engagez. « Apportez votre propre auth » est un design légitime — cela signifie simplement que vous posséderez la sémantique de session, les intégrations fournisseurs et chaque cas d'échec qui s'ensuit. Les couches vides sont un choix ; les couches invisibles sont un passif. La documentation des modules du kit est une référence utile pour voir à quoi ressemble une couche réellement possédée.
| Couche | La question à trancher |
|---|---|
| Identité | Qui émet et vérifie les sessions, sur chaque surface ? |
| Données | Comment chaque enregistrement est-il rattaché à son client propriétaire ? |
| Facturation | Où un événement de paiement devient-il un accès, et qui le révoque ? |
| Travail en arrière-plan | Que se passe-t-il quand un job échoue, réessaie ou tourne deux fois ? |
| IA et fournisseurs | Qui possède les clés, le choix du modèle et la limite de dépense ? |
| Opérations | Comment secrets, journaux, sauvegardes et mises à jour tournent-ils vraiment ? |
Inspectez les jointures entre les outils
Une stack est un ensemble de décisions d'intégration. Identifiez qui possède les sessions, comment les enregistrements sont délimités, où un événement de paiement devient un droit d'accès, et comment l'UI récupère le résultat d'un travail en arrière-plan. Ces connexions déterminent si le chemin nominal reste correct quand les requêtes échouent ou arrivent en double.
supastack utilise Next.js pour la surface web, Expo pour le mobile et des packages TypeScript partagés en dessous. Better Auth possède l'identité, Postgres et Drizzle persistent les enregistrements, et Trigger.dev possède la sémantique de workflow explicite. Ce sont des choix de dépôt, pas une affirmation que chaque produit devrait utiliser les mêmes outils — le guide de la stack technique consigne chaque choix et sa raison, et les questions se transposent même si vous choisissez d'autres outils.
Quels que soient les outils, le test est le même : prenez un enregistrement et tracez-le de l'interface, à travers la frontière serveur, jusqu'à la persistance, et retour. Si une étape est une convention plutôt qu'une règle appliquée, un futur contributeur finira par la casser.
Comptez le coût de fonctionnement
Une décision de stack est aussi une décision d'exploitation. Postgres exige des sauvegardes et une discipline de migration. Un lanceur de jobs exige un tableau de bord que quelqu'un ouvre vraiment. Chaque clé de fournisseur exige une rotation et un domicile hors des bundles client. Ajoutez ces lignes à la comparaison avant que la checklist des fonctionnalités ne vous séduise.
Vérifiez le chemin de mise à jour tant que vous avez encore des options. Un monorepo avec des dépendances épinglées et un processus de mise à jour documenté — le kit maintient un guide de mise à jour exactement pour cela — vieillit mieux qu'une stack assemblée depuis des tutoriels qui supposent chacun une version différente du monde.
- Mises à jour de dépendances et de sécurité : leur fréquence d'arrivée, et qui les applique.
- Identifiants fournisseurs : où ils vivent, et qui peut les faire tourner.
- Données : un calendrier de sauvegarde, un exercice de restauration et une politique de rétention.
- Observabilité : ce qui casse bruyamment, et ce qui échoue en silence jusqu'à ce qu'un client le signale.
Construisez une petite tranche verticale
Avant de vous engager sur une stack, exécutez une tranche qui connecte un utilisateur, écrit un enregistrement possédé, lance un travail et récupère un résultat. Essayez ensuite délibérément le mauvais espace de travail, une session expirée et un job en échec. Évaluez combien de glue personnalisée ces conditions ordinaires exigent.
Gardez un court dossier de décision : ce que la stack prend en charge, ce que vous choisissez de reporter, et ce qui déclencherait une révision. Les achats natifs, l'acceptation fournisseur réelle et les opérations de déploiement doivent être des éléments explicites plutôt que des hypothèses cachées derrière un build local réussi. La bonne stack laisse à l'équipe assez d'attention pour travailler sur le produit.
Si la tranche se passe bien dans le dépôt d'un starter, la question suivante est de savoir s'il faut l'adopter — starter kit ou from scratch parcourt cette décision.
- Connectez-vous, puis restaurez la session après un rechargement.
- Écrivez un enregistrement rattaché à un espace de travail et relisez-le.
- Lancez une tâche en arrière-plan et récupérez son résultat plus tard.
- Répétez les mêmes appels depuis le mauvais espace de travail et une session expirée.
Questions fréquentes sur le choix d'une stack
Les décisions de stack attirent beaucoup de conseils assurés. Voici les questions qui méritent une réponse pour votre propre produit.
- Dois-je choisir la stack que je connais déjà ? — Généralement oui, quand elle peut exprimer les contraintes du produit. Une stack familière aux limites claires bat une stack à la mode que vous passerez des mois à apprendre — sauf si le produit exige vraiment quelque chose qui lui manque, comme le mobile natif.
- Le framework front-end est-il le plus important ? — Moins que les couches autour. Le framework façonne l'UI ; l'identité, le périmètre, la facturation et le travail en arrière-plan décident si le produit reste correct.
- Combien de temps doit durer une évaluation de stack ? — Des jours, pas des semaines : écrivez les contraintes, inspectez les jointures et exécutez une tranche verticale. Si les échecs ordinaires exigent de la glue personnalisée, continuez à chercher.
- Quand un changement de stack ultérieur est-il justifié ? — Quand une contrainte centrale change — une plateforme requise, un seuil d'échelle — pas quand une nouvelle version paraît plus jolie. Le coût du changement vit dans l'auth et les données, pas dans les composants.