support middleware and custom routes

[dai-shi]

split from #329.

This will be some refactors/re-architect mostly internally.

[aheissenberger]

my wishlist for the middleware & server context:

• add multiple middleware from configuration file or programmatically
• middleware can access, manipulate the request, extend the context before and after WAKU
• there is a way to access (and manipulate??) the request and the context from any server component

Use Cases:

• Auth
• Sessions
• mobile browser detection, user location (extra header from AWS gateway)
• setting the http caching, policy and CORS headers

[dai-shi]

Thanks for the feedback!

• add multiple middleware from configuration file or programmatically

Yes, I have that requirement in my head. Haven't decided how to configure them.

• middleware can access, manipulate the request, extend the context before and after WAKU

Yes, I have that too.

• there is a way to access (and manipulate??) the request and the context from any server component

Yes but only the context (you need your own middleware to interact with request and response. we probably provide cookie middleware by default.), with a limitation that the context is locked after starting the stream (not different from now).

[dai-shi]

middleware can access, manipulate the request, extend the context before and after WAKU

One correction: Now, as we try to hide Hono for user-facing api, I'm not sure if we can expose the request and response objects, maybe only headers.

[aheissenberger]

middleware can access, manipulate the request, extend the context before and after WAKU

One correction: Now, as we try to hide Hono for user-facing api, I'm not sure if we can expose the request and response objects, maybe only headers.

as long as I can use a middleware to grab some values from the request and add it as a new property to the context this should be no problem.

Maybe there is a way for a server component to register a middleware? But I would not look at this without a use case.

[dai-shi]

grab some values

what would be such values other than headers, for example?

[aheissenberger]

In an AWS Lambda environment the handler gets an event object and a lambda context. The lambda object has a method to check for the remaining time before the process gets killed and some other properties (use case: long running server processes - >30 seconds) .

Currently I think that accessing the header, the custom context and some helper functions like (e.g. respondWith to handle Errors and Redirects) from a server component should be enough. I looked at hono and h3 - h3 has the most minimalistic api - which could be an inspiration.

Cookies helpers should be optional functions with tree shaking support.

Access to the body, Method is only relevant, for API endpoints.

[dai-shi]

with tree shaking support.

That's a good requirement for designing apis.

[dai-shi]

Done with four PRs.

Please see rsc-basic fixture to disable SSR middleware (equivalent to no --with-ssr in v0.19.4 and before.)
Please see examples/08_cookie to add custom middleware.

There are no examples for custom routes/api, but hope someone tries it. We won't be working on #329 very soon (or never), and we want feedback with this in the meantime.

There are some unfortunate hacks like DO_NOT_BUNDLE. Please bare with them, and suggestions are also welcome.