# Fastify vs Express nel 2026: quale scegliere per un nuovo progetto

> Confronto pratico tra Fastify ed Express nel 2026: performance, plugin architecture, validazione basata su schema, maturità dell'ecosistema e quando conviene l'uno o l'altro.

- Autore / Author: Diego Betto (https://diegobetto.com/about/)
- Pubblicato / Published: 2026-09-03
- URL: https://diegobetto.com/fastify-vs-express-2026/
- Tag: fastify, nodejs, express, api

Express resta, di gran lunga, il framework HTTP più usato nell'ecosistema Node.js — è la scelta di default in praticamente ogni tutorial. Fastify esiste da anni come alternativa seria, ma la domanda "quale dei due per un nuovo progetto" continua a tornare, e la risposta onesta è: dipende da cosa stai ottimizzando.

### Performance: non è solo marketing

La differenza di velocità tra i due non nasce da micro-ottimizzazioni del router, ma da una scelta architetturale precisa: Fastify serializza le risposte JSON usando lo **schema dichiarato per la rotta**, invece di passare per `JSON.stringify` generico. Se dichiari la forma esatta della risposta, Fastify può generare un serializzatore ottimizzato per quella forma specifica, saltando gran parte del lavoro che `JSON.stringify` fa per gestire il caso generico.

```js
fastify.get(
  "/utenti/:id",
  {
    schema: {
      response: {
        200: {
          type: "object",
          properties: {
            id: { type: "number" },
            nome: { type: "string" },
          },
        },
      },
    },
  },
  async (request) => {
    return db.trovaUtente(request.params.id);
  },
);
```

Express non ha un concetto equivalente integrato: la validazione e la serializzazione, se le vuoi, arrivano da middleware terzi (`express-validator`, `zod` a mano nella route). I numeri esatti dei benchmark cambiano a ogni release di entrambi i framework — per i dati aggiornati conviene guardare direttamente la [pagina ufficiale dei benchmark di Fastify](https://fastify.dev/benchmarks/) invece di fidarsi di un numero fissato in un articolo. La direzione, però, è stabile da anni: Fastify è più veloce, e il divario si allarga proprio negli endpoint con risposte JSON strutturate, dove la serializzazione basata su schema pesa di più.

> Per la maggior parte delle applicazioni web, la differenza di throughput tra Express e Fastify non
> è il collo di bottiglia reale — lo sono quasi sempre le query al database, chiamate a servizi
> esterni o I/O bloccante. Scegliere Fastify "perché è più veloce" senza che le performance HTTP
> pure siano davvero un problema misurato è ottimizzare la parte sbagliata dello stack.

### Differenze architetturali

**Plugin encapsulation.** Fastify tratta ogni plugin come un contesto isolato: decoratori, hook e configurazioni registrati dentro un plugin non trapelano fuori, a meno che tu non li registri esplicitamente come globali. Questo rende naturale strutturare un'app grande in moduli indipendenti (auth, utenti, pagamenti) senza che uno "sporchi" lo stato di un altro — un problema comune nelle app Express grandi, dove i middleware sono globali per design e l'ordine di registrazione conta silenziosamente.

**Validazione integrata.** In Fastify lo schema (JSON Schema o TypeBox) non è solo documentazione: viene compilato in un validatore reale (`ajv`), eseguito automaticamente prima dell'handler. In Express la validazione è sempre un passo esplicito e manuale, spesso disomogeneo tra route diverse dello stesso progetto perché non c'è un pattern imposto dal framework.

**Hook del ciclo di vita.** Fastify espone hook granulari (`onRequest`, `preValidation`, `preHandler`, `onSend`, ecc.) con un ordine di esecuzione ben definito. Express ha solo il concetto di middleware in sequenza — flessibile, ma meno esplicito su _quando_ nel ciclo di vita della richiesta un middleware interviene.

### Maturità ed ecosistema: dove Express vince ancora

Qui il vantaggio va nella direzione opposta. Express esiste dal 2010, è lo standard de facto di praticamente ogni tutorial, corso e domanda su Stack Overflow degli ultimi quindici anni. Per qualunque problema che incontri, la probabilità che qualcun altro l'abbia già risolto e documentato con Express è più alta. Il numero di middleware di terze parti pronti all'uso (auth, rate limiting, logging, integrazioni con provider specifici) è ordini di grandezza superiore. Se il tuo team ha già esperienza consolidata su Express, o stai integrando codice con librerie che assumono l'interfaccia dei middleware Express (`req, res, next`), il costo di adozione di Fastify va pesato contro un beneficio di performance che, come detto sopra, spesso non è il vero collo di bottiglia dell'applicazione.

### Tabella riassuntiva

|                                               | Express                            | Fastify                                               |
| --------------------------------------------- | ---------------------------------- | ----------------------------------------------------- |
| Performance HTTP pura                         | Buona                              | Superiore, specialmente con risposte JSON strutturate |
| Validazione richieste                         | Manuale (middleware terzi)         | Integrata via schema                                  |
| Plugin/incapsulamento                         | Middleware globali                 | Contesti isolati per plugin                           |
| TypeScript                                    | Supportato, non nativo             | Pensato per TS fin dal design                         |
| Ecosistema/community                          | Il più grande dell'ecosistema Node | Solido, ma più piccolo                                |
| Curva di adozione per team esperti su Express | Nessuna                            | Bassa-media                                           |

### Quando scegliere cosa

**Express** resta la scelta giusta quando il team lo conosce già bene, il progetto si appoggia a middleware specifici disponibili solo per Express, o la velocità pura delle risposte HTTP non è mai stata un vincolo reale del progetto — la maggioranza dei CRUD interni e delle API a basso traffico rientra qui.

**Fastify** conviene per API ad alto throughput dove la serializzazione JSON pesa davvero, per progetti TypeScript-first dove vuoi che gli schema di richiesta/risposta siano anche la fonte di verità per i tipi, o per architetture modulari grandi dove l'incapsulamento dei plugin previene una classe intera di bug da stato condiviso non voluto.

Se hai scelto Fastify, la guida [Creare una REST API con Fastify e TypeScript](https://diegobetto.com/fastify-rest-api-typescript/) copre setup, routing e validazione con schema in pratica, partendo da zero.