There should be a single source of truth for registering and tracking the graph.

• Create multiple graphs (for example, staging and production, or different development branches)
• Stores versioned schemas for all GraphQL-federated services
• Serves schema for GraphQL gateway based on provided services & their versions
• Serves a supergraph schema for the GraphQL gateway
• Validates new schema to be compatible with other running services
• Validates that all client operations are supported by your schema
• Produce a diff between your proposed schema and the current registry state to detect breaking changes and more
• Lightweight authorization concept based on JWT.

Read more

• Federation with Mercurius.
• Federation with Apollo Gateway.
• Managed Federation with Apollo Gateway.

Try all endpoints in insomnia or read the api documentation.

Copy .env.example to .env

# Install project
npm install
# Start postgres
docker-compose up postgres
# Create db schema
npm run migrate:up
# Watch mode
npm run dev
# Run tests
npm run test

Run a benchmark with:

docker-compose up postgres
docker-compose up --build app
docker-compose run k6 run /benchmark/composed-schema.js

Our benchmark suite is running in the CI.

GraphQL-Registry uses by default postgres as database.

# Bootstrap database
npm install && npm run migrate:up
# Run service
docker run -e DATABASE_URL="" starptech/graphql-registry:latest -p 3000:3000

Available environment variables.

GraphQL Registry is currently highly under development. It means that we are still working on essential features like production-ready schema management, graph metrics and development tooling. GraphQl Registry can be evaluated anytime. Every feature is covered by integration tests. We rely on your feedback and sponsorship. Feel free to open an issue or feature request!

❤️ contributions!

I will happily accept your pull request if it:

• has tests
• looks reasonable
• follows the code of conduct