Allow for multiple remote endpoints
See original GitHub issueOne of things things that has me a little confused, is the seemingly lack of versioning recommended by GraphQL implementation articles and examples. Speaking for our team, we are already planning on making our current implementation essentially a pre release (/graphql
) and starting with our apollo server build out at api/v1
or graphql/v1
.
That being said, I’m interested to get thoughts on using the apollo client with multiple remote endpoints. Here are a few examples / thoughts on the api design
3rd party service + in house service
Let’s say we look into the future a year or so. GraphQL has solidified around a standard (already pretty dang close!) and more and more services offer Graph endpoints along with their standard REST endpoints. So I’m building an app that pulls from my app source, and pulls from reddit for example.
// a vanilla, not external redux store example
import ApolloClient, { createNetworkInterface } from "apollo-client";
const Reddit = createNetworkInterface('https://reddit.com/graphql');
const Heighliner = createNetworkInterface('https://api.newspring.cc/graphql');
// we can either specify the remote locations on the queries
// fwiw, I think this is a bad idea ;) but anything is possible right?
// this would mean only on client instantiated with multiple network interfaces passed to it
`
@Reddit
query getCategory($categoryId: Int!) {
category(id: $categoryId) {
name
color
}
}
`
`
@Heighliner
query getCategory($categoryId: Int!) {
category(id: $categoryId) {
name
color
}
}
`
const client = new ApolloClient({
networkInterface: {
Reddit,
Heighliner
}
})
// or we can create multiple clients but will have to figure out the duplicate store key
const RedditClient = new ApolloClient({
networkInterface: Reddit,
reduxRootKey: "reddit",
});
const HeighlinerClient = new ApolloClient({
networkInterface: Heighliner,
reduxRootKey: "heighliner",
});
Personally I am a fan of instantiating multiple clients as the two endpoints should have no overlap (if they did, your GraphQL server should be handling the linking, not the client). That also gives us the benefit of doing something like this in the future
Remote service + local service. One query / action language to rule them all
// a vanilla, not external redux store example
import ApolloClient, { createNetworkInterface, createLocalInterface } from "apollo-client";
// localGraphQLResolver is a client side implementation of a graphql app
// it allows for mutations to update / change local state of the app
// and queries to get app state
// @NOTE this is just an idea I've been playing with. Hope to have an example soon
const Local = createLocalInterface(localGraphQLResolver);
const Heighliner = createNetworkInterface('https://api.newspring.cc/graphql');
const App = new ApolloClient({
networkInterface: Local,
reduxRootKey: "local",
});
const HeighlinerClient = new ApolloClient({
networkInterface: Heighliner,
reduxRootKey: "heighliner",
});
So all in all, I don’t think this requires any API changes, just wanted to bring it up 👍
Issue Analytics
- State:
- Created 7 years ago
- Reactions:3
- Comments:50 (17 by maintainers)
Top GitHub Comments
Personally, I think the main strength of GraphQL is having exactly one endpoint. If you’re querying multiple GraphQL servers from the same client, I feel like you’re doing it wrong (just my opinion at the moment).
I think having a function in the server to proxy part of the schema to a different GraphQL server would be the right approach, so that you maintain the property that you can render your whole UI with one roundtrip.
As for merging client and server data, I have a few ideas for how to do that, but I think that’s a special case - it should be exactly one server schema and one client schema IMO.
One main argument for me is that the whole point of GraphQL is to be able to traverse data in the same query, and have schema types that reference each other - just sending two root queries to different servers doesn’t really give you any benefit over just initializing two clients IMO.
We have some ideas for how this might work in a future Apollo proxy server, which would let you traverse between schemas at will in a single query, from your schema, to external services, etc.
@stubailo I just thought of this and stumbled upon this issue. I saw GitHub released a GraphQL API, and thought “how would I write a front-end app that connected to my own GraphQL backend, but also used GitHub’s API?” I don’t know of any way for Apollo to connect to multiple servers.