honojs
[Discussion] What middleware do you want?
From v2.0.0, we can create 3rd party middleware. So far, the following 3rd-party middleware has been created.
- GraphQL Middleware
- Firebase Auth Middleware
- Validator Middleware
- Sentry Middleware
GraphQL Middleware was originally provided as Built-in Middleware, which I also use. Firebase Auth make more authentication options for Cloudflare Workers. Validator Middleware is my creation, and I like it. Sentry Middleware will be very helpful in catching errors at the edge.
Next, What middleware do you want?
If there is any Middleware you want, please comment here, even if you don't make it yourself. Someone may make it. You may also get other ideas by seeing the ideas here.
Error Handler. We should be able to throw exceptions anywhere in the code and the middleware should catch it, so that it can in turn handle it as a 500 error page, 404 error page or anything else, based on the error type.
Hi @rishavs !
Thank you for your comment. Are app.notFound and app.onError not enough? Indeed, Hono does not have the original Error objects.
// https://honojs.dev/docs/api/hono/#not-found
app.notFound((c) => {
return c.text('Custom 404 Message', 404)
})
// https://honojs.dev/docs/api/hono/#error-handling
app.onError((err, c) => {
console.error(`${err}`)
return c.text('Custom Error Message', 500)
})
Let me try them. I don't think they are documented anywhere right now.
The way I was handling errors was something like this;
// deno-lint-ignore-file
import { Hono } from 'https://deno.land/x/hono/mod.ts'
import {render} from "./../views/render.js"
import {postsList} from "./../views/pages/postsList.js"
const showPostsListPage = new Hono()
showPostsListPage.get('/', async (c) => {
try {
const page = await postsList()
var props = {
title: "Posts List",
description: "This here is the description of the post list page",
page : page
}
const view = render(props)
return c.html(view)
} catch (err) {
return c.html ("500 ERROR")
}
})
export {showPostsListPage}
and I had to put the try catch on every single route.
but app.onError seems to be exactly what I wanted. Thanks.
I don't think they are documented anywhere right now.
Yes, it is not well documented. We have to write better, cc: @ThatOneBro :)
@rishavs
Helmet would be nice.
Body parser and cookie parser are already included in the core.
https://honojs.dev/docs/api/context/#creq
// Parse cookie
app.get('/entry/:id', (c) => {
const value = c.req.cookie('name')
...
})
// Parse Request body
app.post('', async (c) => {
const body = await c.req.parseBody()
...
})
These are not documented well too.
Opentracing or similar (https://github.com/openzipkin/b3-propagation/blob/master/README.md)!
I'd love some non-3rd-party authentication middleware(s)! Just some simple register/signup that stores data in a database (bun's built in sqlite db's for example)
It could also extend to other best practices like GDPR compliance, session storage, forgot password, etc. It would save a lot of time, and the need for another completely unrelated library. (Featherjs in my situation, which also comes with its own http server)
Cloudflare R2 Bucket CRUD :)
Also more convenience around Durable Objects & WebSockets
Cloudflare R2 Bucket CRUD :)
Also a R2 pass-through middleware would be interesting, to serve and cache a R2 bucket as a static site. Something in the lines of kotx/render.
Hi @icrayix !
Thank you for using Hono.
apart from the kind of insufficient docs LOL
Ha, Ha. We have to write more good documents.
The thing I wanted to ask is the state of the already created 3rd-party middleware. I've already found the corresponding repo but that seems pretty empty.
There are some middleware managed in every independent repository:
- https://github.com/honojs/graphql-server
- https://github.com/honojs/sentry
- https://github.com/honojs/firebase-auth
We want to move these repositories to monorepo, this repository:
https://github.com/honojs/middleware
We can't do that yet. Nevertheless, the above monorepo has a minimal setup, so adding new middleware may be easy if we want to do so.
So yeah just wanted to know if any of the above-mentioned middleware has already been created?
No, not yet. Some of them are still in the idea stage, but others like tRPC could be implemented already
Just wondering, why is that?
Mainly the main maintainer (me) should do that, but I don't have time. I'm not a full-time open-source developer.
So is that repo actually open for contributions?
Yes, it's open. You can create PR for the repository.
It might sound strange, but I would prefer not to see more middleware. Since it's for workers which interprets code on the fly, it's IMHO better to be minimalistic rather than risking the bloat of having too many features. I find the current list of middleware really hits the sweet spot, and I would really think twice about adding something. I think it is very wise to keep the more exotic ones (especially connections to 3rd party services) in separate repositories like you did.
If there was one thing I'd say I miss, it's generating an OpenAPI spec out of the box, or through a middleware. Although I don't use them currently, I can see websocket support as a nice addition too.
Regarding the validation, that's one thing I'm not really a fan of. I prefer to validate in the endpoint itself using a more powerful lib like https://github.com/grantila/suretype where you get both the validation, the typing, can produce schemas, etc.
Hi!
Released "tRPC Server Middleware" now. Check it out!
https://github.com/honojs/middleware/tree/main/packages/trpc-server
Proxy would be a great addition. Something as simple as this: deno.land/x/[email protected]
..or reflare! https://github.com/xiaoyang-sde/reflare
HMAC signature validation for verifying webhooks akin to https://github.com/gr2m/cloudflare-worker-github-app-example/blob/dee1c7766065058fde2a8bf366f2f2b729ea2d3f/worker.js
Durable Objects tooling akin to hyper-durable
Proxy would be a great addition. Something as simple as this: deno.land/x/[email protected]
..or reflare! https://github.com/xiaoyang-sde/reflare Now that reflare is gone, something needs to fill that space.
Proxy would be a great addition. Something as simple as this: deno.land/x/[email protected]
..or reflare! https://github.com/xiaoyang-sde/reflare
Now that reflare is gone, something needs to fill that space.
h3 can proxy requests.