Support local and remote services in ApolloGateway

Currently ApolloGateway supports the serviceList option for remote GraphQL services and localServiceList for local GraphQL schemas, but they cannot be used together. It would be great if ApolloGateway allowed both remote and local schemas.

[tjwallace]

Sorry I should have mentioned that I had tried returning a LocalGraphQLDataSource inside of buildService but ran into some issues:

1. This check requires a url in the service definition.
2. This object eventually gets passed to buildService (a second time for the service), but does not include anything originally in the definition (like schema) so I have to do a check on name and then reference schema from a higher scope. Is this expected? I didn’t originally notice this so now I have it working.

Here is what I have now for reference. Is this the “correct” way to use LocalGraphQLDataSource?

// local schema
const schema = buildFederatedSchema([Foo, Bar, Baz]);

const serviceList = [
  // can't add `schema` to this object because `buildService()` will eventually be
  // called a second time without it (only name, url and typeDefs)
  { name: 'local', url: 'local' },
  { name: 'remote', url: 'http://remote.com/graphql' }
];

const gateway = new ApolloGateway({
  serviceList,
  buildService({ name, url }) {
    if (name === 'local') {
      return new LocalGraphQLDataSource(schema);
    }

    return new RemoteGraphQLDataSource({ url });
  }
});

[mac2000]

@rahul22048 oh it is very old at very end we did make following:

right inside apollo federation gateway wrap all services with code pieces from graphql federation transformation

in at very end our gateway was something like:

var gateway = new Gateway({ services: process([
    {name: 'federated-service-1', url: 'http://localhost:3000'},
    {name: 'nonfederated-service-2', url: 'http://localhost:5000', config: require('./nonfederated-service-2.js')},
]) })

where process function inside returned records as is if there were no config property, other wise do transformation with applied configs

and it was working for a while, but later we did manage how to make federation support in dotnet so no need for this, at moment everything is working without any proxies