[soulchild77]

I created a pet project (REST API) with Hono and I'm seriously considering using it for future projects instead of what has been my go-to stack for years (Express, lately with Zodios).

Hono's middlewares, especially zod-openapi[1] and @scalar/hono-api-reference[2], make it really easy to define your REST endpoints once and get full typesafe routes with request/response validation, an automatic OpenAPI spec, a beautiful OpenAPI browser and you can even reuse the typings in your frontend with Hono's RPC[3] middleware, essentially giving you end-to-end type-safety without any code-generation.

Its maintainer yusukebe is a really nice guy who is always being helpful and very active. I want Hono to become the modern successor of Express. :)

[1] https://hono.dev/snippets/zod-openapi

[2] https://www.npmjs.com/package/@scalar/hono-api-reference

[3] https://hono.dev/guides/rpc

[lioeters]

> request/response validation

> beautiful OpenAPI browser

> end-to-end type-safety without any code-generation

That's a great sales pitch - I'd looked at Hono before but now I've opened all the links you mentioned and will try it out.

[franciscop]

I'm very curious, I'm learning from both HonoJS and ElysiaJS about how to build a great next-generation library, and the thing that strikes me from Hono is that it seems it has integration for a lot of things, BUT you have to write a lot of manual code for those instead of "extending the base Hono" so to speak. For the `zod-openapi` example you gave, I'm looking at the docs and it seems there's no import in common from hono to hono/zod-openapi project:

    import { z } from '@hono/zod-openapi'
    import { createRoute } from '@hono/zod-openapi'
    import { OpenAPIHono } from '@hono/zod-openapi'

I would have expected/hoped things to be more integrated, e.g. you still do `import { Hono } from 'hono'` and then somehow you connect to this OpenAPI middleware. Any thoughts on this? Do you feel like moving from "base Hono" to use hono/zod-openapi you have to change how you do things? Another place I've seen this pattern is with the different edges, you have different import/exports, which I understand to certain degree but I still think a bit more could be done at the base library.

[soulchild77]

That's actually something I find a bit awkward, too. Especially, there was no way to re-use the global Hono error handler for all OpenAPI routes. I created an issue[1] with my suggested workaround and was told that that's the way to go. Maybe things are that way because `zod-openapi` was introduced later on. But I believe in the end it doesn't really matter that much as the code is clean and readable. :)

[1] https://github.com/honojs/middleware/issues/323#issuecomment...

[franciscop]

> "in the end it doesn't really matter that much as the code is clean and readable"

The thing I'm worried about is the behaviour differences of having 2 different ways of importing things, exactly as it seems you found. That's valuable feedback, thanks!

[sqwxl]

We are using a similar stack. I assume your client is located in the same repo as your server? That's a no-go for us, so we're planning on using the OpenAPI spec to generate a type-safe frontend client. I kind of wish it was as easy as using the RPC middleware, though.

[soulchild77]

In cases where the client needs to stay separate, we have had a good experience with Orval[1] to generate a fully-typed @tanstack/query client from our OpenAPI spec.

[1] https://orval.dev/

[groothe1drr]

Was looking to do this the same with Hono. Need a basic REST API. Possible for you to share your code?