Request options / context, at request call site

[jimisaacs]

Feature request

It would be great to be able to pass more arbitrary things to our networkTransport, and maybe even store object, via the client request call sites. Maybe something like an arbitrary context (like golang), or options (like js).

Motivation

The reason is mainly for multi-user support, though there are more applications. Right now for multi-user, our solution is to have an apollo client per user. This might not sound or be horrible, but it would be nice to be able to pass a store and transport, or maybe even a client at the call site of requests so we might be able to consider different architectural approaches.

Why is this better than simply maintaining multiple clients? It can provide more context to underlying network transports and stores if it were piped through each respectively. This would allow per operation headers, cache handling, and much more.

Beyond multi-user support, sometimes, certain operations have different transport obligations, like auth, which currently would require either a different client, or a way to pipe things to the transport of the current client. I'm pretty sure this feature would solve this too.

Proposed solution

Apollo client currently takes a contextIdentifier. Maybe this should be replaced by an ApolloContext object, where it can optionally provide an identifier, and a bunch of other things if it wants to.

Maybe it is just a different flavor of method altogether than allows this?:

send(ApolloContext(operation: query, cachePolicy: .default, identifier: UUID(), networkTransport: networkTransport, store: store))

Outstanding Questions

Currently I only see contextIdentifier used in query watchers, so I'm not sure how this would change that, or subscriptions. I would assume you would pass an ApolloContext at the time of setting up a subscription / watcher, the same way you'd pass it upon a request.

[AnthonyMDev]

We plan on re-writing our entire networking stack in H2 of this year. It should be much more flexible at that time.

That said, using the same data storage and networking session across multiple user's generally considered a dangerous practice as an industry standard. It can cause bugs to creep in that violate user privacy and security.

[jimisaacs]

@AnthonyMDev thank you, if possible, could there be a shared open design when this happens?

[calvincestari]

@jimisaacs we'll likely follow the same RFC-style proposal that we did for the codegen 1.0 release. So yes, we'll share it with the community for feedback.