GraphQL Anywhere - Our Journey With GraphQL Mesh and Schema Stitching

Hi everyone, my name is Uli and I'm really excited to be here and give the first talk at GraphQL Galaxy. Giving the first talk at GraphQL Galaxy I feel like I want to mention a lot of cool things that happen in the community so give me a couple of minutes to mention a few things and then we can actually start with the actual talk.

So I'm a member of a group called The Guild. We're the largest open source group in the GraphQL world so you probably are using one of our libraries like maybe the GraphQL Code Generator to generate code from your schemas and your operations. GraphQL Inspector to make sure to track changes and make sure that you're not making breaking changes. GraphQL Modules which we recently introduced 1.0 after many years of iterations. It's a tool that helps you basically split responsibilities of your GraphQL gateway between teams while still maintaining a regular GraphQL gateway. GraphQL Tools that I will mention later today mostly around the new schemas teaching that if you thought was deprecated then stay on for this talk and I hope you can learn some new things around it. GraphQL Mesh which lets you query sources that are not GraphQL as if they were GraphQL automatically and many others.

I'm mentioning all those tools because for us the goal of the Guild is to, in order to create a powerful community, we believe that we need to rely on a lot of tools that are being maintained and you can count on for the long-term. That's what we do. We do it ourselves and we do it with the community. You could, you know, use all those tools together as one platform and they all have a vision behind them, but like when we go to a very large client or something like that, we can't just introduce all those tools, we build them individually so you can slowly and gradually introduce those tools when you need them, only the things that you need. But again, like I said, we can't do this alone.

So in the last year, we joined the GraphQL Foundation in order to also help influence and contribute to the core assets of GraphQL, like GraphQLJS and GraphQL.org. So in GraphQLJS, we actually started again the effort of migrating GraphQLJS to TypeScript. We need help there, by the way, so you can go to GraphQLJS and the highlighted issues are around the TypeScript migration. Any help will be helpful. And also, we improved a lot GraphQL.org itself. We've completely rebuilt the infrastructure of it using Gatsby to make it easier to contribute. And also, we rebuilt the code page. So it will be much easier to find the libraries that you want and that are well-maintained. So go there and find basically all the libraries that I'm going to mention now are highlighted there, and we hope to make that the best source out there. And if you want to contribute, it's easier now. It's better than, easier than ever.

I'll also mention some things that happened in the community that are not by us, and that makes us very happy, like the new GraphQL Web Socket library. For years, there was a library that wasn't maintained, and Dennis from the community basically built a new library, created a working group around the protocol, and made it way more secure and way more easy to integrate. If you ever tried GraphQL subscriptions, or you needed a Web Socket protocol, now it's easier than ever.

Also, for years, we've been talking about the stream and defer directives, and how valuable they could be, and this year Liliana and Rob from First Dibs actually did a lot of work for very long periods of time in order to bring those into the spec and into the reference and limitation, so you could use them today. Another directive that is very interesting is not in the spec yet, but I believe it has a very bright future and could help a lot of people, is the Live Queries directive. Lauren from the community actually created the GraphQL Live Query repository and libraries, and I think you should check it out. We are personally very excited about that.

And another thing that I think is not a big secret is that a lot of the popular libraries in the community aren't well maintained and aren't updated. So even if we have all those new libraries, it's hard for you to integrate all those into your server. But recently Daniel picked up that problem. Daniel from the community actually released GraphQL Helix, which we are already using in production. We highly recommend it. It's a very light GraphQL framework. You can use it with any other framework like Express or Festify or anything else. And you can use all the new features from GraphQL. So we highly recommend that. And of course, there's the big work that Riqui has been doing on GraphiQL and the GraphQL language services. And there's a lot of very exciting things that we rely on there with our own tools. So a lot has happened, and we are very excited about that. But the most interesting thing is that most of that work is being done by individuals, and we want to support other individuals as well who are doing that work. So if you need help, if you have ideas, if you want to contribute, we believe that now is easier than ever. And if you find any obstacle, let us know, and I hope we can help you with that.

So now let's start with the actual talk. So the actual talk, my goal for the actual talk, is to actually present to you how we, the Guild, go about introducing GraphQL into large codebases. We do that all the time with very large clients, and we learned some things that work and some things that don't work for us. So I hope that I can share with you those lessons, share with you the toolings that we use so you can use them yourself, and hopefully it will help you, and hopefully maybe you can learn also from us what not to do. The title for this plan, I call it Gradual and Distributed. And I hope you think about that title whenever you want to use our toolings or throughout that talk. So GraphQL is great, I'm not gonna talk about why here, but let's go into the basics to see where it could actually help us. So GraphQL can help us describe the data and the connection between it, and then we can query it.

