Per-route hook or middleware

[CaptainCodeman]

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

[coryvirok]

I think the new layout Middleware (+layout.server.js ?) solves this by letting you call await parent() and capturing the result.

Aside: Combining "layout" and "server" makes me cringe as a predominantly backend dev. I think Kit is what we get when front-end devs redesign backend systems and nomenclature. No judgement here, just highlighting the peculiarities.

Ps. I enjoy your blog

[CaptainCodeman]

I think the new layout Middleware (+layout.server.js ?) solves this by letting you call await parent() and capturing the result.

Hopefully, but I understood that to be part of the load mechanism for pages, rather than the server endpoints which is where I need it (e.g. on a fetch of the child endpoint only, after page navigation). I'll try things out when the new routing lands and see what works and if this still applies.

Aside: Combining "layout" and "server" makes me cringe as a predominantly backend dev. I think Kit is what we get when front-end devs redesign backend systems and nomenclature. No judgement here, just highlighting the peculiarities.

I don't think it's too bad - the server is server only which makes things clearer and layout is a templating thing, which can run on both server and client.

Ps. I enjoy your blog

Thanks! So many things to write, so little time ...

BTW: It's SvelteKit powered :)

[dummdidumm]

With the redesign, the parent endpoint would become a layout endpoint, whose data is automerged with the page data. #6056 will make rerunning load smarter so it doesn't rerun unnecessarily. I think this covers all use cases of this request, if I'm not mistaken.