added clients & defaultClient option.

[j]

So, I the client option was merged where users can pass in a Client to override the client in ApolloProvider. One pain that I've come across using this method is that for SSR, it's complicates things when you need to create a new client per HTTP request. Without multiple clients, in typical react-apollo setups, this works fine because each request wraps the app in ApolloClient, runs getDataFromTree, etc, etc. When using SSR, this example in the comments when the client option was originally merged makes it difficult (because the cache is somewhat lost, unless you pass around the original created one)

Current Implementation:

// This is fine on the browser since you can locally cache "other-client" 
// and re-use... but a pain for SSR.
import MyOtherClient from "../other-client"

export default graphql(MyQuery, {
  client: MyOtherClient,
})(MyComponent);

This PR adds this functionality:

// Store.js
export default graphql(gql(`...`))(Products); // uses default client

// Repositories.js
export default graphql(gql(`...`), {
  options: {
    client: 'github'
  }
})(Repos);

// App.js
<ApolloProvider clients={{ shopify, github }} defaultClient={shopify}>
  <App>
    <Store />
    <Repositories />
  </App>
</ApolloProvider>

I know I'm supposed to create PRs only if there's a consensus, but it was more of a pain setting up an environment to show my use-case than it was to just see if moving all clients to the provider context would fix it. After I added all of this, it indeed fixed my issue where double fetching on the server & browser would happen.

This still needs a few more tests and error handling when clients with invalid names don't exist, etc.

Checklist:

• If this PR is a new feature, please reference an issue where a consensus about the design was reached (not necessary for small changes)

#1232

• Make sure all of the significant new logic is covered by tests

I still need to add a few more tests and clean things up.

• If this was a change that affects the external API used in GitHunt-React, update GitHunt-React and post a link to the PR in the discussion.

[apollo-cla]

@j: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[apollo-cla]

	Fails
🚫	No CHANGELOG added.

Generated by 🚫 dangerJS

[stale]

This issue has been automatically labled because it has not had recent activity. If you have not received a response from anyone, please mention the repository maintainer (most likely @jbaxleyiii). It will be closed if no further activity occurs. Thank you for your contributions to React Apollo!

[jbaxleyiii]

@j I'm so so sorry this PR was never responded to! I'm curious, why do you create multiple clients?

[j]

@jbaxleyiii hey, I was using Shopify API + Graphcool and the route that was implemented (client option). In my case, I'd probably just end up using schema stitching, but I've become too uncomfortable with the current state of stitching, so ideally the front-end could just simply call two APIs. :)

[jbaxleyiii]

@j would being able to send the request to two different endpoints (not two full clients) work for you? That is possible with the 2.0 and keeps this integration simpler

I don't want to support multiple clients at this time since the recommended approach is a single client which can use multiple endpoints

[sh0umik]

Is anyone using this PR till date ? This commit seems fine but also 3 years old. Any feedbacks ?

[cansin]

@jbaxleyiii I couldn't quite understand your comment re: "the recommended approach is a single client which can use multiple endpoints". Can you elaborate on how one can re-use a single client instance in order to connect both, let's say, GitHub and Shopify GraphQL APIs?

[cansin]

Btw, I am guessing, we should be using useMutation({ client: anyExtraClient }) instead of trying to provide multiple client instances. But I was intrigued by that comment and wanted to make sure I am not missing a feature that I could rely on. Thanks