[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:
- Users - This subgraph is provided by the repository
- Inventory - This subgraph is provided by the repository
- Product - This subgraph is written by Apollo Federation library maintainers. There are some example implementations in it that can be used for reference
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:
-
Setup project for test
-
npm installpackages for theusers,inventoryandgraph-routerservices -
Build supergraph SDL for
graph-routerusingrover supergraph compose -
Build
users,inventoryandgraph-routerdocker images -
For each folder in the
implementationsfolder… -
docker-compose upthedocker-compose.yamlfile at root of folder
Note: theproductsservice in thedocker-compose.yamlhasbuild: .which will build the docker image prior to bringing up all the services -
Run spec compliance tests and store results in memory
-
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.