A way to provide info from platform request to application

[benmccann]

Describe the problem

There are things on the original platform request that are needed in SvelteKit and can't be accessed today. E.g. some Node middlewares stick things on the request and the user may need to access them, Cloudflare KV and Durable Objects need access to env (#3426), etc.

Describe the proposed solution

A way for adapters to copy info from platform request into locals, a new field like meta, some new argument to render, or something else

Alternatives considered

Had considered exposing the whole request object (#2359)

Importance

i cannot use SvelteKit without it

Additional Information

No response

[JeanJPNM]

I have some questions about this:

• Will there be a namespace for the info in locals (like locals.info.foo or will it be at the same level than the others (local.foo)?)
• Can any kind of object be passed down?
• If it is possible, can the platform request be exposed via locals?
• For adapter-node could it be possible to expose the req object via locals (allowing the nextjs middleware style)?

[benbender]

I would like to rise the issue, that this might make it very hard for 3rd-party-libs to support sveltekit (at least with the full feature-set they have in other frameworks). I'm thinking about libs like https://github.com/PabloSzx/graphql-ez or https://github.com/trpc/trpc.

[benmccann]

this might make it very hard for 3rd-party-libs to support sveltekit (at least with the full feature-set they have in other frameworks)

Can you explain why it would make it difficult? I'm not familiar with these libraries. graphql-ez claims to already support SvelteKit

[benbender]

@benmccann ATM, sveltekit chooses to only provide a minimal common denominator for request/response. This is an approach which imho arbitrarily takes away options and freedom from users and implementors. Additionally it is a quite different approach to basically everyone else, often resulting in quite some effort to support by 3rd-parties (see f.e. https://github.com/trpc/trpc/releases/tag/v9.3.0).

If we would go down the way with a raw-request-prop, it would be the responsibility of the implementor to check and guarantee what features/props/methods of the request are there and supported. It would make support much easier for 3rd-parties, as they f.e. simply could type-check the object in .rawRequest to determine the platform and, ideally, reuse existing code for this platform.

The road with manually copying props into req.locals has no guarantees about any interface which could be checked against and would result in the need to manual configure things on a per case basis by the enduser of many libs. The responsibility is split between implementor and enduser with no common anchor and no clear separation of concerns.
Additionally I would fear that it could result in a higher support-burden for 3rd-party-libs, as I would suspect bugs resulting of problems by manually copying props as a prerequisite to use those 3rd-party-libs (to their full extend).

[cameronmbell]

I completely agree with @benbender, the truth is people know which adapter they are going to use. There is minimal real utility to being able to switch between serverless and node without having to rewrite some stuff. That's not something people need to do often enough to justify constraining developers this much.

[fezproof]

One thing that I haven't seen a solution propose yet is how this would work in local development? Perhaps the adapter can write a sort of polyfill to allow the app to run locally while assuming the adapter specific environment exists

[icflorescu]

I would like to rise the issue, that this might make it very hard for 3rd-party-libs to support sveltekit (at least with the full feature-set they have in other frameworks). I'm thinking about libs like https://github.com/PabloSzx/graphql-ez or https://github.com/trpc/trpc.

@benbender - if you're interested in tRPC, have a look at trpc-sveltekit. Not a full features-set yet, but it's a start.