NestJS, c'est bien. Mais pas pour tout.
J'utilise NestJS tous les jours. C'est mon framework principal chez Orange Bleu pour les grosses API, les domaines complexes, les projets qui ont besoin de structure. Et je le recommande dans ce contexte-là.
Mais il m'arrive régulièrement de devoir monter un truc plus petit. Un webhook qui reçoit des events Stripe. Un proxy qui reformate des données entre deux services. Une API interne avec trois routes. Pour ce genre de besoin, sortir NestJS c'est comme prendre un semi-remorque pour aller chercher du pain. Ça marche, mais c'est un peu beaucoup.
Le setup NestJS, même minimal, c'est : un module, un controller, un service, de l'injection de dépendances, un main.ts
avec bootstrap. Pour trois routes, c'est du boilerplate qui ne sert personne.
Hono
J'ai découvert Hono en cherchant un truc simple pour un petit service interne. Le pitch : un framework web ultra-léger, qui tourne partout (Node, Deno, Bun, Cloudflare Workers, edge functions), avec un routeur rapide et du TypeScript natif.
Concrètement, une API Hono c'est ça :
import { Hono } from "hono";
const app = new Hono();
app.get("/health", c => c.json({ status: "ok" }));
app.post("/webhooks/stripe", async c => {
const body = await c.req.json();
// traiter l'event
return c.json({ received: true });
});
export default app;
Un fichier. Pas de module, pas de décorateur, pas de DI. C'est aussi simple qu'Express, mais sans devoir réinventer la roue à chaque projet : validation, CORS, auth, tout est déjà là en middleware officiel. Avec Express, on finit toujours par recréer le même boilerplate maison d'un projet à l'autre.
Ce que j'apprécie
La taille. Hono pèse rien. Le cold start est quasi-instantané, ce qui est un vrai avantage pour les edge functions ou les workers. Sur un VPS classique c'est moins critique, mais ça reste agréable de démarrer un service en quelques millisecondes.
Le typage des routes. Les handlers sont typés de bout en bout. Le body, les params, les query strings, tout ça peut être validé et typé avec des middlewares (Zod, par exemple). C'est pas aussi structuré que NestJS avec ses pipes et ses DTOs, mais pour un petit projet c'est largement suffisant.
Les middlewares. Il y a un écosystème de middlewares officiel assez complet : CORS, auth bearer, rate limiting, logger, etc. On compose ce dont on a besoin, sans embarquer le reste.
La portabilité. Le même code tourne sur Node, Bun, Deno, Cloudflare Workers. En pratique je l'utilise surtout sur Node derrière Docker, mais c'est rassurant de savoir que le code n'est pas verrouillé sur un runtime.
Ce que Hono ne fait pas
C'est pas un framework full-featured. Il n'y a pas d'injection de dépendances, pas de système de modules, pas d'architecture opinionnée. Et c'est le but.
Dès qu'un projet commence à avoir un vrai domaine métier, plusieurs couches, des besoins de testabilité avancés, je reviens vers NestJS. Hono n'est pas fait pour ça et ne prétend pas l'être.
Mon usage au quotidien
Chez Orange Bleu, on utilise Hono pour :
- Les webhooks (Stripe, services tiers)
- Les petits services internes (conversion, proxy, healthcheck)
- Les prototypes rapides avant de décider si le projet mérite un NestJS
Le pattern est toujours le même : un seul fichier ou un petit dossier, un Dockerfile de 10 lignes, et c'est déployé
sur Coolify en quelques minutes. Pas de setup, pas de config, pas de temps perdu.
Pour résumer
NestJS quand le projet le justifie. Hono quand il ne le justifie pas. Pas besoin de choisir un camp, les deux cohabitent très bien.
"scripts": {
- "start": "nest start",
- "build": "nest build",
+ "start": "node index.ts",
},
"dependencies": {
- "@nestjs/core": "^11.0.0",
- "@nestjs/common": "^11.0.0",
- "@nestjs/platform-express": "^11.0.0",
- "reflect-metadata": "^0.2.2",
- "rxjs": "^7.8.0",
+ "hono": "^4.0.0",
}