Scegli attorno ai requisiti del prodotto
Annota ciò di cui il prodotto ha bisogno prima di confrontare nomi di framework. Una dashboard web, uno strumento mobile offline e un flusso di ricerca lungo hanno requisiti diversi. Decidi quali client servi, quali dati appartengono a ciascun cliente e quali operazioni devono continuare dopo la chiusura di una scheda.
Pesa l'esperienza del tuo team accanto alle liste di funzionalità. Uno stack familiare con confini chiari può essere più facile da mantenere di una combinazione più recente che richiede di imparare auth, deployment e convenzioni di persistenza insieme. Conta il lavoro continuo di aggiornamenti e debug, non solo la prima installazione.
- Quali superfici client ti servono dal primo giorno — solo web, oppure anche mobile e desktop.
- Quali dati appartengono a ciascun cliente, e se i team condividono i workspace.
- Quali operazioni devono sopravvivere a una scheda del browser: job in coda, lavoro pianificato, attività di lunga durata.
- Cosa fatturerai — abbonamenti, posti, utilizzo — e chi lo pagherà.
- Quanta superficie operativa il tuo team può gestire realisticamente: database, code, provider.
Valuta i livelli sotto il framework
I nomi dei framework descrivono la superficie. I livelli sottostanti decidono se il prodotto regge. Scorrili uno alla volta e poni a ciascuno la stessa domanda: chi possiede questa decisione, e dove viene fatta valere?
Tratta ogni livello che uno stack lascia scoperto come lavoro che stai sottoscrivendo. «Porta la tua auth» è un design legittimo — significa solo che possiederai la semantica delle sessioni, le integrazioni dei provider e ogni caso di fallimento che ne segue. I livelli scoperti sono una scelta; i livelli invisibili sono un rischio. La documentazione dei moduli del kit è un riferimento utile per vedere com'è fatto davvero un livello presidiato.
| Livello | La domanda a cui rispondere |
|---|---|
| Identità | Chi emette e verifica le sessioni, su ogni superficie? |
| Dati | Come viene delimitato ogni record al cliente che lo possiede? |
| Fatturazione | Dove un evento di pagamento diventa accesso, e chi lo revoca? |
| Lavoro in background | Cosa succede quando un job fallisce, riprova o gira due volte? |
| AI e provider | Chi possiede le chiavi, la scelta del modello e il limite di spesa? |
| Operazioni | Come funzionano davvero segreti, log, backup e aggiornamenti? |
Ispeziona i punti di giunzione tra gli strumenti
Uno stack è un insieme di decisioni di integrazione. Identifica chi possiede le sessioni, come vengono delimitati i record, dove un evento di pagamento diventa un permesso e come la UI recupera il risultato del lavoro in background. Queste connessioni determinano se il percorso felice resta corretto quando le richieste falliscono o arrivano duplicate.
supastack usa Next.js per la superficie web, Expo per il mobile e pacchetti TypeScript condivisi sotto. Better Auth possiede l'identità, Postgres e Drizzle persistono i record e Trigger.dev possiede il comportamento esplicito del workflow. Sono scelte del repository, non l'affermazione che ogni prodotto dovrebbe usare gli stessi strumenti — la guida allo stack tecnologico registra ogni scelta e la sua ragione, e le domande restano valide anche se scegli strumenti diversi.
Qualunque siano gli strumenti, la prova è la stessa: prendi un record e traccialo dall'interfaccia, attraverso la frontiera del server, nella persistenza e ritorno. Se un passaggio è una convenzione invece di una regola fatta valere, un futuro contributore prima o poi lo romperà.
Conta il costo di mantenerlo in funzione
Una decisione sullo stack è anche una decisione operativa. Postgres richiede backup e disciplina nelle migrazioni. Un job runner richiede una dashboard che qualcuno apre davvero. Ogni chiave di provider richiede rotazione e una casa fuori dai bundle client. Aggiungi queste voci al confronto prima che la checklist delle funzionalità ti conquisti.
Verifica il percorso di aggiornamento finché hai ancora opzioni. Un monorepo con dipendenze fissate e un processo di aggiornamento documentato — il kit mantiene una guida all'aggiornamento del kit esattamente per questo — invecchia meglio di uno stack assemblato da tutorial che assumono ciascuno una versione diversa del mondo.
- Aggiornamenti di dipendenze e sicurezza: con che frequenza arrivano, e chi li applica.
- Credenziali dei provider: dove vivono, e chi può ruotarle.
- Dati: una pianificazione dei backup, un'esercitazione di ripristino e una policy di retention.
- Osservabilità: cosa si rompe rumorosamente, e cosa fallisce in silenzio finché un cliente non lo segnala.
Costruisci una piccola fetta verticale
Prima di impegnarti in uno stack, esegui una fetta che autentica un utente, scrive un record posseduto, avvia lavoro e recupera un risultato. Poi prova deliberatamente il workspace sbagliato, una sessione scaduta e un job fallito. Valuta quanta colla personalizzata richiedono queste condizioni ordinarie.
Tieni un breve registro delle decisioni: cosa supporta lo stack, cosa scegli di rimandare e cosa innescerebbe una revisione. Acquisti nativi, accettazione reale dei provider e operazioni di deployment dovrebbero essere voci esplicite piuttosto che supposizioni nascoste dietro un build locale riuscito. Lo stack giusto lascia al team abbastanza attenzione per lavorare sul prodotto.
Se la fetta funziona dentro il repository di uno starter, la domanda successiva è se adottarlo — starter kit o da zero percorre quella decisione.
- Accedi, poi ripristina la sessione dopo un ricaricamento.
- Scrivi un record delimitato a un workspace e rileggilo.
- Avvia un'attività in background e recuperane il risultato più tardi.
- Ripeti le stesse chiamate dal workspace sbagliato e con una sessione scaduta.
Domande frequenti sulla scelta dello stack
Le decisioni sullo stack attirano molti consigli sicuri di sé. Queste sono le domande a cui vale la pena rispondere per il tuo prodotto.
- Dovrei scegliere lo stack che conosco già? — Di solito sì, quando riesce a esprimere i requisiti del prodotto. Uno stack familiare con confini chiari batte uno alla moda che passerai mesi a imparare — a meno che il prodotto non richieda davvero qualcosa che gli manca, come il mobile nativo.
- Il framework front-end è ciò che conta di più? — Meno dei livelli che lo circondano. Il framework plasma la UI; identità, delimitazione, fatturazione e lavoro in background decidono se il prodotto resta corretto.
- Quanto dovrebbe durare una valutazione dello stack? — Giorni, non settimane: scrivi i requisiti, ispeziona le giunzioni ed esegui una fetta verticale. Se i fallimenti ordinari richiedono colla personalizzata, continua a cercare.
- Quando è giustificato cambiare stack più avanti? — Quando cambia un requisito fondamentale — una piattaforma obbligatoria, una soglia di scala — non quando una release più nuova sembra più bella. Il costo del cambio vive in auth e dati, non nei componenti.