So in this example, a client can query a server or multiple services, then the GraphQL engine will actually help orchestrate all those different calls, and for the client it will just be an obstruction. The client will send one request, will get one response in the shape that it asks, only the data that it asks, but also all that work behind the scenes, the orchestration that was being automated, is being basically obstructed away for the client or the consumer.

So we can see here network performance that everyone is talking about, but also we can see that we have a schema of our data graph, basically something that explains the actual data that we want to consume. We also can see from that schema the relations and the connections for the product, in an explicit way, and also we get orchestration and automation.

So the question is, you know, where should we start using it? And when we go about answering that question, we ask ourselves, where does that logic sit today? Because that will maybe be the easiest place to start. Because instead of introducing a new architecture, hopefully we can maybe just automate stuff that are just being done manually today. So for us, what we see a lot is that this logic actually sits today on the client, on mobile clients or web clients. So basically they use REST today, they send multiple calls, and then they do a lot of manual work in order to restructure the data and make it ready to render to the UI.

So when we start using, integrating GraphQL into services, into companies, usually what we do is, or many times what we do is actually introducing GraphQL on the client. And you'll be surprised how popular that way of going about introducing GraphQL is. Not a lot is talked about it, but it's extremely popular. We see it a lot. So that way you can start basically automating a lot of the work. The teams can start learning GraphQL. It's easy because it's much easier to introduce a small dependency into a client app than to add a new server or change the architecture or things like that. People can start learning and understanding the benefits. And then later on, once we're slowly, gradually growing into the front end world and get a lot of those benefits, then at time, later on, we can actually move that code or that orchestration into the server when we see fit and when we see the need. So there's a lot of benefits of doing that on the client. I have a whole talk about that. I won't repeat the talk today. But then once we introduce GraphQL between the client and the GraphQL engine, what about the data sources? I mean, we're still querying the same data sources as before. And in our resolvers, for example, we still call the same rest endpoints that we used before. So what we thought is, how could we start integrating those benefits from GraphQL also into the backend services, for them to understand what they're being queried by, to get a schema? To get, again, instead of just sending a REST call, maybe send a GraphQL query. So many times people actually start converting their existing services or the old services that they had into GraphQL, which in some cases makes sense, but in most companies it's not feasible. Those teams have enough work already. Or maybe those sources are even not maintained by us or by our teams and it's going to take years to do that. So what we tried to do is to think, well, those sources are still there, they're working, maybe they have schemas like gRPC or OpenAPI and Swagger schemas. Maybe they don't have any schema but I can look at the existing responses and maybe generate JSON schemas out of them. So if we have all that information, why can't we just take that information and automatically convert those into GraphQL schemas? And that's GraphQL Mesh that hopefully a lot of you already heard about. And again, the idea is to take the information that we have of existing sources and generate and automatically convert this information into GraphQL.

So GraphQL Mesh has many handlers. You can convert OpenAPI and Swagger, gRPC, SOAP, SQL and even OData and many others. And that's where you can actually start querying GraphQL into those sources without them even knowing what GraphQL is. So you get the benefits instantly, makes the adoption much easier. People can start consuming GraphQL even though the sources are not that.

Now, that's GraphQL Mesh. So once we started doing that, the next phase of that is actually, you know, we have multiple sources some of them are not GraphQL converted into GraphQL, some of them are actually GraphQL, but because GraphQL is based on a data graph, we can actually maybe take all those different sources now and merge them into one GraphQL source. So how do we do that in the community today? Taking multiple GraphQL data sources and merge them into one, like here. And in this case with GraphQL Mesh, again, it could be any sources, it could be GraphQL or not GraphQL. So what's the solution in the community today for that? Apollo Federation. So Apollo Federation is a very interesting technique to help you take multiple GraphQL sources and merge them together. It has a lot of benefits, it also means there's a lot of toolings and there's specific things you need to use in order to leverage Apollo Federation. But the thing is, with GraphQL Mesh, we chose not to use specifically GraphQL Federation. We chose the ability to give you the choice. You can use Apollo Federation but you can also use Schema Stitching.

