mercurius
mercurius copied to clipboard
mercurius-js
Create an open source implementation of a Federated Schema Registry
Netflix is publishing how they're approaching implementing GraphQL Federation on their blog.
An interesting element is the existence of a schema registry (picture taken from the blog post, highlight is mine).
The registry is described as:
Schema Registry is a stateful component that stores all the schemas and schema changes for every DGS. It exposes CRUD APIs for schemas, which are used by developer tools and CI/CD pipelines. It is responsible for schema validation, both for the individual DGS schemas and for the combined schema. Last, the registry composes together the unified schema and provides it to the gateway.
And its functionality as:
Whenever a new schema is pushed by a DGS, the Schema Registry validates that:
- New schema is a valid GraphQL schema
- New schema composes seamlessly with the rest of the DGSs schemas to create a valid composed schema
- New schema is backwards compatible
If all of the above conditions are met, then the schema is checked into the Schema Registry.
We should consider creating an open source implementation of a schema registry for Mercurius.
I've been working something like this for quite some time now (after we realized, that we can't handle a large graph properly without one).
We've tried https://github.com/pipedrive/graphql-schema-registry but it has quite some limitations that render it impossible to use for us, and even if we would continue to use Apollo (which is something we want to trade in for mercurius early next year), we wouldn't be able to use Studio (or whatever it's called these days), as on-premise hostability is a must have for us as well.
It is not yet in a working state, but I would happily put it under the umbrella of an org, you know...
This is a fascinating topic for us too. cc @projectjudge @aleccool213 @edno
@asciidisco
It would be fascinating to know the limitations you encountered when using graphql-schema-registry. That could really influence the decisions made here.
One option might be to fork https://github.com/pipedrive/graphql-schema-registry and make the changes we want?
One option might be to fork https://github.com/pipedrive/graphql-schema-registry and make the changes we want?
That's a great idea. Its either fork or develop a close relationship with the maintainer to have pull requests go into that repo. Its using fairly standard tech (react/node) so should be fairly easy for everyone who would be contributing to mercurius to also contribute there.
An update here, from the sounds of it, The Guild will be releasing "Hive" which is their version of an open-source graphql schema registry. Might be good just to wait for that.
If someone wants to meet with us and discuss their needs to make sure we are covering it, feel free to reach out and let's meet early next year! We want to hear as much feedback, use cases and most importantly workflows you are having and make sure that by the time we open source it, it fits to the important workflows people are having
@Urigo we have not defined our requirements at NearForm - I'll likely ping you in the coming weeks.
We would love to have something like this. I'm very interested in following along and contributing!
For sure, I'm in ! Here is the schema reporting protocol from Apollo : https://www.apollographql.com/docs/studio/schema/schema-reporting-protocol/
Just wanted to mention the availability of a new schema registry reporting plugin for Mercurius: https://github.com/nearform/mercurius-apollo-registry.
Hi all, I'm currently working on a GraphQL Registry https://github.com/StarpTech/graphql-registry I'm open to contributions. My goal is to provide a similar experience with Apollo Studio in terms of schema and client management.
https://github.com/StarpTech/graphql-registry/tree/main/examples/mercurius-federation
Since my last comment here, we've released GraphQL Hive as a SAAS schema registry and also as a completely open source MIT project you can self host. There is now a huge community of companies using it, many using it as self hosted (the code and feature are completely identical to the SAAS version). Just realized I haven't gave an update here so I hope it would be valuable for people Here is the link to the repo: http://github.com/kamilkisiela/graphql-hive and here is a link to a talk I gave with full background on the solution
We would love to hear feedback from everyone here on what's missing and what we can improve!
@Urigo - OMG!!! :star_struck: :star_struck: :star_struck:
Thanks for the tip! I'm not so far with the project I'm working on to need federation, but this will certainly be in my to-do list for the future. Thanks again!
Scott
@Urigo thanks for the update, we are looking at it and we'll come back with meaningful feedback! cc: @aleccool213
From a quick look at GraphQL Hive, I think the complexity of the deployment actually makes it arguably cheaper to go for hosted / SaaS options. Nonetheless, great that such a technology is open source! Very useful.
@MrSaints of course we would prefer that you would pay us for SAAS and we believe we are doing it in a cheap and good way ;) but we still want to make self hosting Hive the easiest it can be! Can you share a bit about what was the complexity you've seen?
Quoting from the self hosting docs by @n1ru4l :
Pre-Requisites
The easiest way of running GraphQL Hive is using Docker and docker-compose.
All the services required for running GraphQL Hive are published to the GitHub container registry (GraphQL Hive Docker Images).
Please make sure to install the Docker daemon as well as docker-compose on your machine before proceeding.
@Urigo Sure. To clarify, I don't think the complexity is in the installation itself / following the Docker instructions.
I'm thinking more in terms of architectural complexity and costs.
I may be mistaken, but looking at the docs, and https://github.com/kamilkisiela/graphql-hive/blob/08c2a9fe317ad1079d57d0f24110988d183bf46c/docker-compose.community.yml, it seems running Hive requires:
- Postgresql
- Redis
- Kafka
- Clickhouse
The first 2 is alright. Kafka, and Clickhouse however, are not exactly cheap to run in production. Getting a team to manage that too is not exactly cheap, which is why I was saying it may be better to opt for a SaaS / Cloud option :)
BTW, I'm not saying they are not necessary costs. I'm sure they are more than justified. That's a separate discussion which I don't think I can comment on at this stage without looking deeper.
@MrSaints Registry requires only Redis and PostgreSQL, ClickHouse and Kafka are used for Usage Reporting
