Skip to main content

Choosing Hono as the Backend Framework

· 2 min read

We decided to use Hono as the backend framework for our application.

Why did we make this decision?

Several popular Node.js frameworks were evaluated: Hono, Fastify, Express, @hapi/hapi, Restify, Koa, and NestJS. The following factors contributed to the selection of Hono:

  • Performance

    • Built on Web Standards and optimized for Edge and serverless runtimes.
    • Benchmarks show it consistently outperforms Express, Koa, and even Fastify in some scenarios.
  • Modern API and simplicity

    • Small, composable API reminiscent of Express.
    • Cleaner middleware composition, low overhead, and minimal boilerplate.
  • Built-in TypeScript support

    • Excellent type inference and developer experience out-of-the-box.
  • Edge-first and lightweight

    • Ideal for serverless or edge environments (Cloudflare Workers, Bun, Deno).
    • Tiny bundle size (~20kB) benefits startup time and cold starts.
  • Architectural flexibility

    • Does not impose opinionated patterns like NestJS.
    • Easily supports custom architectures like DDD and CQRS.
  • Lower learning curve

    • Minimal concepts to learn compared to NestJS or @hapi/hapi.
    • No need for decorators, DI containers, or heavy scaffolding.
  • Ecosystem and maintenance

    • Actively developed with growing community.
    • Built-in support for CORS, validation, JSX SSR, and many plugins.

What is the impact?

  • Codebase

    • More concise and readable API code.
    • Encourages functional, minimalistic design.
  • Team productivity

    • Fast onboarding due to simplicity and great TypeScript support.
  • Infrastructure readiness

    • Compatible with modern runtimes, future-proof for edge/serverless deployments.
  • Risks

    • Smaller community and ecosystem compared to more established frameworks.
    • Might require custom wrappers for some integrations.

What’s next?

  • Implementation

    • Initial API scaffold will be created using Hono, aligned with our DDD and CQRS architecture.
  • Responsibility

    • The core backend team (@team-backend) will be responsible for the implementation.
  • Timeline

    • Implementation in MVP planned within 2 sprints (~4 weeks).
    • Re-evaluation planned quarterly as the ecosystem evolves.