Guida
Come scegliere un template di progetto in base ai vincoli, non alle mode
Lo starter migliore di solito è quello adatto al team, ai dati e ai vincoli operativi, non il framework più celebrato nella settimana di lancio.
Un template fa risparmiare tempo solo se è adatto al lavoro successivo. Parti dai vincoli costosi da cambiare.
Parti dal team
Un framework familiare è spesso la scelta più rapida per arrivare in produzione. Se il team sa già fare debug in Python e mantiene dipendenze pip, uno starter FastAPI o Django può essere una scelta iniziale migliore rispetto a introdurre un nuovo linguaggio per un modesto aumento di throughput. Lo stesso vale per Go, Ruby, PHP, Node.js e .NET.
Conta anche la scelta del gestore dei pacchetti. Le famiglie Next.js e Python offrono varianti per evitare che npm, pnpm, pip e Pipenv diventino una migrazione involontaria già il primo giorno.
Scegli in base ai confini del servizio
Usa un template statico quando l'output sono file. Usa un template di app web quando rendering e instradamento appartengono all'applicazione. Usa uno starter API quando l'interfaccia è gestita da un altro client. Sembra ovvio, ma scegliere un ambiente di esecuzione più ampio del necessario aumenta i tempi di compilazione e il lavoro di manutenzione senza vantaggi per l'utente.
Per i dati, parti dai modelli di accesso. PostgreSQL è una solida scelta relazionale generale, pgvector aggiunge operazioni vettoriali a PostgreSQL, Redis è adatto all'accesso rapido chiave-valore, MongoDB conserva documenti, MySQL serve carichi di lavoro relazionali e RabbitMQ gestisce messaggi in coda.
- —Output statico: Nginx static.
- —Applicazione web renderizzata sul server: Next.js, Rails, Laravel, Blazor o un altro framework applicativo.
- —API JSON o a eventi: uno starter API mirato in Node.js, Python, Go, Ruby, PHP o .NET.
- —Dipendenza con stato: scegli in base al modello di accesso ai dati, non al linguaggio dell'applicazione.
Esamina prima di distribuire
La scheda del catalogo non sostituisce la lettura dello starter. Verifica il file delle dipendenze, il comando di compilazione, l'entrypoint di produzione, la route di verifica dello stato e i volumi persistenti. Assicurati che il template esegua la piccola quantità di configurazione che desideri, senza aggiungere molta configurazione che non comprendi.
Distribuisci poi la versione minima credibile. Imparerai di più da una compilazione reale e una verifica dello stato che da un'altra ora di confronto tra le homepage dei framework.
- —Il lockfile delle dipendenze esiste ed è coerente con il gestore dei pacchetti scelto.
- —La compilazione funziona senza prompt interattivi o strumenti locali non dichiarati.
- —Il comando di avvio usa impostazioni di produzione e la porta configurata.
- —La verifica dello stato fallisce quando una dipendenza necessaria è indisponibile.
- —I percorsi dei dati persistenti sono dichiarati prima della prima scrittura reale.
Prendi una prima decisione reversibile
Il primo template deve rendere poco costoso il primo test in produzione. Mantieni ridotto il perimetro iniziale dell'API, evita formati di dati specifici del framework nelle interfacce esterne e colloca le regole di business in funzioni trasferibili se la scelta dell'ambiente di esecuzione si rivela sbagliata.
Reversibilità non significa progettare in vista di una riscrittura. Significa che la prima distribuzione produce evidenze — tempo di compilazione, uso della memoria, comportamento in caso di guasto e comprensione del team — prima che il progetto accumuli dipendenze evitabili dal framework.