Sviluppatori Express.js Freelance Italiani

Express è ancora mantenuto o conviene guardare altrove?

È mantenuto, e l'idea contraria è un residuo di un periodo di stallo ormai chiuso.

La versione 5 è stata rilasciata e la serie 4 riceve ancora patch, con pubblicazioni recenti su entrambe le linee.
Il progetto è sotto la OpenJS Foundation, con governance ripristinata e nuovi manutentori.
È stato creato un gruppo di lavoro sulla sicurezza e il progetto partecipa al programma di gestione delle vulnerabilità della fondazione.

Gli autori hanno descritto la versione 5 come deliberatamente «noiosa»: nessuna rivoluzione, ma rimozione delle versioni obsolete di Node, sicurezza e semplificazione della manutenzione. Per chi ha applicazioni in produzione è esattamente quello che serve.

Express, Fastify o Hono: quale scegliere?

Premessa onesta: non esistono confronti ufficiali fra questi progetti, e i benchmark che circolano vanno letti come opinioni di mercato, non come dati certificati. Detto questo, i criteri pratici ci sono.

Express conviene quando: vuoi la massima disponibilità di sviluppatori, di esempi e di librerie compatibili. Chiunque abbia lavorato con Node lo conosce.
Fastify conviene quando: cerchi una struttura più opinionata e funzionalità integrate come la validazione degli schemi.
Hono conviene quando: il bersaglio sono ambienti di esecuzione leggeri e distribuiti.

Per un'applicazione aziendale ordinaria la differenza di prestazioni fra i tre è quasi sempre irrilevante rispetto al tempo speso nel database e nelle chiamate esterne.

La nostra API Express è diventata ingestibile: si può sistemare senza riscriverla?

Quasi sempre sì, ed è un intervento tipico. Il problema non è Express ma l'assenza di una struttura, che il framework non impone.

Separare i livelli: rotte, logica di business e accesso ai dati in posti distinti, invece che tutto dentro le funzioni delle rotte.
Centralizzare la gestione degli errori e la registrazione degli eventi, così che un problema in produzione sia diagnosticabile.
Validare gli input in un punto solo, con regole dichiarate invece che controlli sparsi.
Aggiungere test sulle parti critiche prima di toccarle, altrimenti ogni modifica è un salto nel vuoto.

Si fa in modo incrementale, mentre l'applicazione resta in produzione. Una riscrittura completa è quasi sempre la scelta più rischiosa e più costosa.

Come ci proteggiamo dalle vulnerabilità più comuni?

Con quattro accorgimenti che coprono la grande maggioranza dei casi reali e che vanno messi nel capitolato, non lasciati al buonsenso.

Validare ogni input con uno schema dichiarato: è la difesa contro la maggior parte degli attacchi di iniezione.
Intestazioni di sicurezza e politiche di origine configurate esplicitamente, non lasciate ai valori predefiniti.
Limiti di frequenza sulle rotte sensibili, a partire da quella di accesso.
Dipendenze aggiornate e verificate periodicamente: nelle applicazioni Node è la via d'ingresso più frequente.

Serve passare alla versione 5?

Non è urgente, perché la 4 riceve ancora correzioni, ma è la direzione giusta e conviene pianificarlo insieme a un altro intervento.

Cosa comporta: il cambiamento principale riguarda le versioni minime di Node supportate e alcune API modificate. Per un'applicazione ordinaria è un lavoro contenuto.
Quando farlo: insieme all'aggiornamento di Node, che comunque va fatto se sei fermo su una versione fuori supporto.
Cosa verificare prima: le librerie intermedie di terze parti, che sono quasi sempre il vero collo di bottiglia della migrazione.