Support for Apollo Federation

[spawnia]

• Added or updated tests
• Documented user facing changes
• Updated CHANGELOG.md

Resolves #911

Changes

Allows Lighthouse to function as a federation capable service in Apollo Federation.

Breaking changes

No.

[tristanpemble]

hello! I was in the middle of trying to implement Apollo Federation in Lighthouse myself. from what I could tell, there was no good way to extend the webonyx/graphql-php schema printer to handle printing directives due to the use of static methods. I ended up adapting it to write my own. I did not expect to share this, and went a little crazy with generators as an experiment for cleaner reading code/ease of extensibility. however, it seems to function well. take whatever you need: https://gist.github.com/tristanpemble/f6d427034a33a06392f44ed17fb278dc

you should, in theory, be able to just throw this into your code and call FederationSchemaPrinter::printFederationSchema($schema) in place

[tristanpemble]

it would seem the repo linked in the original report has a much simpler extension of SchemaPrinter

[spawnia]

Thank you @tristanpemble, that was some good inspiration :)

[tristanpemble]

from what I see most of what is needed for federation is implemented - is there anywhere else I can help (maybe just by testing it out)?

[spawnia]

I am not quite sure how to interpret https://www.apollographql.com/docs/federation/federation-spec/#create-stub-types

A federated service should take the @external fields and types and create them locally so the service can run on its own.

Do we need some kind of mocking / generator?

[tristanpemble]

hm. I am definitely not an expert on this, but, I interpret that sentence as leaving the onus on the end-user and not on the framework. I'm not sure how you would automatically mock out types/fields from other federated services if the user did not provide them.

I think the take away from that section could impact this implementation could be here:

All fields referred to in @key, @requires, and @provides directives need to have corresponding @external fields in the same service.

perhaps you could insert schema validation wrapped in helpful messaging for the library user to tell them they need to define the external type or field in their schema if it is not present.

[tristanpemble]

I dug a little deeper on the official JS implementation, I think these validations will help you: https://github.com/apollographql/federation/tree/main/federation-js/src/composition/validate

specifically these are similar to what I was imagining:

• keyFieldsMissingExternal.ts
• requiresFieldsMissingExternal.ts
• providesFieldsMissingExternal.ts
• externalUnused.ts
• externalMissingOnBase.ts
• externalTypeMismatch.ts

anyway, I think digging through their validations will help! it could be that some of these are used from their gateway only, and not the federated service.

edit: after a little more digging I think that all of these validations are from the gateway on composition :) I think still a helpful reference to make sure you are compliant