Che cos'è il middleware (ciclo di vita della richiesta)?

Il middleware è una funzione della pipeline della richiesta che ispeziona o modifica richieste e risposte prima della logica della route. Due accezioni condividono la parola: quella più antica, aziendale (broker di messaggi e bus di integrazione tra applicazioni), e quella dei framework web di cui si occupa questa voce, cioè funzioni dentro una sola applicazione, attraversate in ordine da ogni richiesta. Express enuncia il modello senza giri di parole: un’app “è essenzialmente una serie di chiamate a funzioni middleware” – e l’ordine di quelle chiamate è, letteralmente, il programma.

Punti chiave

La pila, in ordine

// JavaScript / Node.js — Express + Parse Server
// Middleware: functions the request flows through, in registration order
const app = express();
app.use(helmet());                       // 1 · security headers
app.use(cors(corsOptions));              // 2 · CORS before anything that fails
app.use(express.json({ limit: '1mb' })); // 3 · body parsing, bounded

// Parse Server IS middleware — a whole backend mounted into the stack
app.use('/parse', new ParseServer(config).app);

app.use(notFoundHandler);                // 404 — after all routes
app.use(errorHandler);                   // error handler LAST (4 args)

// Flutter / Dart — Back4app Flutter SDK
// One SDK call — and the platform's middleware stack ran the gauntlet:
final response =
    await QueryBuilder<ParseObject>(ParseObject('Post')).query();
// Before your query touched data, the request passed through:
//   security headers → CORS → body limits → key check → session auth
//   → rate limiting → routing → (your beforeFind trigger) → the database
// You wrote none of it — that's the middleware a BaaS runs for you.

// iOS / Swift — Back4app Swift SDK
// One SDK call — and the platform's middleware stack ran the gauntlet:
let posts = try await Post.query().find()
// Before your query touched data, the request passed through:
//   security headers → CORS → body limits → key check → session auth
//   → rate limiting → routing → (your beforeFind trigger) → the database
// You wrote none of it — that's the middleware a BaaS runs for you.

// Android / Kotlin — Back4app Android SDK
// One SDK call — and the platform's middleware stack ran the gauntlet:
val posts = ParseQuery.getQuery<ParseObject>("Post").find()
// Before your query touched data, the request passed through:
//   security headers → CORS → body limits → key check → session auth
//   → rate limiting → routing → (your beforeFind trigger) → the database
// You wrote none of it — that's the middleware a BaaS runs for you.

Ogni posizione ha la sua ragione: gli header di sicurezza per primi (devono comparire su ogni risposta, errori compresi); CORS prima di tutto ciò che può fallire (altrimenti i browser mascherano l’errore vero); il parsing del body, limitato, prima delle route (altrimenti req.body vale undefined); l’autenticazione prima dell’autorizzazione (permessi verificati contro nessuno sono permessi concessi a chiunque); il rate limiting prima del lavoro costoso (un limitatore messo dopo la query sul database non protegge niente); il 404 dopo tutte le route; il gestore di errori proprio per ultimo.

La cipolla, disegnata correttamente

La metà che quasi tutte le spiegazioni omettono: la pipeline funziona nei due sensi. La documentazione di Django la disegna come una cipolla – ogni middleware è un livello attorno alla vista, al centro – e il codice che sta dopo la chiamata a next() (o dopo get_response) gira sul percorso di ritorno della risposta, in ordine inverso. È lì che si misurano i tempi di risposta, che gli header vengono apposti e che il logging registra quello che è davvero accaduto. Un livello che fa cortocircuito non salta solo l’handler; salta entrambe le metà di ogni livello interno – che è esattamente la garanzia per cui esiste una barriera di autenticazione.

Bug di ordine che arrivano in produzione

Il consiglio generico è “l’ordine conta”; i bug concreti sono più istruttivi. Autorizzazione prima dell’autenticazione: il controllo dei permessi gira contro un principal anonimo – 401/403 intermittenti, nessuna eccezione da nessuna parte, ore di debug. Body parser dopo le route: ogni handler vede req.body === undefined e dà la colpa al client. Auth prima di CORS: il browser blocca la risposta 401 stessa perché priva di header CORS, così il frontend vede un errore di rete invece di quello vero. File statici prima dell’auth: file privati serviti di buon grado a chi non è autenticato. Gestore di errori non per ultimo: gli errori lanciati dopo la sua posizione nella pila non lo raggiungono mai. Ognuno di questi bug supera uno smoke test sul percorso felice – i bug di ordine sono proprio quelli che arrivano in produzione.