Now, I want to talk a bit about Schema Stitching for a second, because for many years people thought that Schema Stitching was deprecated. What happened with Schema Stitching actually is that Apollo chose to move into Apollo Federation and not invest more time in Schema Stitching. But for us, working with a lot of clients that use Schema Stitching, we saw that in many use cases, Apollo Federation didn't completely replace Schema Stitching. So what we've done is we took over GraphQL tools from Apollo and basically kept maintaining it and kept improving it. And today I want to show you that GraphQL and Schema Stitching today is not only an alternative to Apollo Federation, but in many cases it's even better. So with GraphQL Mesh, by the way, again we don't choose for you. You can choose between Apollo Federation and Schema Stitching. So what you see here is, it looks like maybe like Apollo Federation, but that's actually Schema Stitching. That's a way to take, I want you to look at the, basically this is a specific service that uses, the gateway is actually a Schema Stitching gateway that takes that source and merges with other sources. The interesting thing about that code, I'm not going to dive too deep into that because I don't have too much time, but this is the most interesting part. This source is just GraphQL. I can use that with GraphQL Express, or GraphQL Helix, Apollo Server, any source that I want. And that means that all the new stuff that I mentioned in the beginning of the talk, all the new things that are now, people could use with GraphQL, you could use with Schema Stitching. So it's simply GraphQL. You don't have to buy into a separate ecosystem, you don't have to buy into a whole list of products.

Like I said at the beginning of the talk, gradually and distributed, you can use GraphQL merging and remote sources without a complete buying into a specific product. In order to dive deeper into that, I won't do that today, unfortunately, because I have more things to mention, but I think you should really check out this repository by Greg, schema stitching demos. What's happening there is that there you can actually see demos of the latest schema stitching. Well, first of all, side by side with some demos from Apollo Federation to compare. Secondly, you can see things there, like how to use subscriptions with schema stitching and also how to live reload specific services into your gateway. If they're releasing new version and how you can leave the gateway and live reload other things into it. So, it's very, very interesting and we keep, like all of our other tools, we're slowly and gradually improving it. And we want your feedback as well.

Now, like I said, gradually and distributively. Now, once we have all the things that I just mentioned, meaning we can take different sources, GraphQL or not, convert them into GraphQL, then merge them together using Apollo Federation or Schemas stitching. And now we have this central place that we can query and with one graph, right? But the thing is, we also care about distributed. So, it's not...we think that you could get all those benefits, get those one graph, get all those things together, but then, instead of making you run everything through one central gateway or one central point that might be a point of failure, with GraphQL Mesh and schema stitching, you could actually get all those different services, introspect them. And then also, instead of just creating a gateway, you can actually generate SDKs. So now, each service can query directly all those different services, that's why it's called GraphQL Mesh, because it can be a mesh of services and those SDKs could sit on your data processing layer, or data processing service on your gateway and even on the client. So you could get this one graph experience, but you don't have to run all of those through essential place.

Now, and you know, just to give you an example of how we use it sometimes, taking all that power, but using it in a very simple use case to start with, you have today resolvers. You already wrote a regular GraphQL server, you have resolvers. Hopefully, if you're using TypeScript, you generated the inputs and the outputs of those resolvers using GraphQL code generator. But then when you call the remote services, it's not typed, you call the same old REST endpoint. You don't have types and you can query that. But if we take all the power that I just mentioned, and but generated into a simple SDK will can get all those types and actually get a powerful SDK that can query all the services in our ecosystem. And that's actually the most popular use case that we see today for GraphQL Mesh. It can be a very powerful gateway, but it can also be just a much better data source for you. So you can just integrate it today into your existing GraphQL services. So that's the beauty and the power of having something that has all the knowledge, all the power of everything I mentioned, but can just be compiled into an SDK.

Now, in order to have that SDK, we need to, somewhere, but still have it being distributed, where would we save all those information, all the schemas from all those different sources. That's the problem that is missing here. And so we want the distributed GraphQL, but we also wanted one-graph information. How do we do that? The answer is simple. We just need the registry.

We just need a place for all those different services to register and say, hey, this is my schema. That schema can be GraphQL, it can be OpenAPI, it can be anything. We can go to that registry, look at it, or look at it just as users trying to implement something, or to look at it as code that would later generate an SDK. And then generate just code that could run anywhere.

So we separated the notion of having everything in one place and the runtime. And I think that's a very powerful idea. Today we are already having that registry running at all of our clients. It's something that we're going to open source. It's called GraphQL Hive. We want to iterate a bit more over it and then open source it. So if you want to try it already, you can try it. But the idea is that you can already use that today on your own registry and any other registry solutions that you have today, just save those schema somewhere and fit it back into GraphQL Mesh.

