-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This is an internal wiki meant for contributors to this supergraph and members of the Apollo Solutions organization. However, to be transparent on how things operate behind the scenes, we are documenting our contributing notes in public.
For local work, the subgraphs are run as a monolith on a single HTTP server and a separate standalone Apollo Gateway, running on a different port, is used for local composition. See the current commands that are used in our DEV.md file
We use GitHub Actions to run code and schema checks on every pull request. This validates that the subgraphs can start up locally and that the schema composes correctly. You should not have to modify any GH actions unless you are adding a new subgraph (see below).
This repo gets published to Fly.io under the Apollo Solutions org. If you do not have access yet and are a part of the Apollo Solutions team, reach out to our team Slack channel to be added. It is run as a monolith app so that we can scale out the example as needed yet still only pay for a single app in our org as we don't expect much traffic to basic example.
The subgraphs all run on Fly, however, we use the Apollo GraphOS organization, Apollo Solutions, to host our schema and run our Router. If you do not have access yet and are a part of the Apollo Solutions team, reach out to our team Slack channel to be added. Here you can update the Router configuration and see any recent schema changes.
To add a new subgraph, a few steps need to be taken so that the new subgraph server is run in production and the new schema is reflected in the supergraph.
You can reference some of the existing subgraphs for code samples, but in the end you should expose a single function like getUsersSchema that returns a Federation compatible GraphQLSchema object. You can do that by defining the schema.graphql file for type definitions, resolvers.js for the runtime code, and optionally a data.js for some of the hardcoded data sets.
This is the file that starts all subgraphs in either dev or production mode. You should add the subgraph name and call the schema function in the LOCAL_SCHEMA_CONFIG object. This will then automatically be parsed and a new endpoint at /{subgraphName}/graphql will be added that can be used by the Gateway/Router.
After your changes are verified locally, make sure the schema gets published by updating the PR checks and merge actions to validate the schema on future updates and published on merge to the main branch. On your first PR, the schema checks might fail since you will be attempting to check a new schema that does not exist.