You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's easy to spot that at every level in this path, I could do some checks and build up some context. These steps could be very small and simple to manage:
(authenticated) could check whether the user is logged in
(@admin) could check the role of the currently logged in user and behave differently for different roles
[system] could add a connection to some external API to the context of the request
[table] could do some check regarding authorization, and e.g. restrict certain tables
Right now, there are two options to partially create such an API. However, route groups and parallel routes are still not covered by these options:
I could build a very big middleware.js that will have a long list of checks, covering all possible combinations in the worst case
I could create very big leaf route.js functions that handle all checks down the tree, these route handlers will have a lot of responsibilities, all in one file
Proposal
Next to route.js files, you should be able to create file-system based nested middleware.js functions. As a result, you should be able to utilise route groups, spread operators and parallel routes in your API design.
A middleware.js file should be called before any of its children are called. It should be able to do everything the middleware.js file can do right now. Children of such a middleware function can be either other middleware functions, or leaf route handlers. In the end a route handler will get a request and the entire context that has been build up by all ancestor middlewares, before the response is sent down the tree again, via the chain of middlewares back to the front-end.
As a final note, this proposal kind-of translates the combination of page.js and layout.js to API files.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Goals
Non-Goals
Background
Let's say I want to build the following API:
src/api/(authenticated)/(@admin)/[system]/[table]/[…options]
It's easy to spot that at every level in this path, I could do some checks and build up some context. These steps could be very small and simple to manage:
Right now, there are two options to partially create such an API. However, route groups and parallel routes are still not covered by these options:
middleware.js
that will have a long list of checks, covering all possible combinations in the worst caseroute.js
functions that handle all checks down the tree, these route handlers will have a lot of responsibilities, all in one fileProposal
Next to
route.js
files, you should be able to create file-system based nestedmiddleware.js
functions. As a result, you should be able to utilise route groups, spread operators and parallel routes in your API design.A
middleware.js
file should be called before any of its children are called. It should be able to do everything themiddleware.js
file can do right now. Children of such a middleware function can be either other middleware functions, or leaf route handlers. In the end a route handler will get a request and the entire context that has been build up by all ancestor middlewares, before the response is sent down the tree again, via the chain of middlewares back to the front-end.As a final note, this proposal kind-of translates the combination of
page.js
andlayout.js
to API files.Beta Was this translation helpful? Give feedback.
All reactions