How stitching, federation and modules all fit together?
TL;DR
After many years of supporting the community, the OK-Grow! Team is transferring ownership and maintenance of merge-graphql-schemas to The Guild
merge-graphql-schemas will be added to the existing Schema management tools already created by The Guild (GraphQL-Toolkit, GraphQL Modules, GraphQL Inspector and graphql-code-generator)
This is a continuation of making order in the schema management tools across the ecosystem
If you are at GraphQL-Conf this week, come say hi
merge-graphql-schemas is a popular library in the GraphQL Ecosystem.
It’s one of the first tools people encounter once they went through their first GraphQL implementation and start to wonder how to organize their GraphQL server code.
The OK-Grow! Team has been maintaining that library for years, filling a needed gap in the ecosystem.
At the same time, The Guild has been working on similar tools around GraphQL schema and module management.
Today we are happy to announce that we are joining forces and merging our efforts to create open source, easy and scalable solutions for GraphQL servers.
In a couple of days of work we’ve refactored the underlying implementation of merge-graphql-schemas to use GraphQL-Toolkit under the hood, we can close around 90% of the open issues on the library while making sure all existing tests are passing!
We are happy to announce a new beta release (1.6.0-beta) is out!
If you are a user of merge-graphql-schemas please give the new version a try before we make a full release.
yarn add merge-graphql-schemas@next
What’s next?
The Guild has been busy for a while creating scalable GraphQL solutions around schema and modules management for large teams.
The main issue we see today in the ecosystem is that there is no clear overview of which tools solve which problem area.
In order to make sure we solve the right issues in the right place, we need clear boundaries between the different libraries and solutions.
Let’s try to break down the different areas of solutions needed when splitting GraphQL schemas:
Building and executing GraphQL according to spec — The Engine
Structuring multiple building blocks of the same server into a single executable schema — GraphQL Tools and Frameworks
Structuring multiple servers instances into a single executable schema — Federation
Now we can gather all use cases from the community, put them as tests on the right library and make sure we solve each one of them.
The Engine
The Engine (in the Javascript world the most popular one is graphql.js) should be responsible of taking a ready schema and resolvers, validate the objects, introspecting them and executing documents against them at runtime.
That GraphQLSchema input must be strictly valid according to the GraphQL Spec.
That’s why manipulating a ready GraphQLSchema object can be hard. GraphQLSchema object should be the final object to input the engine.
The Engine should not care or help you create that final schema or resolvers.
GraphQL Management Tooling
We can think of the Engine like a Web Browser — It is responsible of taking a spec (Javascript and HTML) and execute it in a consistent way.
But the browser doesn’t care about how you create that Javascript and HTML bundle.
That means that like we use babel, Typescript or frameworks for manipulating code to generate spec-compliant output, we can do the same for GraphQL with graphql.js as our target “browser”.
Those tools should help you organize and manage your code in your preferred way, without needing to be bound by what graphql.js expects.
One of the main things that those tools can provide us is an easy way to split the code and the schema into small chunks and later merge them with different merging strategies.
Just like Javascript frameworks, using those tools can get you very far and make it easy to handle huge codebases with many different teams.
Federation
In some scenarios you would want to run completely different servers and merge them somehow into a single GraphQL gateway.
Schema stitching and schema federation are attempts to make that work less manual.
There are some use cases where you might want those types of solutions, but they also add a lot of complexity so it’s important to understand very well why you really can’t handle your use case in a build-tool type of solution, and to know if Federation is an end goal or a stepping point to get you further.
Breaking it all down
After years of working with GraphQL, from small applications to managing schemas across huge corporations, creating open source tools and best practices around those, we want to share it all with the community.
In the next few weeks we will publish articles about each solution type, the tools around and when you should use what.
Things like why you should split your schemas, why not, what are the existing solutions out there and when to use each one.
We will also add examples of all those use cases into our main tutorial.
We need you to send us your questions, use cases and ideas — we want to make sure we cover as many use cases as possible across our libraries and other libraries we contribute too as well (some things might fit into graphql.js or Apollo for example).
You can comment here or submit issues into any of our repositories.
Thank you OK-Grow!
I want to personally thank the OK-Grow! Team and specifically Paul for being a very early adopter and supporter of the GraphQL community.
The work you have done so far has been amazing and valuable and we are dedicated to continue to support our community in the best way possible.
Top comments (0)