Hono, Fastify e FastAPI: Come Scegliere il Framework Backend Giusto

Hono, Fastify e FastAPI: Come Scegliere il Framework Backend Giusto

LE NOSTRE GUIDE

Pronto a imparare?

MarfCode · 10 aprile 2026 ·
Hono Fastify FastAPI backend framework

La scelta del framework backend è una delle decisioni tecniche con le implicazioni più durature in un progetto. Non si cambia facilmente: il codice cresce intorno ad esso, il team costruisce abitudini su di esso, le integrazioni dipendono da esso. Vale la pena farla con chiarezza.

In Marfcode lavoriamo con tre framework backend: Hono, Fastify e FastAPI. Non per mancanza di standard, ma perché ogni progetto ha requisiti diversi e usare lo strumento sbagliato ha un costo reale.


Il Principio di Base: Linguaggio e Contesto Prima di Tutto

Prima di confrontare i framework, la domanda più importante è: in quale linguaggio gira il backend, e perché?

  • Se il team è full-stack TypeScript e il backend gira su Cloudflare Workers → Hono
  • Se il team è Node.js con requisiti di throughput elevato e ecosistema plugin → Fastify
  • Se il backend integra logica Python, modelli AI o data processing → FastAPI

Non è una questione di quale framework sia “migliore” in assoluto. È una questione di quale sia più adatto al contesto. Forzare un framework Python su un team TypeScript, o viceversa, introduce attrito inutile.


Hono: Il Framework per l’Era Edge

Hono è un framework web TypeScript/JavaScript ultraleggero (< 15KB), progettato per girare su runtime non-Node.js: Cloudflare Workers, Deno, Bun, AWS Lambda Edge. Il nome viene dal giapponese per “fiamma” — veloce e leggero per design.

Perché esiste

Il problema che Hono risolve è semplice: i framework Node.js tradizionali (Express, Fastify) usano API che non esistono nei runtime edge. require(), fs, path, http — tutto il layer di Node.js non è disponibile su Cloudflare Workers o Deno. Hono usa solo Web Standard API (fetch, Request, Response, Headers), che funzionano ovunque.

Caratteristiche tecniche

Router basato su trie: routing ultra-veloce anche con centinaia di endpoint. Nei benchmark, Hono è tra i framework più veloci disponibili su qualsiasi runtime.

Middleware pattern: identico a Express (next() pattern), con middleware integrati per CORS, autenticazione JWT, rate limiting, validazione, logging.

Type safety: TypeScript first, con inferenza dei tipi sui parametri delle route e sui body delle richieste senza configurazione manuale.

RPC client: Hono può generare automaticamente un client TypeScript type-safe per le proprie API — eliminando la necessità di mantenere un layer API client separato nel frontend.

// Hono su Cloudflare Workers — esempio reale
import { Hono } from "hono";
import { zValidator } from "@hono/zod-validator";
import { z } from "zod";

const app = new Hono();

const createLeadSchema = z.object({
  nome: z.string().min(2),
  email: z.string().email(),
  budget: z.number().min(0),
});

app.post("/leads", zValidator("json", createLeadSchema), async (c) => {
  const data = c.req.valid("json");
  // data è completamente typed grazie a Zod
  const result = await createLead(data);
  return c.json(result, 201);
});

export default app;

Quando usare Hono

  • Il backend gira su Cloudflare Workers (deploy edge, latenza globale minima)
  • Il progetto è full-stack TypeScript e si vuole coerenza di linguaggio e tooling
  • Si costruiscono microservizi o API gateway leggeri
  • Il cold start è un requisito critico (Workers + Hono: cold start < 5ms)

Limiti

  • Ecosistema plugin meno maturo rispetto a Fastify
  • Non adatto per logiche CPU-intensive (limite del modello Workers)
  • Meno opzioni per ORM e database rispetto all’ecosistema Node.js completo

Fastify: Il Cavallo da Lavoro Node.js

Fastify è un framework Node.js costruito per performance e produttività. La filosofia è “tutto ha uno schema” — validazione degli input, serializzazione degli output e documentazione automatica sono derivati dallo stesso schema JSON.

Caratteristiche tecniche

Schema-driven: ogni endpoint definisce uno schema JSON per input e output. Fastify usa queste definizioni per validare automaticamente le richieste in ingresso e per serializzare le risposte in modo ottimizzato (3–5× più veloce della serializzazione JSON standard con JSON.stringify).

Plugin system: l’intero ecosistema Fastify è costruito su plugin con dependency injection integrata. La separazione tra responsabilità è strutturale, non convenzionale.

Performance: nei benchmark con Node.js, Fastify gestisce 30.000–60.000 richieste/secondo su hardware standard — significativamente più di Express (10.000–15.000 req/s).

OpenAPI automatica: con @fastify/swagger, la documentazione OpenAPI viene generata automaticamente dagli schema. Zero documentazione manuale da mantenere.

// Fastify — esempio con schema e plugin
import Fastify from "fastify";

const fastify = Fastify({ logger: true });

fastify.post(
  "/ordini",
  {
    schema: {
      body: {
        type: "object",
        required: ["prodotto_id", "quantita"],
        properties: {
          prodotto_id: { type: "string" },
          quantita: { type: "integer", minimum: 1 },
          note: { type: "string" },
        },
      },
      response: {
        201: {
          type: "object",
          properties: {
            id: { type: "string" },
            stato: { type: "string" },
            creato_il: { type: "string", format: "date-time" },
          },
        },
      },
    },
  },
  async (request, reply) => {
    const ordine = await creaOrdine(request.body);
    return reply.code(201).send(ordine);
  }
);

Quando usare Fastify

  • API Node.js con requisiti di throughput elevato
  • Progetti con ecosistema plugin Node.js (autenticazione, ORM, messaggistica)
  • Backend che gira su server tradizionale o container (non Workers)
  • Team con esperienza Node.js consolidata che non ha motivo di spostarsi su runtime edge
  • API che integrano sistemi esistenti Node.js (queue, job scheduler, WebSocket)

Limiti

  • Richiede Node.js (non gira su Cloudflare Workers nel modello standard)
  • La curva di apprendimento del sistema plugin è ripida per chi viene da Express
  • Per integrazioni Python/AI, rimane un sistema separato da orchestrare

FastAPI: Il Backend Python per l’Era AI

FastAPI è il framework Python moderno per API, costruito su Starlette (ASGI) e Pydantic. È diventato lo standard de facto per backend Python negli ultimi tre anni, superando Flask e Django REST Framework in adozione per i nuovi progetti.

Caratteristiche tecniche

Pydantic per la validazione: i modelli dei dati sono classi Python tipizzate con Pydantic. La validazione degli input, la serializzazione degli output e la documentazione OpenAPI sono derivati automaticamente dagli stessi modelli.

Async nativo: FastAPI è costruito su ASGI e supporta async/await in modo nativo. Operazioni I/O-intensive (chiamate a database, API esterne, file system) non bloccano il thread.

Documentazione automatica: FastAPI genera automaticamente Swagger UI e ReDoc dai modelli Pydantic. La documentazione interattiva è sempre aggiornata senza effort manuale.

Type hints ovunque: FastAPI usa i type hints Python per tutto — parametri di path, query parameters, body, response models. L’IDE sa esattamente cosa aspettarsi ovunque.

# FastAPI — esempio con Pydantic e async
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, EmailStr
from typing import Optional
import asyncio

app = FastAPI()

class AnalisiRichiestaInput(BaseModel):
    testo: str
    lingua: str = "it"
    modalita: Optional[str] = "standard"

class AnalisiRichiestaOutput(BaseModel):
    sentiment: str
    categorie: list[str]
    priorita: int
    sommario: str

@app.post("/analisi/richiesta", response_model=AnalisiRichiestaOutput)
async def analizza_richiesta(input: AnalisiRichiestaInput):
    # Chiamata asincrona a modello AI
    risultato = await modello_classificazione.analizza(
        testo=input.testo,
        lingua=input.lingua
    )
    return AnalisiRichiestaOutput(**risultato)

Quando usare FastAPI

  • Il backend integra modelli AI/ML (LLM, classificatori, modelli predittivi)
  • Si usa la libreria scientifica Python (NumPy, Pandas, scikit-learn, PyTorch)
  • Il team ha competenze Python consolidate
  • Il progetto richiede elaborazione dati complessa o ETL pipelines
  • Si costruisce un backend per sistemi di analisi predittiva o automazione documenti

Limiti

  • Performance inferiori a Hono e Fastify su puro throughput HTTP (ma sufficienti per la maggior parte dei casi)
  • Non adatto per deploy serverless edge (richiede un runtime Python completo)
  • L’ecosistema Python per applicazioni web tradizionali è meno maturo dell’ecosistema Node.js

Il Confronto Diretto

CriterioHonoFastifyFastAPI
LinguaggioTypeScript/JSTypeScript/JSPython
RuntimeEdge (Workers, Deno, Bun)Node.jsASGI (Uvicorn, Gunicorn)
Performance (req/s)~100.000+ (edge)~50.000 (Node)~10.000–20.000
Cold start< 5msN/A (sempre attivo)500ms–2s
EcosistemaIn crescitaMaturoMaturo (Python)
Integrazione AI/MLNoLimitataNativa
Deploy Cloudflare WorkersNativoNon standardNo
Validazione automaticaZodJSON SchemaPydantic
Documentazione OpenAPIManuale/pluginPluginAutomatica

Come li Combiniamo in Marfcode

In un progetto tipico con componenti multiple:

  • Frontend (Astro/SvelteKit) su Cloudflare Pages
  • API edge (autenticazione, routing, trasformazioni leggere) → Hono su Workers
  • Backend applicativo (logica business, integrazioni) → Fastify su VPS/container
  • Backend AI/data (elaborazione testi, predizioni, automazioni) → FastAPI su VPS/container

Non è sempre necessaria questa separazione — per molti progetti una singola API Hono o FastAPI è sufficiente. Ma quando il progetto cresce, avere componenti con responsabilità separate paga in termini di scalabilità e manutenibilità.

Definisci l’architettura giusta per il tuo progetto con Marfcode


Articolo correlato: Cloudflare come piattaforma di deploy | Sviluppo Web e Mobile per PMI: guida completa