Loading navigation…
User
Work with AxonMundi's composed client schema and self-hosted Cosmo registry
The self-hosted Cosmo registry is the authority for the deployed AxonMundi prototype composition. It accepts published subgraph SDL, produces the composed client schema, and provides the latest valid router configuration. It does not replace Prepared911's established GraphQL stack as the canonical integration.
A successful composition means the registry has a valid graph configuration. It does not prove a service is healthy or that a new client surface is deployed. Producers deploy compatible services before publishing SDL, then verify the composition and router telemetry afterward.
@prepared/data-gql vendors the composed client schema so code generation and
mocks do not depend on a running router. Use this path only for a frontend
participating in the AxonMundi prototype. The normal refresh fetches the latest
valid schema from axonmundi/default:
Copy .env.wgc.example to the untracked .env.wgc file and load it:
If needed, complete the device flow yourself:
Refresh the schema and regenerate dependent types:
Before a schema-related change, compare the committed copy without writing:
pnpm schema:login uses an individual Keycloak device-flow session. Do not
attempt it for another person or substitute a CI API key. CI uses separately
managed COSMO_API_URL and COSMO_API_KEY; neither belongs in a local file,
repository variable, or log.
When an AxonMundi change is not yet in the registry, point the schema sync at a local composed router configuration:
just compose creates the untracked execution configuration that contains the
composed client schema. This is a local development path only; do not commit
execution configuration or composed-SDL artifacts. See the
AxonMundi getting-started guide
for local static composition and registry-backed Studio development.
Note for frontend developers: You do not need to run these commands or publish subgraphs. This section is for backend service owners publishing a separately owned service to the registry.
You do not need an AxonMundi checkout to validate or publish a separately owned subgraph. Do that work in the subgraph's repository, using its normal build, test, deployment, and CI conventions.
Coordinate the subgraph name, namespace, app=axonmundi label, deployed
routing URL, and authorization requirements with the graph owner.
In the subgraph PR, run the service's generated-artifact checks, tests, and a registry schema check:
After merging, deploy and verify a backward-compatible service version before publishing its SDL from the same repository's delivery pipeline:
Confirm the new composition in Studio and monitor router-to-subgraph telemetry. Just because the registry composed your schema successfully does not prove the underlying service is healthy or correctly handling traffic. Always verify deployment health and authorization alongside the composition.
The subgraph CI obtains COSMO_API_URL and COSMO_API_KEY through the
approved CI secret path. Never use the router's GRAPH_API_TOKEN for this
work.
The first integration still needs an AxonMundi handoff for local-composition coverage and any router policy or header-forwarding changes. That work belongs to the graph owner; it is separate from publishing and does not require every subgraph contributor to clone AxonMundi.
For generated-code requirements, Connect services, CI credential setup, and rollback details, use the subgraph CI and registry publication runbook.
Do not mint a GRAPH_API_TOKEN, modify router runtime Secrets, or run an
environment cutover as part of normal frontend or producer work. Those actions
belong to Platform and are covered by the
registry cutover runbook.