Allow for multiple remote endpoints

[jbaxleyiii]

One 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 👍

[stubailo]

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]

seemingly lack of versioning recommended by GraphQL implementation articles and examples

My understanding is that GraphQL is supposed to remove the need for versioning by having deprecated fields. So you can deprecate a field, then track how many clients access that field, and once it drops below a certain level you just remove it. Rather than having different versions of the whole API.

[jbaxleyiii]

@stubailo I haven't played around with deprecated fields. I'll give that a go for our use case. I can see how having the server doing the linking would be a better world too.

http://facebook.github.io/graphql/#sec-Deprecation for reference

Thanks for the input 🎉

[stubailo]

Yeah I would really love to know how that works for you. And it would be cool to collaborate on the proxy thing, I think that would be really valuable, if you could just have your schema say "oh, this is a GitHub user" and then be able to import the whole GitHub API schema and just traverse it.

[stubailo]

Moving this: #86

[jbaxleyiii]

@stubailo since our move would be to the apollo version of the graphql server, I'm sure you'll hear about it haha.

then be able to import the whole GitHub API schema and just traverse it

The dream. Application libraries that you can import and use for your app

[crumhorn]

We are in the process of rewriting the front end to existing old-school webservices, and it's quite naive to assume that a server will only ever have one endpoint.

In our case we have two SOAP services (yep, old stuff) that provide data, and that's just "how it is" currently. In any case, as Apollo as of this writing doesn't seem to support our scenario as I can only tell apollo to use one endpoint based on my url, here's a quick and dirty copy & paste of what I did to make apollo + express handle this (Using Ang2 RC5 if it matters) in case someone else is interested.

First, on the client side, I set up a middleware so that it takes a passed "variable" and sets it as part of the header, as follows:

const networkInterface = createNetworkInterface('http://localhost:4000/graphql');

networkInterface.use([{
    applyMiddleware(req, next) {
        if (!req.options.headers) {
            req.options.headers = {};
        }

        req.options.headers.service = req.request.variables["service"];

        next();
    }
}]);

In my data provider service on the client, I then set up a basic fetch method like:

private fetchData(service:string, query:any):any {
        return new Promise((resolve, reject) => {
            this.angularApollo.query({
                query: query,
                variables: {
                    service: service
                }
            }).then((graphQLResult) => this.handleGraphQLResponse(graphQLResult, (data) => resolve(data), (errors) => reject(errors)));
        });
    }

This will ensure my passed in "service" string ends up on the request header sent to the server.

Now, on the server, using express, I set up a redirect route that reads the header and sends the request on to either one or the other endpoint based on this header:

graphQLServer.use('/graphql', function (req, res) {
    // fetch service from header
    var service = req.headers["service"];

    var path = '';

    if (service == 'trading') {
        path = '/graphqlTrading'
    }
    else if (service == 'ref') {
        path = '/graphqlRef'
    }
    else {
        res.send('Unknown service in header, or not set. Service was: ' + service);
        return;
    }

    var url = 'http://localhost:4000'+path;

    // console.log("Piping '" + service + "' service " + req.method + " + request to "  +url);
    req.pipe(request(url)).pipe(res);
});

Do note however that bodyParser() can mess up redirects as it modifies the body on the request object and can cause the pipe to hang, in my case the express() I use for the GraphQL server is separate from the one I use for the other Ang2 server-side stuff and I don't include bodyParser unless specifically via:

graphQLServer.use('/graphiqlRef', bodyParser.json(), graphiqlExpress({
    endpointURL: '/graphqlRef'
}));

In my opinion, it would be great if you could load up multiple network interfaces in apollo and at query-time be able to tell it which one I want it to use. I'm sure there's many possible solutions though.

[yodacom]

Were you able to work with ApolloStack in context and access your SOAP services? I have a similar case with using legacy SOAP services that we need to access with our Reactjs/Redux app ..we would like to go about this in the new "ApolloStack way" so further describing your success/experience with experimenting with SOAP using ApolloStack would be greatly appreciated and helpful to all of us!

[stubailo]

I'm pretty confident that the correct way to use GraphQL is to have one server that calls different services in the background. Having multiple ApolloClient instances is the best way to call multiple services.

[crumhorn]

@yodacom, yes, we are successful using GraphQL and NodeJS together with npm module "soap". I wrote a quick and dirty java project to generate the GraphQL schema from a WSDL (requires some manual interaction post-generation). Since this issue is regarding something else, feel free to contact me if you are intesteted in it. I could put it up on github if others also are interested.

[helfer]

@crumhorn I think it would be great if you could put it on GitHub, then we can link to it from here.

[crumhorn]

@helfer, and anyone else interested, here it is:

https://github.com/crumhorn/wsdl2graphql

I wrote up a quick Readme.md for it.

Like I mentioned earlier, it's a very quick and dirty project and I didn't spend much time on it, but it did the job for us, saving us a large amount of time. Do note the "Important" section, as there's two lines in the code that might necessary to change to fit other peoples web services.

I suggest running it from either IntelliJ IDEA (or Eclipse) just to make it easy as getting the right classpath on the command line is (as always) a pain.