So again, the idea of the GraphQL Hive is that all of the different tools that I just mentioned today are working separately, but if you want to get the benefits of all of those together, you can have it in a registry. It can be our registry. It could be your registry. You can choose whatever you want. So for us, just to summarize everything I said today, the GraphQL workflow is the most important thing. What is the workflow that GraphQL enables us and then we can choose the toolings that we want and we can use them gradually, and where we want in a distributed way. So we want to execute anywhere. We could use GraphQL Mesh and schema stitching, basically build those merging strategies, but then execute it everywhere. We still want the one graph. We still want to look at all of organization and we want to order what's all the mess that is happening, so we can still collect all those schemas and we can put it in a registry like GraphQL Hive. And again, without the need to put them together in the runtime, so we don't have a central point of failure, we still get the benefits of the order. And also can, you know, some stuff that I didn't mention, we can start enforcing rules. So that's why we released recently the GraphQL ESLint library. We can start enforcing rules and, you know, collaborations and have best practices around all over the company, again, without making people running through a central gateway. We could just, you know, share the rules instead of sharing the execution. Same goes for tracing, by the way, and visibility. You know, once we have all those different environments running, we can gather all the data individually from each of those different sources. We can store it anywhere inside your existing tools today, because you probably already are doing it.

And then you can visualize that centrally. So if you take all your existing tools and just connect them to GraphQL Inspector and GraphQL Hive, you can start having all those benefits of one integrated tool without again, the need of conforming into one ecosystem.

And the most important thing that I want to say today is that it doesn't even need to be GraphQL. All those things and all the tools that we build that are able and giving us a lot of all of those abilities, we can actually take a source that is not GraphQL, convert it into GraphQL using GraphQL Mesh, and get all or at least some of all of those some of those benefits. So, again, that's the way that we go about introducing GraphQL into places. That's how we prevent mistakes. That's how we make sure that we're not buying in too early into solutions that a year two years down the road won't be beneficial. And also we could use the existing solutions and existing sources that the companies have in order to get where we want to be. So, again, distributed and gradual.

For summary, we believe that in order to be successful in those things, you want to get the things that you need only when you need them. And you can do it, you don't need to buy in for a whole ecosystem before you understand the benefits. Gradual and distributed. For more information, you can go to the gil.dev. From there, you can get to our forum, you can reach out directly to our online chat, reach out to all of our open source libraries on GitHub. And basically, we want to hear from you. We want to get more feedback. We're gradually and distributedly improving all those tools separately and together. So, we need your help. We work on them individually, but we want to work with them together with you. Thank you very much. From your poll. How do you feel about that? Yeah, so, I mean, I put it as a trick question. Expected the answers, and the answers were pretty funny. So, thanks for everyone for trying to answer. Some of them were good. Some of them were bad. Most of them were funny. So, thanks. Super funny. There's also one answer that says, Uri killed it.

So, I really need you to hear that, El. So, almost. It's a good answer. The answer is basically, so it was a trick question. So, the answer is it's not deprecated. Most people in the community think it was deprecated in favor of Apollo Federation, which is kind of true. So, Apollo at that time created schema stitching like long time ago. And then at some point, they went with the direction of Apollo Federation and decided not to invest too much time in GraphQL tools. But they were kind enough. So, and we had a lot of clients that used schema stitching. And what we found is that Apollo Federation was good for many use cases, but not all. And we still needed to support schema stitching for our clients. So Apollo was kind enough to move GraphQL tools to us to support. And we've done a lot of work, including basically integrating a fork of schema stitching that was being developed by Yakov. You can find him on our repo. One of the biggest maintainer of schema stitching today. He's doing amazing work in it. And basically, since we took over, it evolved a lot. And I think in the talk, I mentioned the bits about how it's now, not only not deprecated, but actually is a very powerful alternative to Apollo Federation and how we in GraphQL Mesh, we use both. We give you the option to choose between the new schema stitching and Apollo Federation. And we see that actually when people get the choice, they get to choose more and more schema stitching than Apollo Federation. So, it was a trick question. So the answer is basically, no, it's not deprecated at all and it's better than ever. So you should definitely check it out if you use schema stitching before and it was a pain, like some people mentioned, you should definitely upgrade. And yeah. That's an awesome answer. Thank you so much for that. I think that triggers a lot of people's opinions and I'm pretty sure a lot of them were looking forward to this and I can now see why it was a trick question.

All right, so about the Q&A, I think a little birdie has been dropping a few questions for you Uri, from Discord. So Bastian has their question and the question is, is Mesh doing one-on-one conversion? For instance, if I have two end points that are get requests, will you get two queries out of that? Great question, so yes and more.

So basically it will get you a one-to-one, like just by doing that, you'll instantly get, yeah, like basically two root queries, but Mesh also gives you the option to join them into one. And when we say joining to one, it can be between those two end points, but it also means that those two end points are maybe coming from completely different services. Like one can be REST and one can be gRPC or SOAP or OData. So yeah, so it does both. And the important part here is that you have full control over all over the pipeline from the conversion and how each of those end points is being converted to how they being executed to how they're being merged. So it started with, you know, if it's just a tool that does those conversions but very quickly now that so many people from the community are using it and it's becoming like an actual valuable product as a gateway, you need all those customizations. You need like all the power that is possible. So yeah, so today you can do anything with it.