Cortocircuito: quando non chiamare next() è il punto

Il contratto ha due uscite legittime: passare il controllo, oppure chiudere il ciclo. Chiuderlo presto non è un fallimento del middleware, è metà del suo lavoro: il 401 della barriera di auth, il 429 del limitatore, l’hit di cache, il reindirizzamento, il preflight CORS risolto sul posto. La regola che tiene onesta ciascuna delle due uscite: farne sempre esattamente una – rispondere, oppure next(). Non farne nessuna lascia la richiesta sospesa per sempre; farle entrambe genera errori headers-already-sent che confondono tutti a valle.

La stessa idea in ogni framework

Un modello, quattro accenti. Il percorso degli errori ha la propria convenzione in ogni framework: in Express la firma a quattro argomenti (err, req, res, next) è il meccanismo di registrazione, ed è per questo che cancellare un parametro “non usato” trasforma in silenzio il gestore di errori in un middleware ordinario che non scatta mai.

Middleware vs. gateway vs. hook

Tre livelli di intercettazione, un unico annidamento: il gateway sta davanti alla flotta, il middleware fa passare ogni app dalla propria batteria di controlli, e gli hook scattano dove le richieste diventano dati. Una preoccupazione appartiene al livello più esterno in grado di deciderla – limiti globali al gateway, auth di sessione nel middleware, “questa scrittura è valida?” nell’hook.

Casi d’uso tipici

• Autenticazione e gestione delle sessioni – stabilire l’identità una volta sola, presto, per tutto quello che segue.
• Igiene trasversale – CORS, header di sicurezza, compressione, ID di richiesta.
• Disciplina degli input – parsing del body con limiti di dimensione, controllo del content-type, validazione.
• Osservabilità – logging e misurazione dei tempi attorno a tutta la pipeline, via il percorso di ritorno della cipolla.
• Protezione del traffico – rate limiting e barriere anti-abuso che fanno cortocircuito prima che il costo venga sostenuto.

In quale livello sta questa cosa? Matrice decisionale

Limiti e trade-off

• L’ordine è invisibile finché non lo è più. La pila si legge dall’alto in basso ma fallisce in modi che puntano da ogni altra parte; la registrazione dei middleware va trattata come codice portante, da sottoporre a revisione.
• Ogni livello tassa ogni richiesta. Dieci middleware da 2 ms ciascuno sono 20 ms su ogni risposta; la pila si misura come si misurano le query.
• Lo stato globale è una trappola. Il middleware gira in concorrenza su più richieste; qualsiasi stato mutabile condiviso diventa una race condition – i dati propri della richiesta vanno attaccati all’oggetto richiesta, e in nessun altro posto.
• Le pipeline nascondono il flusso di controllo. Un livello che fa cortocircuito tre posizioni più sotto può spiegare perché una route “non gira mai”; la mossa di debug è sempre la stessa: stampare la pila, in ordine.
• Non tutto è una questione di pipeline. La logica di business infilata di nascosto in un middleware vincola a sé ogni route; la pipeline serve alle preoccupazioni trasversali, non a quelle centrali.

Il middleware su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Qui la relazione è di una letteralità rara: il server di Back4app è esso stesso un middleware Express – la scheda JavaScript lo mostra montato con app.use('/parse', …) in una pila standard – e la piattaforma esegue la batteria canonica per ogni richiesta: header di sicurezza, CORS, parsing limitato, verifica delle chiavi, autenticazione di sessione e rate limiting, nell’ordine giusto, mantenuti come infrastruttura. La logica personalizzata per singola richiesta va poi dove indica la matrice decisionale, invece che in codice di pipeline fatto a mano: i trigger beforeSave/beforeFind per le regole vicine ai dati, le Cloud Functions per le operazioni – ciascuno con il contesto utente della richiesta già attaccato, che è gran parte di ciò che un middleware su misura ha sempre voluto sapere.