How to Split Subgraphs across Repositories
Introduction
For larger teams and larger projects, it can make sense to split your subgraphs into multiple repositories contributing to the supergraph in the "parent" project. This approach enables teams to have independent software development lifecycles (SDLC) and CI/CD pipelines, providing better governance and control over their specific domains.
In this setup, one or more subgraphs are defined in each repository and depending on the role of the user on the cloud project, can be built and applied to the supergraph independently. Each subgraph typically represents a distinct data domain (e.g., users, orders, products) and can be managed by different teams.
- Supergraph and subgraph builds are immutable and have unique IDs
- A subgraph must exist in the DDN project before inviting collaborators to it
- Each subgraph is namespaced and internal metadata objects cannot conflict with other subgraphs
- The supergraph is where subgraphs meet and conflicts can occur with root field and type names
- Subgraph prefixing can automatically remedy naming conflicts
Deployment with a multi-repository setup is effectively the same as deploying from a single repository, but with the considerations of managing your context to reference the shared project, and also being aware of the differences in abilities of the users building and deploying.
See the tables below for the roles and permissions of users on a Hasura DDN project.
In order to utilize multi-repository collaboration, you must have an active DDN Advanced Plan.
How it works
Parent Project:
The project Owner
or Admin
will need to:
- Initialize a new local parent project
- Initialize the corresponding cloud parent project
- Initialize git for the parent project
- Provision subgraphs on the cloud parent project
- Create a base build of the cloud parent project
- Invite collaborators to the cloud parent project
Independent Subgraphs:
The invited user will need to:
- Create a new supergraph with a new subgraph and initialize a new repository
- Initialize their cloud project as the parent project and link the new subgraph
- Set the subgraph context
- Create a subgraph build
- Integrate the subgraph build into the parent project
- Apply the build to be the official supergraph API (
Owner
,Admin
,Subgraph Admin
roles)
Create the Initial Parent Project
Begin by creating a "parent" project that will serve as the coordinated supergraph for your independent subgraph repositories. This central project will manage provisioning subgraphs, inviting collaborators, and maintaining the overall API.
Step 1. Initialize a new local project
This will serve as the parent project.
ddn supergraph init <parent-project> && cd <parent-project> && git init
This will scaffold the local configuration for your DDN project and initialize a Git repository.
Step 2. Initialize the cloud project
This is based on the local parent project.
ddn project init
In your configuration file (e.g., .hasura/context.yaml
), you'll see a new project
entry with the name of the project
returned by the CLI.
Step 3. Create an initial commit
git add . && git commit -m "Initial commit"
Push this repository to your preferred hosting service to share it with collaborators.
Step 4. Provision subgraphs on the cloud parent project
If you know the subgraphs to include, you can provision them using the DDN CLI. Replace <subgraph-name>
with the
desired name:
ddn project subgraph create <subgraph-name>
You are also able to add a subgraph on the console in the Share > Invite a user > Granular access
section.
Subgraphs can be added as needed when collaborators are onboarded.
Step 5. Create a base build of the cloud parent project
ddn supergraph build create
This initial build serves as the foundation for future subgraph builds.
Step 6. Invite collaborators to the cloud parent project
Navigate to your project's console and invite collaborators based on their roles:
Role | Abilities |
---|---|
Owner | All Project abilities including deletion. At this time, project ownership is not transferable. |
Admin | Same as a Project Owner, excluding deletion of the project. |
Read Only | Only explore and visualize the supergraph. |
Subgraph Admin * | All subgraph development-related abilities: create subgraph build, apply subgraph build to endpoint. |
Subgraph Developer * | Same as a subgraph admin, excluding the ability to apply subgraph build to endpoint. |
* Subgraph roles are only available on DDN Advanced projects.
The following are the detailed permissions for the above roles:
Permissions | Owner | Admin | Read Only | Subgraph Admin * | Subgraph Developer * |
---|---|---|---|---|---|
View Supergraph Explorer | ✅ | ✅ | ✅ | ✅ | ✅ |
View project insights | ✅ | ✅ | ✅ | ✅ | ✅ |
Create supergraph builds - using all subgraphs' metadata | ✅ | ✅ | ❌ | ❌ | ❌ |
Create supergraph builds - using single subgraph's metadata * | ✅ | ✅ | ❌ | ✅ | ✅ |
Apply supergraph builds to project endpoint | ✅ | ✅ | ❌ | ❌ | ❌ |
Create subgraph builds * | ✅ | ✅ | ❌ | ✅ | ✅ |
Apply subgraph builds to project endpoint * | ✅ | ✅ | ❌ | ✅ | ❌ |
Admin permissions on all subgraphs | ✅ | ✅ | ❌ | ❌ | ❌ |
Create / Delete subgraphs | ✅ | ✅ | ❌ | ❌ | ❌ |
Add / Remove collaborators | ✅ | ✅ | ❌ | ❌ | ❌ |
Manage project plans and billing | ✅ | ✅ | ❌ | ❌ | ❌ |
Delete project | ✅ | ❌ | ❌ | ❌ | ❌ |
* Only available on DDN Advanced projects.
Each collaborator will receive an invitation to join the project and can proceed to add their subgraphs.
Independent Subgraphs
Each independent subgraph contributing to the parent project resides in its own separate repository and has it's own local supergraph. The repository could be an existing or newly initialized one.
Step 1. Create a new supergraph with a new subgraph and initialize a repository
The invited user will need to create a new supergraph on their machine with a new subgraph and initialize a repository.
They will use the same name for the subgraph as was created in the parent project.
ddn supergraph init <subgraph-name-as-supergraph-name> --create-subgraph <subgraph-name> && cd <subgraph-name> && git init
This scaffolds the necessary structure and initializes a Git repository.
Step 2. Initialize the cloud project as the parent project and link the new subgraph
This will initialize the cloud project as the parent project.
ddn project init --with-project <parent-project-name>
Your configuration file will now link the local subgraph to the parent project.
You can add data sources and develop locally at this point. Check out relevant tutorials for adding sources.
Step 3. Set the subgraph context
ddn context set subgraph ./<subgraph-name>/subgraph.yaml
This sets the subgraph as the default for future CLI commands.
Step 4. Create a subgraph build
ddn subgraph build create
The CLI returns a build version for later integration into the parent supergraph.