Per-route hook or middleware #5763
Description
Describe the problem
Occasionally, I have a need to load some data in an endpoint and then re-use some of that data in a child endpoint. There's currently no way to pass the parent data down to the child on the server-side other than indirectly via the rendering system, and in some cases that data shouldn't go to the client at all and / or would add unnecessary bloat to the page payload.
To paint a more concrete picture of a scenario, imagine a forum system ...
/routes/topic/[id]/__layout.svelte Renders the topic title, author, summary, date, reply count etc...
/routes/topic/[id]/index.ts Is the endpoint for the topic data
/routes/topic/[id]/[slug]/index.svelte Renders the paginated posts in the topic
/routes/topic/[id]/[slug]/index.tx Is the endpoint for the post data, it uses the page number from the url + a slice of the post references on the topic to fetch
How to re-use the data from the parent endpoint, in the child endpoint, without passing it through the page (which doesn't need it).
Describe the proposed solution
What I'd like to have is the ability to hook into the request at any level, to pass data down. Exactly like the current hooks, which only runs at the root app level. Or maybe it could work like the new load system is going to, where a child can await a parent ... but on the server side for endpoints (?).
Alternatives considered
Right now I get around it by using a sequenced handler in the app-level hooks, to check for a particular routeId prefix, do the data fetch there, put it into locals and then have access to it in both places.
But it feels odd that I can't use the routing system to do something so routing-related, and I didn't see anything in the new routing proposal that would address it.
Importance
nice to have
Additional Information
It's not possible to add anything to locals from the parent endpoint AFAICT (I guess 'cause it's a child request at that point?)
It's a fairly normal NoSQL approach to embed references to a list of things in a parent as it saves on expensive queries (esp. with offsets when using paginated data).
Avoiding unnecessary reads of the parent data is also beneficial, it would only be 1 but it's additional cost when charged per-read and adds to overall request latency.
This kind of thing has been trivial to do when writing server APIs in Go, but hasn't translated well to a SvelteKit powered API.
Running and accessing a caching server on Google Cloud from Cloud Run is surprisingly complicated and expensive. Per-instance caching would be problematic on an auto-scaling platform (for cache invalidation) so reading per-request is the best compromise.
Related to: #3881