-
Notifications
You must be signed in to change notification settings - Fork 721
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request options / context, at request call site #2283
Comments
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. |
@AnthonyMDev thank you, if possible, could there be a shared open design when this happens? |
@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. |
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better. |
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 anApolloContext
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?:
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 anApolloContext
at the time of setting up a subscription / watcher, the same way you'd pass it upon a request.The text was updated successfully, but these errors were encountered: