Schema versioning and diffing breaking changes

[angelsvirkov]

Hi guys, I would like to start a discussion around the topic of breaking changes and schema versioning in GraphQL Mesh. I have also thought a little bit about potential solutions and I am going to propose one.

Problem

• GraphQL Mesh is used as a gateway server to multiple smaller services. The final mesh is constructed dynamically on a server start-up after stitching together all input handler schemas. Now, one service introduces a breaking change and this immediately gets propagated to the mesh server on the next start-up. Resulting in an undetected breaking change on the GraphQL Mesh Schema and ultimately on breaking the clients.

Question?

I know this topic around versioning and maintaining old clients is non-trivial but I was thinking if there is already something that could improve this situation on the GraphQL Mesh?

Proposal idea:

My idea here would be to have some sort of schema locking with another module. For example, on server start-up the module could compare the newly created schema with the locked schema from before and report differences or even yield an error and stop any further actions.

I hope this was the right place for this problem. What are your thoughts on this?

fyi @Kiesen

[dotansimha]

Hi @angelsvirkov !
This is a very interesting topic, and it's something we really want to tackle and improve.

The first thing here is - we don't have any way to tell that the upstream schemas has changed - we have some thoughts on adding restart policies for the mesh, but currently it's just not there yet.

Regarding the GraphQL schema changes: your suggestion is really interesting, but we can't really tell when the change has happened since it happens in runtime.
The mechanism you suggested could be implemented in a separate setup, on top of graphql-mesh, with only a few lines of code (since you can get the SDL of the GraphQL schema created, store it, and the compare it with graphql-js or graphql-inspector and find breaking changes).
I guess it's all a matter of behaviour that you wish to implement - I would prefer to have a running server with a breaking change, instead of stopping the server).

[angelsvirkov]

Thanks for the quick and thorough answer. I have a follow-up question on this topic if you don't mind. Apart from detecting breaking changes, there is also the problem of maintaining older schema versions, which is even a bigger problem. But would you say that it could be possible in GraphQL Mesh to maintain older schemas and new schemas together? Let's say with some sort of an adaptability module which does transform older schemas into the new one and it makes the compatible in a way. The reason I am asking is because with GraphQL Mesh we get a very high level of abstraction and generality but I feel like we might lose some points like version management which require some more specific work. So if GraphQL Mesh exposes some functionality for schema version management then it would really strike a golden balance between abstraction and specificity. Is the latter what you meant by something you would like to tackle in GraphQL Mesh?

P.S. I am not sure if such a version management mechanism could be implemented as part of the mesh or as you already mentioned in separate setup on top.

[Urigo]

@angelsvirkov the whole thread is a great subject that we are spending a lot of time now currently with a couple of our clients in order to open source a better set of tools for managing all those different sources.

If we break it down even further, we can start by asking, where does all the information about different schemas, their sources, versions in runtime and in code belongs?

To your question, we definitely want to tackle this, I've mention it briefly in my GraphQL Galaxy Keynote here.

We are now in the process of testing our designs on a couple of different use cases and flows with our clients to make sure we got it right.
It sounds like you have an interesting use case as well that we should definitely take into account, would you be ok with having a short meeting with us to teach us about your use case and see if our proposal covers yours as well or there are cases we haven't thought about?

[angelsvirkov]

@Urigo , thanks for the comprehensive answer. I would be interested in such a meeting to share the use cases / problems with you.

[Urigo]

Great! Could you please reach out on email and let's schedule?
My email is public on my Github profile

Thanks and see you soon!

[angelsvirkov]

For anyone who is looking for an update on this, here is what I believe are good solutions available at the time of writing

• https://www.graphql-mesh.com/docs/recipes/build-mesh-artifacts
• https://graphql-hive.com/

[JustusNBB]

Direct link to the validation subsection for mesh validate:
https://www.graphql-mesh.com/docs/recipes/build-mesh-artifacts/#validate-your-existing-mesh-artifacts