Cos'è Hono e perché gira ovunque

Scrivi un'API con Express, poi decidi di pubblicarla su Cloudflare Workers e scopri che non funziona: quel framework presuppone un ambiente Node che lì non c'è. È il problema che nasce quando il codice è legato a una piattaforma invece che a uno standard. Hono parte esattamente da lì. In questo articolo trovi come funziona, perché gira ovunque e quando conviene davvero.

Cos'è

Hono è un framework web leggero costruito sulle API standard del web — Request e Response — e per questo gira senza modifiche su Node, Cloudflare Workers, Deno, Bun e le piattaforme edge.

La differenza rispetto ai framework tradizionali sta nelle fondamenta. Express è costruito sugli oggetti di richiesta e risposta di Node: funziona dove c'è Node. Hono usa gli oggetti standard che il browser e le piattaforme moderne conoscono già.

La conseguenza pratica: lo stesso file si pubblica su un server tradizionale o su una piattaforma edge cambiando poche righe di configurazione.

import { Hono } from "hono";

const app = new Hono();

app.get("/ordini/:id", async (c) => {
  const ordine = await trovaOrdine(c.req.param("id"));
  if (!ordine) return c.json({ errore: "Non trovato" }, 404);
  return c.json(ordine);
});

export default app;

Un solo oggetto contesto (c) invece della coppia richiesta/risposta, e la risposta si restituisce invece di scriverla. È il modello delle piattaforme edge, non quello dei server tradizionali.

Perché la portabilità conta

Potrebbe sembrare una comodità teorica. Non lo è, per due ragioni concrete.

La prima: non decidi tutto all'inizio. Cominci su Node perché è ciò che conosci, e più avanti scopri che una parte dell'API avrebbe senso più vicina agli utenti. Con Hono sposti il codice; con Express lo riscrivi.

La seconda: lo stesso codice in ambienti diversi. Sviluppi in locale su Node o Bun e pubblichi sui Workers, senza mantenere due versioni.

Il limite da conoscere, però, è reale. Portabile è il framework, non tutto ciò che ci metti dentro. Se importi una libreria che usa il file system o moduli specifici di Node, quel codice non gira sull'edge — il framework non ci può fare nulla. È lo stesso vincolo descritto in cosa sono i Cloudflare Workers, e vale la pena verificarlo prima di progettare l'architettura attorno alla portabilità.

Leggerezza e velocità

Hono è piccolo — l'ordine di grandezza è decine di kilobyte, non megabyte — e questo conta specificamente sulle piattaforme edge, dove il codice viene caricato a ogni avvio a freddo e il peso incide sui tempi.

Il suo instradatore è ottimizzato per risolvere le rotte molto rapidamente. Vale però l'avvertenza già fatta per Fastify: nella maggior parte delle applicazioni il tempo se ne va nel database, non nel routing. La leggerezza è un vantaggio vero nel contesto edge; altrove è marginale.

Cosa trovi dentro

Pur essendo minimale, copre ciò che serve davvero per un'API:

Middleware nello stile a cipolla, familiare a chi ha usato framework simili:

app.use("/admin/*", async (c, next) => {
  const token = c.req.header("Authorization");
  if (!valido(token)) return c.json({ errore: "Non autorizzato" }, 401);
  await next();
});

Validazione con controllo dei tipi, integrabile con le librerie di validazione più diffuse. I tipi si propagano al gestore: c.req.valid("json") è tipizzato correttamente, il che con TypeScript fa una differenza concreta.

Middleware inclusi per le cose ricorrenti: CORS, compressione, cache, autenticazione di base, log, limitazione delle richieste.

Un client tipizzato: dal tipo dell'applicazione puoi generare un client che conosce rotte e forme dei dati, e un endpoint rinominato diventa un errore di compilazione invece di un bug scoperto in produzione.

Rendering JSX lato server, utile per pagine semplici senza montare un framework frontend.

Dove ha più senso

Sulle piattaforme edge è la scelta naturale. È nato lì ed è il framework che l'ecosistema Cloudflare assume di più.

Per API che stanno davanti a un database gestito, magari raggiunto via HTTP: è lo schema classico di un backend moderno leggero.

Per microservizi e funzioni piccole, dove il peso dell'avvio conta.

Per un backend che accompagna un frontend moderno, quando non vuoi la struttura di NestJS ma vuoi i tipi condivisi.

Meno adatto a backend con molta logica, elaborazioni lunghe o dipendenze pesanti: lì un server tradizionale su VPS o container resta più sensato, e il vincolo è quello descritto in edge computing.

Errori comuni

Dare per scontato che le librerie Node funzionino sull'edge. L'errore numero uno. Verifica le dipendenze prima di scegliere la piattaforma, non dopo.

Progettare per la portabilità senza averne bisogno. Se sai già dove pubblicherai e non cambierà, la portabilità non ti sta dando nulla: scegli in base ad altro.

Aspettarsi l'ecosistema di Express. Hono è giovane: meno pacchetti, meno esempi, meno risposte già scritte quando ti blocchi. È il vero costo, ed è più rilevante della tecnica.

Usarlo per un backend pesante. Se l'applicazione fa elaborazioni lunghe, l'ambiente edge ha limiti stretti di tempo di esecuzione. Il framework non li aggira.

Confondere c.req.query() con i parametri di percorso. Dettaglio minimo, ma è il primo inciampo di chi arriva da Express.

Hono, Express o Fastify

	Hono	Express	Fastify
Gira su edge	Sì	No	Parzialmente
Peso	Minimo	Medio	Medio
Ecosistema	Piccolo	Enorme	Buono
TypeScript	Ottimo	Aggiunto	Ottimo
Maturità	Giovane	Massima	Buona
Client tipizzato	Sì	No	No

Hono se pubblichi sull'edge, o se vuoi tenerti la possibilità aperta.

Express se vuoi la massima quantità di materiale trovabile e resti su un server tradizionale.

Fastify se stai su Node e vuoi validazione e prestazioni senza vincolarti all'edge.

In sintesi

Hono è un framework leggero costruito sugli standard del web invece che sulle API di Node, e per questo gira praticamente ovunque senza modifiche.

Il vantaggio vero non è la velocità ma la portabilità, che si traduce in una decisione rimandabile: scegli la piattaforma dopo, non prima.

Ma la portabilità riguarda il framework, non le tue dipendenze. Una libreria che richiede il file system resta un vincolo sull'edge: verificalo presto.

Il costo è l'ecosistema. È giovane: meno risposte pronte quando qualcosa non funziona, ed è questo — più di ogni considerazione tecnica — il motivo per cui su un progetto di lavoro potresti comunque scegliere altro.

Se stai valutando dove pubblicare, il quadro è in cosa sono i Cloudflare Workers e in edge computing.