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.
- The core backend team (
-
Timeline
- Implementation in MVP planned within 2 sprints (~4 weeks).
- Re-evaluation planned quarterly as the ecosystem evolves.