Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support middleware and custom routes #513

Closed
Tracked by #24
dai-shi opened this issue Feb 20, 2024 · 8 comments
Closed
Tracked by #24

support middleware and custom routes #513

dai-shi opened this issue Feb 20, 2024 · 8 comments
Assignees

Comments

@dai-shi
Copy link
Owner

dai-shi commented Feb 20, 2024

split from #329.

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

@dai-shi dai-shi self-assigned this Feb 20, 2024
@dai-shi dai-shi changed the title support middleware and custom (non-React) routes support middleware and custom routes Feb 20, 2024
@dai-shi dai-shi mentioned this issue Feb 20, 2024
83 tasks
@aheissenberger
Copy link
Contributor

aheissenberger commented Feb 25, 2024

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
Copy link
Owner Author

dai-shi commented Feb 25, 2024

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
Copy link
Owner Author

dai-shi commented Feb 25, 2024

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
Copy link
Contributor

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
Copy link
Owner Author

dai-shi commented Feb 26, 2024

grab some values

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

@aheissenberger
Copy link
Contributor

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
Copy link
Owner Author

dai-shi commented Feb 26, 2024

with tree shaking support.

That's a good requirement for designing apis.

@dai-shi
Copy link
Owner Author

dai-shi commented Mar 5, 2024

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.

@dai-shi dai-shi closed this as completed Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants