Hono

Hono is a routing library, not a framework in the sense that word usually carries. It matches a request to a handler, gives that handler a typed context object, and runs a middleware chain around it. That is the whole product, in about twenty kilobytes with no dependencies. There is no ORM, no dependency injection container, no code generator, and no opinion about how you arrange your files. It runs anywhere the runtime understands fetch-style requests and responses, which is why it turns up on Workers, Deno, Bun and Node alike.

How we use it

It is the HTTP layer of every Worker API we have written by hand. In Objectify it fronts the versioned REST API, with middleware doing the work that has to happen before any route sees the request: resolving a scoped API key to a tenant, checking plan quotas, applying a per-tenant sliding window rate limit and picking the database shard. In atHeartbeat it carries twenty-one route files inside one Worker, with a security middleware layer applying the content security policy, HSTS and tiered rate limits to everything at once. ClassProfile has the heaviest single file of the three: an authentication router of about eleven hundred lines covering password sign-in, magic links, verification, reset and refresh token rotation, with the rate limit counters held in a key-value store.

What it costs you

Having no opinions is the cost as well as the appeal. Two people will produce two unrelated codebases and both will be idiomatic Hono. On atHeartbeat we had to invent our own service layer conventions, a base service with per-domain services above it, because nothing arrived with one, and that convention lives in our heads and a readme rather than in the framework. On a team that changes hands often, that matters.

The type inference that makes chained routes pleasant also produces very large union types, and on a big route tree the editor gets slow before the compiler does. Splitting routes across files helps, and is worth doing before it becomes annoying rather than after.

The middleware ecosystem is thinner than Express or Fastify. There is a Hono version of most things you need, but when you want a specific authentication provider, an OpenAPI generator or a session store, expect to write a thin adapter yourself rather than install one. That is usually thirty lines, and it is thirty lines you now maintain.

Finally, it does nothing to save you from the runtime underneath. A promise you forget to await still gets cancelled when the response is sent. Hono will not warn you, because Hono does not know.

When we would choose something else

For a team that wants the arrangement decided for them, or a service large enough that consistency beats brevity, NestJS is the honest trade: much more ceremony, much less argument. Where the product is already a Next.js application, we usually skip Hono entirely and use the framework's own route handlers, which is what DMARC Engine and Jonosakti do, because one deployment with one router in it is simpler than two even when the second router is nicer. Details of that setup are on the Next.js page. On a long-running Node server with no edge constraints, Fastify has the deeper plugin ecosystem and we would not argue for Hono there on merit.