Hono v2.0.0

[stone pebble]

I haven't updated to 2.0.0 yet, but just wanted to say thank you for this framework cdnjs' API is now running on a Worker using Hono: https://github.com/cdnjs/api-server

[crisp trout]

Wow great!! I think it's the biggest project that uses Hono. I'm a grad, we can contribute yours.

[light fog]

Perhaps not the best place to ask, but wasn't sure it warranted an issue. If it does or that's the right place, let me know and I'll delete this and move it over to GitHub!

I have an API I'm mirroring so I can't change any of the endpoints since it needs to be compatible. I'm seeing this on the latest Hono (2.0.2) and Wrangler.

The question is essentially this: how do I express alternation within a regex when using the regex router? Using parenthesis causes Hono to throw a TypeError, so I'm not sure it's possible.

As an example, I have an endpoint mimicking compressed files on a disk. Let's assume the filename is always apple to make this simpler. There is a limited number of supported compression formats, so I'd like to be able to do something like:

const CompressionAlgorithmRegex = /br|xz|zst|bz2/;
app.get(`/:filename{apple.(${CompressionAlgorithmRegex.source})}`, (c: Context) => c.text(`GET /${c.req.param("filename")}`))

to have paths which aren't supported routed to a 404. (As an aside: is this a bad design decision? Should I provide an informative error and use a different HTTP code?)

When I try this, I see the following

[mf:err] GET /apple.xz: TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))
    at ee.match (/private/Users/connorbaker/Packages/cloudflare-nix-cache/node_modules/.pnpm/[email protected]/node_modules/hono/dist/router/reg-exp-router/router.js:227:46)
    at ee.match (/private/Users/connorbaker/Packages/cloudflare-nix-cache/node_modules/.pnpm/[email protected]/node_modules/hono/dist/router/reg-exp-router/router.js:237:21)
    at ae.matchRoute (/private/Users/connorbaker/Packages/cloudflare-nix-cache/node_modules/.pnpm/[email protected]/node_modules/hono/dist/hono.js:95:28)
// snipped

Any ideas?

[crisp trout]

@light fog
Hi! How about writing like this:

const CompressionAlgorithmRegex = /br|xz|zst|bz2/
app.get(`/:filename{apple.(?:${CompressionAlgorithmRegex.source})}`, (c) => {
  return c.text(`GET /${c.req.param('filename')}`)
})

[light fog]

I'll give it a try later tonight when I'm off work -- thank you for the response 🙂
EDIT: May have to wait until the weekend first 😩
EDIT 2: After reading Walshy’s post about this not being the place for support, I’ll follow up in #coding-help if I need more help!

[harsh lodge]

@crisp trout I also love hono, and I'm building all of our apps/APIs with it now. I was just reviewing @stone pebble 's cdnjs code, and I noticed the only other library in the main index file was toucan ... have you considered adding Toucan as middleware like the graphql server? I am in the same situation where the 2 external libraries in most of our APIs are just hono and toucan ...

[crisp trout]

Hi! Is Toucan Sentry client? Making "Sentry Middleware" using Toucan is a good idea. It will be third-party middleware like a GraphQL Server, like you said. I did not have the plan to do it, but there is a possibility to do it. Or you make it?? If you can, we are welcome:) I've created the issue about it: https://github.com/honojs/hono/issues/423. Of course, if you're interested.

[stiff musk]

Update: nvm, I had misconfigured something in my custom auth middleware.

[crisp trout]

Solved?

[stiff musk]

Yes!

[stiff musk]

Curious, is there any way to somehow structure an API made with Hono to (auto) generate OpenAPI specs? This would help creating a typed client to communicate between workers / services.

[harsh lodge]

Have you seen https://www.useoptic.com ?

[stiff musk]

@harsh lodge This is pretty cool! Would be awesome to be able to define the OpenAPI specs within the code itself, kinda like https://github.com/lukeautry/tsoa but with workers / Hono.

[crisp trout]

Ah, it would be great if it could be done! Please create the issue to request the feature: https://github.com/honojs/hono/issues

[buoyant knot]

Great work Hono team!
keep the great work! saw graphql middleware coming (maybe some Hasura niceties later?) d1 and pubsub examples will be great

[stiff musk]

I've actually been using GraphQL Zeus to talk to Hasura from workers, which has been nice, since you basically get a fully typed ORM-like GraphQL client, you write queries as objects within your workers!

[buoyant knot]

great, thanks for the heads up! looks awesome

[buoyant knot]

I have to thank you again, how did I missed this zeus! thanks @stiff musk

[crisp trout]

Hi folks, you know, GraphQL Middleware is out!
https://github.com/honojs/graphql-server

