Apollo Federation - Subgraph Library Maintainer Support

[CTA] Add/upvote your favorite GraphQL library, platform or framework in the repo!

Hello Apollo Federation Community!

We want to thank the maintainers of all the Apollo Federation libraries out there for their hard work. Your hard work has helped us establish our current documentation on other servers with Apollo Federation. The time has come for us to establish a better level of support for these libraries maintainers and establish a base foundation for us all. If we haven’t had the pleasure of meeting in the past, my name is Michael Watson and I’m the Developer Advocate for Apollo Federation. I’ve worked with Apollo Federation alongside dozens of Enterprises since it’s inception and it’s been amazing seeing how many languages you can use to create federated subgraphs!

One challenge I’ve seen organizations face is having different features supported (or not) in the various language/implementations tested out. We’ve started up a new repository with the goal of creating a solution that gives a granular understanding of any Apollo Federation library implementation’s spec compliance. The repository outlines the current testing for spec compliance which is what would be used to test any implementation. To accomplish this, we need to have a common schema that can be implemented by various library maintainers that can be used in this strategy.

A set of subgraph schemas has been created as the common schema; they provide the minimum required to test the Apollo Federation specification. This will common schema will change as needed with the evolution of Apollo Federation. The common schema is made up of three subgraphs:

Maintainers of Apollo Federation implementation libraries would implement the Product schema in their own folder within this repository to be included in the referenced tests. This is all automated through docker and using docker-compose ; this means implementors are responsible for packaging their example into a docker image that can be used in a standardized docker-compose.yaml file provided in the repository. The testing workflow can be summarized as:

  1. Setup project for test

  2. npm install packages for the users , inventory and graph-router services

  3. Build supergraph SDL for graph-router using rover supergraph compose

  4. Build users , inventory and graph-router docker images

  5. For each folder in the implementations folder…

  6. docker-compose up the docker-compose.yaml file at root of folder
    Note: the products service in the docker-compose.yaml has build: . which will build the docker image prior to bringing up all the services

  7. Run spec compliance tests and store results in memory

  8. Take all test results and create a table in a markdown file that can be used for Apollo Documentation

Note: A GitHub Action is used to to automate this testing and upload the results as an GitHub release with the markdown file asset

This is hopefully the first step to establishing an even stronger foundation for the community that has supported themselves so well. We also created a simple Maintainers Contributor Guide for anyone that wants to contribute back to this repository. We’ve used it internally to add in apollo-server, federation-jvm , ariadne , and graphene (with hopefully some more to come soon!). If you are a maintainer and need anything, please feel free to post in this thread or reach out to me directly! We want to help and this strategy will evolve over time to meet the needs of our community.

8 Likes