Modify federation to be possible with edn schema as well

[hmy3743]

trafficstars

Extends lacinia's support for federation to add the ability to support federation through the edn schema as well.

[CLAassistant]

All committers have signed the CLA.

[hmy3743]

As I understand the Apollo federation documentation, the @extends and other directive, scalar types, etc. are not explicit in the input SDL but still available, and should not be generated into the output SDL. In the systems I've developed under federation, we start with SDL document and provided that document, as is ... you can see that in the code in master.

I am not sure if I understand the review comment well, but if you look at the document about apollo's federation subgraph, it says that the server should provide some schemas. Then shouldn't the schema be exposed to the router through query{_service{sdl}}}?

[hlship]

I'll work on resolving this against the Apollo documentation.

[hlship]

Federation is a moving target, we're compatible with 1.0, but 2.0 changes things: https://www.apollographql.com/docs/federation/federated-types/federated-directives

In any case, I don't think the current version of this code will work because it includes the Federation (1.0) annotations and objects injected into the schema.

In the current version, based on reading SDL, you can see that those elements aren't in the input SDL (they are provided after that is parsed) and then we use the input SDL as-is when exposing the schema to the Apollo gateway.

I don't know exactly what would happen if we include those elements in the generated SDL but I suspect Apollo will reject the schema.

[hlship]

I'm struggling to find time to come back and finish reviewing this. I want to test what happens when the injected Fed 1.0 directives and types are not filtered out when generating SDL from the schema (that is, see how Apollo reacts).