Use itty-router Instead of Hono for the API Services?

[unibeck]

I am interested in the DX and performance compared to Hono.

[kwhitley]

Great, well I can hopefully answer both questions!

1. Ergo/DX - here's a simple apples/apples comparison:

Major differences between the two are this:

• Hono uses a context to contain everything, including response helpers, bindings, params, etc.
• Itty uses the request itself for this
• Hono sticks more closely to Express syntax, where itty strove to remove much of the boilerplate/verbosity
• Itty is many times smaller than any Hono flavor (that matters sometimes, not others)
• Itty allows additional args passed to router.fetch to propogate to all middleware/handlers, which allows Cloudflare env + context to pass automatically to all middleware/handlers
• Itty can chain any number of handlers in any route. The first one to return anything at all becomes the response. It's unconventional compared to express, but allows for much shorter route code unless you need particularly complicated middleware scenarios (most do not).

Hono

import { Hono } from 'hono'

const app = new Hono()

// middleware example
const addFoo = async (c, next) => {
  c.foo = 'bar' // add a variable to the context
  await next() // must await the next function like in express to continue handler execution
}

// basic route
app.get('/', (c) => c.text('Hello World!'))
  
// route params + middleware
// first register middleware using .use
app.use('/books/*', addFoo)

// then register the route itself
app.get('/books/:id', (c) => {
  const id = c.req.param('id')
  return c.json(`id=${id} and foo=${c.foo}.`)
})

export default app

import { AutoRouter, text } from 'itty-router'

const router = Router()

// middleware example
// any handler that doesn't return acts as middleware
const addFoo = (request) => {
  request.foo = 'bar' // in itty, we just use the request itself as a data transport  
}

// basic route
// we can return text directly without the text() helper, but it would be JSON encoded by default
app.get('/', () => text('Hello World!')) 
  
// route params + middleware
// you can include any number of handlers/middleware, and we can extract id and foo directly out of the request
app.get('/books/:id', addFoo, 
  ({ id, foo }) => `id=${id} and foo=${c.foo}.` // automatically returns as JSON
)

export default router // if your version of wrangler doesn't like this, simply destructure like this
// export default { ...router }

2. Performance... This is a fun one...

If you look here https://hono.dev/docs/concepts/benchmarks, you'll see some rather misleading benchmarks from the early days of Hono's marketing. These pit two speed-optimized flavors of Hono against various routers, including and early version of itty.

The problem is twofold:

First, these are not the routers anyone actually uses in Hono (they aren't the default one you import). The fastest one they use as a comparison is a tree-optimized router, which of course is faster, but not how most folks actually want their router to operate (because we want middleware to dynamically affect downstream routes, so we don't actually want to precompute a path/LUT).

The bigger issue is this: these are all so incredibly fast that there is essentially zero router overhead in any of them, period. You're essentially talking about 0ms of route matching per requests in all of them. Less of a zero becomes kinda pointless besides a theoretical debate! Even in a standalone microservice (Bun/Node), your own route code or IO will be the reason your request throughput is slow, not the route matching itself. In serverless environments like Workers, it becomes even more meaningless, because a single Worker will not be processing all traffic at once, as it is automatically fanned out to handle incoming requests.

2b. Other performance (e.g. CPU/wall clock time).

This is a bit more interesting (although still more theoretical and your mileage may vary - ultimately I'd say none of the performance stuff matters THAT much, and just choose the router you like the ergo of that has the features you need).

Itty is small. Really really really small. Our biggest batteries-included router (AutoRouter) shown above is 1/4 the size of the smallest Hono router (that no one uses, because again, it's not the default router - it's just the one they use when comparison sizes to other routers). As a result, the spin up time of Workers can arguably be slightly faster (smaller code bundle to unpack and execute). A user has done some metric tests you can see here, and I've recreated these with similar (but still close) results on my own:

https://github.com/TigersWay/cloudflare-playground

The results? Hono used about 2.6ms of CPU time per execution, itty was 0.7ms. Baseline (no routing at all) was 0.5ms. So itty is ~0.5 times "slower" than native/no-router, and Hono was about 5 times slower. Again, i'd take all this with a grain of salt, but if cost savings on Workers is a metric you're aiming to tout, itty will arguably get you closer :)

[unibeck]

Great write up. 100% will POC itty-router. Cost savings probably won't be considerable given that each million CPU milliseconds costs 2 cents. Even so, I'm a sucker for performance tuning!