Apollo Federation Spec: Fetch service capabilities

[aeramu]

Related to this issue #120, to integrate with Apollo Federation we need to fulfill their specification at minimal with fetch service capabilities
Schema composition at the gateway requires having each service's schema, annotated with its federation configuration. This information is fetched from each service using _service, an enhanced introspection entry point added to the query root of each federated service.
With these changes, we can use graphql-go as subgraph behind Apollo Federation Gateway even though it's still not fully implements the specification, but at least it's one step closer

This already works with simple schema stitching

[pavelnikolov]

@aeramu thank you for your contribution. Could you, please, add a minimalistic example with two subgraphs in the examples folder. That would be really helpful for people who are just starting with Apollo Federation and this library.
In addition to that, there has been already work started on implementing directives #446, which could allow for satisfying the rest of the specification. Just out of curiosity, what else is remaining?

[suessflorian]

@pavelnikolov, the base introspection spec by default doesn't expose directives (motivation being, it's an implementation detail). Looks like Apollo Federation spec encourages servers to extend introspection capabilities to pseudo show these directives? In contrast to https://github.com/movio/bramble, which deals with this problem by making servers simply plain string show their schema. Both approaches seem to have flaws. But Bramble at least works to focus on compatibility.

[pavelnikolov]

I thought that you'd need to use directives like: @key, @provides and @external.

[aeramu]

@pavelnikolov I already add simple example.

The remaining main spec that I think quite complex is resolve request for entites. It's used to reference and extend types across subgraphs. I still don't know the best way to implement it because it's need user implementation to get each entities.

[pavelnikolov]

@aeramu I pulled you branch locally but unfortunately I couldn't get the node server to start.
Initially it complained that I had newer version of Node.js than what Apollo supported. Then I downgraded Node to v14 LTS but now I get the following error:

$ yarn start
yarn run v1.22.18
warning package.json: No license field
$ node index.js
$HOME/go/src/github.com/graph-gophers/graphql-go/example/apollo_federation/gateway/index.js:5
    supergraphSdl: new IntrospectAndCompose({
                   ^

TypeError: IntrospectAndCompose is not a constructor
    at Object.<anonymous> ($HOME/go/src/github.com/graph-gophers/graphql-go/example/apollo_federation/gateway/index.js:5:20)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:75:12)
    at internal/main/run_main_module.js:17:47
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

It seems to me that it would be much more appropriate to have this declared in a docker-compose.yml file so that users would only need to run docker compose up in order to see the example working.
I'm sorry for demanding yet another change, but would you mind adding a Dockerfile in each of the 3 folders and then a docker-compose.yaml in the root folder of the example? This way we would ensure that this example works on everybody's machine. Let's not forget that some Go developers might not necessarily familiar with Node.js and having everything declared in a Dockerfile would make their life much easier.

[pavelnikolov]

I did test a little bit more and it seems that the apollo/gateway version that you are using is really old. I did upgrade the module to "^0.49.0" and I got a different error:

node_modules/@apollo/gateway/dist/supergraphManagers/IntrospectAndCompose/loadServicesFromRemoteEndpoint.js:50
            throw new Error(errorMessage);
                  ^

Error: Couldn't load service definitions for "one" at http://localhost:4001: Expected JSON response body, but received:
<!DOCTYPE html>
<html>
...

This seemed like the GraphiQL interface HTML. That is why I changed the URLs of the two servers in order to get your example working:

const gateway = new ApolloGateway({
    supergraphSdl: new IntrospectAndCompose({
        subgraphs: [
-            { name: 'one', url: 'http://localhost:4001' },
+            { name: 'one', url: 'http://localhost:4001/query' },
-            { name: 'two', url: 'http://localhost:4002' },
+            { name: 'two', url: 'http://localhost:4002/query' },
        ],
    }),
});

And finally, I got your example working:

So given the above, please:

1. Upgrade the apollo/gateway module to the latest version
2. Ideally, add docker-compose.yml file in the root of the example, so that even without Node.js installed everyone can test the example locally.

[pavelnikolov]

@aeramu I made the changes for you. Thank you for your contribution! I'm looking forward to having the rest of the Apollo Federation working properly. It seems that I need to merge a PR that improves the way we handle custom directives and focus on the @key, @provides and @external directives.