Come si costruisce, e perché.
Ogni strumento nello stack è una decisione. Eccoli tutti, con versioni e motivazioni, tra method64, Climactra e progetti clienti. Più dieci strumenti popolari deliberatamente non in uso.
Cinque layer.
Dal pixel nel browser alla macchina nel datacenter, ogni layer con la motivazione del perché.
- 01Frontend & UICosa gira nel browser
- 02API & Backend ServicesCosa sta tra browser e database
- 03Dati, Auth & PaymentsCosa finisce sul disco, e chi può entrare
- 04AI & MLCosa capisce il linguaggio e calcola embeddings
- 05Infrastructure, Observability & DevToolsDove gira e come viene tenuta d'occhio
Clicca per saltare a una sezione. Passa il mouse su una tool card per vedere gli strumenti collegati.
Frontend & UI.
Il frontend è il layer con la maggior parte delle micro-decisioni, gerarchia tipografica, easing delle animazioni, loading state, accessibilità. Scelta dello stack: senza compromessi React-centric, perché è l'unico ecosistema in cui tutte le capability (3D, animazione, accessibilità, form, routing) stanno in una sola mano. TypeScript ovunque, niente "buttiamoci dentro un po' di JS". Tailwind invece di soluzioni CSS-in-JS, perché sparisce nella build e nel browser non costa nulla. Three.js e GSAP solo dove serve davvero 3D interattivo o sequenze coreografate, altrimenti CSS.
Modello a componenti che ha tenuto per 12 anni. Il sito method64 stesso gira su React 18 con Vite, Climactra e i progetti clienti su Next.js con React 19.2, dove le Concurrent Features e il React Compiler portano davvero un vantaggio.
Strict mode ovunque, un'intera classe di errori a runtime sparisce mentre digiti.
Server Components, App Router, routing + i18n integrati. In uso ovunque serva SSR o multi-tenancy (Climactra), questo sito se la cava con Vite + un prerenderer.
Dev server sotto il secondo, build di produzione sotto i dieci. Webpack ci ha provato per cinque anni, Vite l'ha semplicemente fatto.
Quando si usa Vite invece di Next.js, React Router è il routing onesto e indipendente, nessuna convenzione magica nascosta.
Utility-first risparmia centinaia di classi CSS custom per progetto. Nell'output di build c'è solo quello che è davvero usato.
Per styling specifico di componente fuori dal mondo Tailwind, niente collisioni di classi, niente burocrazia BEM.
Componenti come source code, non come pacchetto npm, modificabili invece di combattere con l'API.
Per sequenze guidate da timeline con easing preciso, dove le transizioni CSS non danno abbastanza controllo e le librerie JS di animazione hanno troppo overhead.
WebGL senza il boilerplate. In uso quando il 3D ha davvero senso, altrimenti resta fuori, perché è un peso massimo per il bundle.
Smooth scroll senza i tipici bug nativi, e con rispetto per `prefers-reduced-motion` out of the box.
Famiglia di icone che ha davvero un aspetto coerente. Importate singolarmente, non l'intero bundle.
Plus Jakarta Sans, Inter, JetBrains Mono, Source Serif 4, self-hosted, woff2, font-display:swap. Nessun tracking Google, nessun terzo DNS lookup.
API & Backend Services.
Il layer API costruisce contratti, non endpoint. Ogni route ha uno schema Zod, ogni response è tipizzata, frontend e backend parlano la stessa lingua, garantito dal compilatore. Fastify invece di Express, perché gli schema vengono scritti comunque e Fastify li usa per la performance. Python entra in gioco quando servono ML / embeddings / pipeline di dati, Node lì non è lo strumento giusto.
Runtime di default per tutto il lato JavaScript. Branch LTS, niente edge-cutting.
Quando entrano in gioco ML, data engineering o embeddings, tutto lì ha un percorso Python più curato della controparte JS.
Schema-driven, veloce, piccolo. Sostituto di Express, da quando validation e JSON schema vengono scritti comunque.
Una definizione di schema per validation, type TypeScript ed export di JSON schema, DRY senza una pipeline di generator.
Client SMTP che funziona preciso da 16 anni. SMTP standard significa: cambiare provider è config, non rewrite, niente lock-in come con Resend o SendGrid e le loro API HTTP proprietarie.
i18n in app Next.js con supporto Server Components, niente layer provider separato nel tree.
Dati, Auth & Payments.
Il data layer è conservativo, perché qui le migration fanno male e i bug di auth costano fiducia. Postgres come default, niente DB di vendor. Prisma come ORM, perché i type generati collegano frontend al database. pgvector invece di un database vettoriale a sé, un DB per progetto basta. Auth.js, perché è auditabile e non deve crescere in lock-in con Auth0 / Clerk.
Un DB relazionale che matura da circa 40 anni. JSONB, full-text, pgvector, tutto in un motore.
Schema come single source of truth, migration versionate, type generati automaticamente. Semplicemente la migliore DX nell'ecosistema Node.
Vector search direttamente in Postgres, niente modello di prezzo Pinecone, niente seconda base dati.
Caching in-memory e rate limiting, quando Postgres riceve troppi write per dati effimeri.
Auth senza account vendor (in passato NextAuth.js). Self-hostabile, flessibile sui provider OAuth, niente pricing cliff con la crescita di MAU. La v5 gira stabile sul beta channel da mesi, abbastanza buona per la produzione.
Password hashing che non dipende da una C lib, gira ovunque, anche in ambienti serverless.
Payment layer con la migliore developer experience. L'architettura webhook-first si sposa con quella usata qui. Per i clienti italiani il ponte verso SdI passa per Aruba Fatturazione Elettronica, Stripe addebita, Aruba emette la fattura elettronica.
Export PDF ed Excel generati lato server, Climactra produce sei report climatici pronti da stampare e quattro export per label di certificazione. I template vivono nel codice, non in uno strumento di design, stessa versionizzazione diff-abile del resto dell'app.
AI & ML.
La selezione dei modelli è pragmatica: Claude per long context e codice, GPT per chiamate bulk economiche, embeddings di OpenAI perché restano semanticamente il miglior rapporto qualità-prezzo. LangChain come collante, non come religione di framework, ma come libreria usata a punto quando si ripetono pattern standard. Niente lock-in con un provider, tutto via Anthropic / OpenAI direttamente, nessun aggregator in mezzo.
Long-context, ragionamento sul codice e tool-use a un livello su cui GPT continuerà a masticare ancora per un po'. Default per tutto ciò che richiede precisione più che velocità.
Quando latenza e costi contano, es. classificazione bulk o generazione semplice ad alto volume.
La migliore qualità di embedding per RAG, combinata con pgvector come storage.
Stage di reranking tra vector search e LLM. Alza misurabilmente la qualità delle risposte RAG, circa due dollari per mille query, trascurabile contro i costi LLM dietro.
A punto per pattern standard come retrieval chain. Non come framework wrap di tutte le chiamate LLM.
Infrastructure, Observability & DevTools.
L'infra è volutamente poco spettacolare: Docker per la riproducibilità, Hetzner invece degli hyperscaler perché gli ordini di grandezza tornano, nginx invece di application router perché gira senza drammi da 20 anni. Osservabilità a due stadi, Sentry per gli errori con stack trace, Umami per le pageview senza cookie. Deploy manuale via SSH + git pull + docker compose, a questa scala più veloce di una pipeline, e nessun secondo provider necessario.
Ambienti riproducibili, niente discussioni del tipo "funziona sulla mia macchina". Compose per setup locali multi-service.
VM reali in datacenter tedeschi, metà del prezzo di AWS per spec equivalenti. Niente vendor lock-in.
Reverse proxy, TLS termination, hosting statico, una config, tre lavori. Default per il sito method64 e per ogni setup in cui serve un classico web server.
Reverse proxy con auto-Let's-Encrypt nei setup container. Su Climactra risparmia un layer di config, stesso lavoro di nginx, trade-off diverso.
Service management senza il dramma dei daemon. Auto-restart, log in journald, standard su ogni Linux.
Infrastruttura ospitata in EU per le caselle e i record DNS propri. Abbastanza affermata da essere usata da banche e autorità. Per il volume di prodotto (Climactra) entra in gioco Amazon SES in eu-central-1 a seconda della scala.
Errori con stack trace, risolti via source map, i problemi emergono prima che gli utenti li segnalino.
Statistiche pageview senza cookie, senza salvataggio IP, GDPR-compliant. Self-hosted sul server Hetzner proprio.
Test runner che eredita le config Vite, niente doppio setup. Più veloce di Jest, stessa API di Jest.
Layer di lint che applica automaticamente convenzioni di codice di tutto il progetto, regole strict, niente scappatoie "warning".
Esegui file TypeScript direttamente da Node, build script e tool di migration girano senza un passo separato di ts-compile.
Dieci strumenti popolari lasciati fuori intenzionalmente.
Una decisione sullo stack non è solo cosa c'è dentro. Altrettanto importante: cosa resta fuori, e perché.
- WordPressL'overhead di manutenzione per temi, plugin e patch di sicurezza cresce in modo sproporzionato con la complessità del sito. Per un sito marketing servibile come HTML prerenderizzato statico, è sovradimensionato.
- BootstrapTailwind è da anni lo strumento migliore per styling utility-oriented. Le classi Bootstrap sono rigide, lo sforzo di override per un design distintivo è sproporzionato.
- jQueryI browser hanno ormai API native per manipolazione DOM, gestione eventi e richieste HTTP. Il footprint di ~30 kB non si ripaga più.
- Webpack (configurato direttamente)La configurazione è laboriosa e i tempi di build sono notevolmente più lenti rispetto a Vite. Per nuovi progetti, Vite è la scelta più pragmatica.
- MongoDBL'idea schemaless sposta solo il peso dello schema dal DB al layer applicativo. Postgres con colonne JSONB offre la stessa flessibilità senza il compromesso su transazioni e join.
- Redux / Redux ToolkitLo state management globale è inutile nella maggior parte delle app. React state, Context e server-state libraries come TanStack Query risolvono lo stesso con molto meno boilerplate.
- Vercel (hosting)DX ottima, ma il pricing delle edge function scala rapidamente oltre il costo di un server dedicato. Next.js viene distribuito direttamente su hardware proprio.
- AWS AmplifyUn'astrazione aggiuntiva sui servizi AWS che, in caso di complessità, crea più problemi di quanti ne risolva. Quando AWS è la scelta giusta, conviene di più andare direttamente sui servizi primitivi.
- Page-Builder (Webflow / framer.com)Strumenti visuali di drag-and-drop rendono più difficile ottimizzare performance, custom logic e versioning. Per siti non-triviali emergono limiti che un approccio code-first non ha.
- Backend no-code (Supabase Auth)Utili per prototipi, ma in produzione si manifestano rapidamente problemi di lock-in. La logica di auth appartiene al proprio codice in modo che resti auditabile e migrabile.
Metriche di build attuali di questo sito, generate automaticamente ad ogni deploy.