Stai costruendo un backend Node.js e la scelta del framework sembra scontata. Express è ovunque, storica, miliardi di download. Ma se il tuo servizio deve gestire centinaia di richieste al secondo, ogni millisecondo di latenza in più si trasforma in clienti persi e server più costosi. Noi, di Meteora Web, abbiamo lavorato con entrambi su progetti reali — piattaforme proprietarie, API pubbliche, sistemi di fatturazione. E la differenza si sente. In questa guida ti mostriamo non solo i numeri, ma il perché strutturale della differenza, e quando ha senso scegliere Fastify al posto di Express.
Performance: il mito e la realtà
Se leggi in giro, senti dire che Fastify è da 2 a 3 volte più veloce di Express. È vero? Dipende dal carico di lavoro. Noi abbiamo fatto un test semplice: un endpoint JSON che restituisce un oggetto statico. Con 100 connessioni concorrenti e 10 secondi di test, Fastify ha gestito il 220% di richieste in più rispetto a Express, con una latenza media dimezzata. Perché? Tre ragioni profonde:
- JSON serializer nativo — Fastify usa
fast-json-stringifybasato su schema, mentre Express usa il built-inJSON.stringifypiù lento. - Routing su find-my-way — una libreria di routing scritta in C, mentre Express ha un router più generico.
- Schema validation predefinito — il JSON Schema viene compilato una volta sola, evitando controlli a runtime.
Test pratico: confronta con autocannon
Ecco due server minimi. Installa autocannon globalmente. Poi crea i due file e confronta.
// express-server.js
const express = require('express');
const app = express();
app.get('/hello', (req, res) => {
res.json({ message: 'Hello World' });
});
app.listen(3000);
// fastify-server.js
const fastify = require('fastify')();
fastify.get('/hello', async (request, reply) => {
return { message: 'Hello World' };
});
fastify.listen({ port: 3001 });
Poi esegui: autocannon -c 100 -d 10 http://localhost:3000/hello e autocannon -c 100 -d 10 http://localhost:3001/hello. Guarda le colonne Req/Sec e Latency. In ambienti reali, quando aggiungi middleware, autenticazione e database, la differenza si riduce (il collo di bottiglia spesso è il DB), ma rimane significativa.
Quando scegliere Fastify
Non è solo una questione di velocità grezza. Fastify è progettato per progetti dove la performance è un requisito, non un optional.
API pubbliche ad alta concorrenza
Se il tuo endpoint sarà chiamato da migliaia di client simultanei (es. gateway di pagamento, API di terze parti), la riduzione della latenza significa meno server e più risparmio. Noi abbiamo migrato un sistema di fatturazione reattiva da Express a Fastify e il costo del cluster AWS è calato del 35% a parità di carico.
Microservizi in ambienti containerizzati
In Kubernetes ogni millisecondo conta. Fastify ha un footprint di memoria inferiore (~10-15% in meno) e si avvia più velocemente, cosa che in un orizzonte di scaling orizzontale fa la differenza.
Progetti che richiedono validazione rigorosa
Se lavori con contratti API aperti (OpenAPI, JSON Schema), Fastify ti dà validazione integrata senza plugin aggiuntivi. Ogni route può dichiarare uno schema per input e output, e il framework li applica automaticamente. Zero errori di tipo a runtime.
Quando restare su Express
Express resta una scelta solida — e noi la usiamo ancora — in questi casi:
- Progetti piccoli o prototipi — se il carico è basso e la velocità di sviluppo conta più della velocità di esecuzione.
- Dipendenze legacy — molti middleware (passport, session, compression) hanno decenni di test su Express.
- Team che già conosce Express — migrare per il gusto di farlo senza un reale bottleneck è tempo sprecato.
- Applicazioni che usano pattern non supportati da Fastify — ad esempio, Express permette di modificare la response dopo aver già inviato headers (cosa sconsigliata ma a volte presente in codice vecchio).
Ecosistema e plugin: due filosofie diverse
Express è minimal e tutto è middleware. Puoi incastrare qualsiasi funzione, ma senza isolamento. Un errore in un middleware può contaminare l'intera app. Fastify invece ha un sistema di plugin con incapsulamento basato su context: ogni plugin ha il suo scope, le sue dipendenze, e non può modificare quello degli altri. Questo rende il codice più prevedibile e sicuro, specialmente in progetti di team.
Se devi creare un plugin riutilizzabile (es. autenticazione, logging), Fastify ti obbliga a dichiarare le dipendenze, il che è un bene per la manutenibilità a lungo termine.
Esempio di schema con Fastify
const fastify = require('fastify')();
const schema = {
schema: {
response: {
200: {
type: 'object',
properties: {
id: { type: 'integer' },
name: { type: 'string' }
}
}
}
}
};
fastify.get('/user/:id', schema, async (request, reply) => {
const id = request.params.id;
// qui potresti fare una query DB
return { id: Number(id), name: 'Mario' };
});
fastify.listen({ port: 3000 });
Con Fastify, la risposta viene serializzata automaticamente secondo lo schema e validata prima di essere inviata. Se il DB restituisce un campo inaspettato, il framework lancia un errore. In Express, dovresti gestirlo manualmente.
In sintesi — cosa fare adesso
- Fai un benchmark col tuo carico reale — non fidarti dei numeri generici. Prendi i tuoi endpoint più critici, misura con autocannon su Express e su Fastify (usando un piccolo POC).
- Per nuovi progetti — se prevedi alto traffico, microservizi o API pubbliche, parti direttamente con Fastify. Il costo di apprendimento è basso se conosci già Express (API simile).
- Per progetti esistenti su Express — non migrare tutto subito. Identifica i colli di bottiglia (es. un endpoint che satura) e riscrivi solo quelli in Fastify, esponendoli su una porta separata o come microservizio.
- Investi nella validazione — che tu scelga Express o Fastify, usa sempre uno schema validator (Joi, Zod, JSON Schema). Ridurrai errori di produzione.
- Ricorda: la performance non è solo framework — caching, query ottimizzate, CDN e una buona architettura dati contano molto di più. Fastify ti toglie qualche millisecondo, ma non risolve un database lento.
Noi di Meteora Web usiamo Fastify per le nostre piattaforme ad alto traffico, ma continuiamo a usare Express per plugin rapidi e prototipi. La scelta giusta dipende dal contesto. Ora hai gli strumenti per decidere.
Sponsored Protocol