support middleware and custom routes

dai-shi / waku

⛩️ The minimal React framework

https://waku.gg

MIT License

4.01k stars 104 forks source link

support middleware and custom routes #513

Closed dai-shi closed 2 months ago

dai-shi commented 3 months ago

split from #329.

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

aheissenberger commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

grab some values

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

aheissenberger commented 3 months ago

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 commented 3 months ago

with tree shaking support.

That's a good requirement for designing apis.

dai-shi commented 2 months ago

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.