Open yusukebe opened 1 year ago
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 :)
Some other middlewares that would be great to have are;
@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.
Datadog!
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:
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.
WebSocket support.
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.
OpenAPI / Swagger support π
TRPC support would be great.
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: https://deno.land/x/oak_http_proxy@2.1.0
Proxy would be a great addition. Something as simple as this: deno.land/x/oak_http_proxy@2.1.0
..or reflare! https://github.com/xiaoyang-sde/reflare
session controller and MySql(MariaDB)
storage : awe-s3
Datadog for logs or some other 3rd party logging! π
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
Websockets, Reverse Proxy, Prometheus.
OpenAPI/Swagger support
openapi is really very important
Proxy would be a great addition. Something as simple as this: deno.land/x/oak_http_proxy@2.1.0
..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/oak_http_proxy@2.1.0
..or reflare! https://github.com/xiaoyang-sde/reflare
Now that reflare is gone, something needs to fill that space.
h3 can proxy requests.
JSON Schema validation for the serialization of a response's body - similar to the one in fastify
This could provide major performance enhancements.
A session middleware to use to replace expression-session
would be pretty handy, and a lot of people might need something like that.
Ah indeed, making a session middleware is good.
Rate limiting middleware that would use an in-memory store by default but would be extensible enough to allow using something like redis for example.
Rate limiting middleware that would use an in-memory store by default but would be extensible enough to allow using something like redis for example.
In-memory data store doesn't work for edge workers.
Cloudflare Queues. Currently doesnβt work with Hono. Would be great!
@o-az It seems like Cloudflare Queues do work with hono: https://github.com/orgs/honojs/discussions/1163#discussioncomment-6096815
Service workers/pwa/google workbox for use in client browser (though workbox has its own routing module)
Rate limiting middleware that would use an in-memory store by default but would be extensible enough to allow using something like redis for example.
In-memory data store doesn't work for edge workers.
Is there any workaround to this? I am thinking about making a rate limit middleware for Hono because I use it in many of my projects and a rate limiter would be great. Curious to know if any community member has already made one or if it's even worth pursuing.
Hey, I am working on a rate limiter in Hono for my project, @dickeyy if you are interested we can collaborate.
Hey everyone! π Excited to share that I've just launched hono-rate-limiter
β a middleware for managing rate limiting in Hono applications! Currently at version v0.1.1
, as I need to check If this works in multiple runtimes. Would love to hear your feedback and suggestions on it. Check it out - https://github.com/rhinobase/hono-rate-limiter
Hello! I want to use Swagger like this, it is so easy to use.
datadog
From v2.0.0, we can create 3rd party middleware. So far, the following 3rd-party middleware has been created.
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.