[crisp trout]

Hi! Validator Middleware is available now! You can use it just like any other Middleware. Use it and give us feedback!
https://github.com/honojs/validator

[graceful sage]

@crisp trout hey, I see in your docs (https://honojs.dev/docs/getting-started/cloudflare-workers/#bindings) that bindings are in c.req.env but in the code sample, it uses c.env instead. Can you clarify? Also, does it work with Service Bindings?

[stiff musk]

I should be c.env, the code sample below is right, must have been a typo!

[crisp trout]

Sorry! c.req.env is a typo. The correct is c.env. And it should work with Service Bindings.

[graceful sage]

yep confirmed, thanks! also, request come with a cf property (https://developers.cloudflare.com/workers/runtime-apis/request/#requestinit) but I don't think Hono keeps it, does it?

[crisp trout]

Hono keeps cf property in Request. Hono uses Request object as it is, without conversion.

[obtuse turtle]

@crisp trout apologies if I'm missing something here: is there a way to extend context? For example, in middleware can I attach an item to the context, and then use it in the handler?

I tried typing (c: CustomContext) => {...handler} where CustomContext is my own context that extends Hono.Context but Typescript complains that it's not a valid handler.

[crisp trout]

Hi! The same thing was discussed in this Issue.
https://github.com/honojs/hono/issues/414

[obtuse turtle]

Oh wow, totally missed this! Thanks

[crisp trout]

The easiest way is to use c.set / c.get. This is not yet documented.

// I/we should write more documents!

[crisp trout]

Hey! I've created the Discord channel for Hono!!
Please use this for interaction within the user community, not only for development matters.
See this issue: https://github.com/honojs/hono/issues/483

[vast grail]

https://discord.com/invite/KMh2eNSdxV

The bot is a bit over-zealous but we think this is fine - posted it on your behalf @crisp trout

[crisp trout]

Thank you!

[zinc flint]

!!! love hono!

[forest ruin]

Hey guys. Anyone care to explain why one would pick hono over itty-router considering itty-router is 9x less package size

I really like hono just trying to understand. Also heard that the performance is the same between hono vs itty router regardless the hono performance report

[stone pebble]

itty-router is a router, hono is a full framework

[forest ruin]

If all I wanted was routing functionality, do you think itty router a better option?

Is the extra 400kb that big of a deal api response times

[obtuse turtle]

No.

400kb won't make or break anything

But also, you're very much:
a. measuring full bundle size. Tree-shaking significantly cuts the size which happens automatically with Workers or esbuild
b. aren't measuring it gzipped, which all Workers are (and if you're not running on a Worker then size doesn't usually matter)

[vast grail]

I was gonna say - a basic Hello World app in Hono is like 30kb / 8kb gzip

[obtuse turtle]

For reference, my unzipped bundle size increased by 30kb

Yeah

[crisp trout]

Hi, about performance, I think Hono is faster, but it's hard to compare in the case of Cloudflare Workers. For Deno and Bun, Hono is one of the fastest routers.

And about size, yes, the npm package size is 270 kb, but Hono basic application is 30kb. Most of them are middleware, and if you want to use middleware, just use it.

But, I think itty-router is also great! It's very small.

Hi there! We've released Hono v2.0.0! This release includes Deno and Bun support, cleaning up the API, adding new features, and others. Also, a new website https://honojs.dev/ is opened!!
https://github.com/honojs/hono/releases/tag/v2.0.0

[stiff musk]

Love using Hono! Good work on supporting the 'rest' of the communities too with Deno / Bun support!

[young cloak]

Any orm support ?

[keen cosmos]

Just played around with it, would love to see GraphQL support down the line!

[crisp trout]

Hono is just a web framework. It does not support ORM. You may use such as Prisma:
https://www.prisma.io/docs/guides/deployment/deployment-guides/deploying-to-cloudflare-workers

[crisp trout]

Yes! We are planning to make GraphQL server as middleware. It's coming soon!

[keen cosmos]

@crisp trout great to hear, you should add Hono to Stackshare, I'm sure you'd gain more traction with companies & devs promoting it there

[crisp trout]

I did not know Stackshare well, I'll check it, thank you!

[stiff musk]

@crisp trout hope you don't mind me asking here, I was cleaning up some workers of mine and saw that I had a custom global.d.ts to add the CF property types to the request of Hono. Is that still the recommended way to do that or what is the best way to approach this?

E.g. else I get the following:

[crisp trout]

For now, the way to extend the Request object, as you are doing, is better:

declare class Request extends Body {
  readonly cf?: IncomingRequestCfProperties;
}