Batteries Included Reimagined - The Revival of GraphQL Yoga

Hi, everyone. My name is Uli, and I'm really excited to give the first keynote talk at GraphQL Galaxy. Today, I'm going to talk about Envelope, our new GraphQL plugin system that you should use on your servers today. But there's also, for this talk, I have a surprise secondary title talk. Batteries Included Reimagined, the Revival of GraphQL Yoga. Those of you who know the Guild and know GraphQL Yoga should get excited by now. I'm going to talk a bit about that later. Stay tuned.

The Guild is the largest open source group in the GraphQL ecosystem. We develop many libraries, they all fit into one big vision. But the idea is that each library is individual. Some examples are GraphQL Code Generator, GraphQL Tools, and Sceva Stitching, GraphQL to basically take any source like OpenAPI, Swagger, gRPC, SQL, and generate GraphQL APIs out of them. GraphQL Inspector for preventing breaking changes, GraphQL Modules for distributing the work between many different teams in the enterprise, and many, many others. And the philosophy of the Guild is that each of these tools should and is developed completely independently. You don't need to use the other tools in order to use any of the tools here. They are fitting into one big platform, from the database and the data sources all the way to the front-end. But you're not vendor-locked. You could gradually introduce these tools when you actually see fit and you see the need. Also, part of our philosophy is not to develop tools that we just want to develop, but only tools that we see a necessity and a need. We rather rely on other open source tools and also contribute to them. But every time we see that the library is not maintained or is not able to accept things that we need from it, only then we basically create a new library. Or what we do many times is we take unmaintained libraries and revive them.

So at the beginning of this year, we saw a lot of need around the GraphQL server ecosystem. And we tried to figure out what do we need and how can we improve it. We tried to contribute it and have talks with existing frameworks in the community. And we ended up creating our own solution. So today I want to talk with you about Envelope. You should also check out the website and look at it there. But I want today to start actually for what was our mindset when we started actually creating Envelope. So the first thing we started asking ourselves, we looked at the existing ecosystem, we asked what do we actually need from a GraphQL server? I mean, this is like a slide that I use in many, many of my talks.

Basically, you see here a client queries a GraphQL server, the GraphQL server then sends calls to all kinds of sources and all kinds of places and the server will send me back one result, orchestrate all the calls and will send it back one result as I expect. And this is something we all know. What is the mechanism here and what do we need from it?

So the core of it is GraphQL JS itself, the reference implementation and the reference implementation. Actually, if we look at the code inside, basically expose a couple of functions for us. Validate, parse, execute, and subscribe. Validate is around validating the schema and the query to make sure that it's actually a valid schema and query. Parse is parsing the query as AST and understand and make it into a document that we can execute. And then the execute function itself which I give a lot of talks around how it looks inside. This is like a pseudocode slide about what's actually happening inside the execute function, meaning the execute function will get the executable schema and the query, and then do all the orchestration and automation work to get the right result in the shape that we want, orchestrating everything that's happening with the network calls or the resolvers. So that's basically the execute function and GraphQL JS. Those are the things that GraphQL JS gives us. But then there's the server. What are the extra things that GraphQL JS doesn't give us that we need from a GraphQL server?

So one thing is the schema creation itself. GraphQL JS has its own way of creating the schema, but the community actually diverges and created many different solutions to create a schema, like SDL-first, a code first with tools like Nexus or GraphQL, which is very exciting and worth checking out, and many others. So you want to create your own schema in many different ways. The other thing that we need to connect GraphQL JS to is actually the communication layer. We need to connect it to an HTTP server, maybe work across WebSockets, and maybe we want to deploy it in a serverless environment and we need all kinds of constraints and things there. And we want our GraphQL server to take care of that for us. And there's many, many different things around operating this GraphQL server, caching and performance, tracing, logging, security and auth, and good error handling. And of course, we want the GraphQL server to have a thriving ecosystem. We want like people to be able to create many different solutions across the GraphQL service so we could use it in any of our use cases and not rely on one single use case that that's the only thing that we need for our server. So once we figured that out, we looked at the actual landscape and this is like a very opinionated slide. You can argue with us, I would love to. But we think that the current server ecosystem has some issues. First of all, the current most populous frameworks out there are very opinionated and sometimes not well maintained. And I think the combination of these two is very problematic. So first of all, being very opinionated means you're fitting into certain types of use cases, usually simple use cases, and because you want to get a lot of community and stuff like that. But then if you combine that with a poorly maintained or library, then it means that now your users can't actually change things and can't get things up to date. So together, this is a very problematic situation. And this is something we faced a lot when we worked with our clients.

We needed a lot of more complex setup and handling all kinds of cases. And the current libraries just weren't enough. It was very, very hard to maintain. And we had to write a lot of weird code in order to get things going.

Also, frameworks being maintained means that they are, they make you build things in a certain way. And then a lot of the solutions that they provide are not being shared between different types of HTTP servers or different types of how you create your schema. Like if you're using code first or schema first. Like everything around the server could be shared no matter what are your choices, but in many of these libraries and frameworks, because they're opinionated, you can't.

Another thing is in the same similar concept, those frameworks wrap the entire request pipeline. So that's okay if you're doing, again, something very simple. But first of all, it depends. Sometimes if you work with an HTTP server, like let's say Festify or Express or Coa, you want to use their full power. And second of all, sometimes you're actually deploying in environments that are different. And you want to actually have the full flexibility like edge, like CloudFlare Workers and edge deployments, and then you want, you need more flexibility in how you handle these things. You want to hook into this system and have the full power so you can deploy it anywhere. And some frameworks do allow for minimum extensions and things like that, but from our experience, this was very, very hard to work with.

And we kept trying to contribute, we kept trying to help them do things better, but at some point we got into a limit. And there was another thing where some of the frameworks are built for a certain purpose. They're built to make, for you to use more of the tools of these companies. And that means that the technical choices also, you see that in the technical choices. And that means that it's hard to use all kinds of custom made solutions that sometimes are needed for complex applications with these server frameworks and their architectures.

So we went back to the drawing board and what you see here is actually the first sketch that we had of Envelope. And I'll try to kind of like reverse engineer what we were thinking at the time. So we took GraphQL GS and we took the function that it exposes, parse, validate, execute and subscribe. And we thought, what if we could hook into the system? We could maybe hook before and after parse, before and after validate. Eight functions before and after all of this. So we can have, we can change anything and then we can still expose the same API. So anyone that uses just GraphQL, the reference implementation could still use the same thing but now we got hooks into the system with powerful plugin system. Each plugin could basically hook into each of this, into every step of GraphQL. And then also we connected basically, just gave you the option to give your schema.

So, and that schema could be anything, could be a nexus, could be geographical, could be schema first with GraphQL tools and also federation, which I'll maybe mention later on. And then this is all in separation of the request, HTTP request pipeline.

So, when you handle the HTTP request pipeline, we leave it to the best tools that do that work like Fastify, Express, Coa, and also maybe in other environments like serverless environments. So you have the full power and you just use these frameworks as they're intended to, there's no reason for us to make a better Fastify or to wrap Fastify for you.

So that's Envelope. And that's what we released about a year ago. And this was a game changer for us. We deleted so much code working with clients using the system. And today the ecosystem around it is huge and I'll now share why. So what are the things that we actually, that Envelope helped us with. First thing, there's a lot of hard graphical things that we kept repeating and doing again and again with every client. And now instead of repeating these things and depends on the client that depends on the setup, now we could share, we could turn that logic into a plugin and share it across all the ecosystem, all of our clients and all of our open source users.

So here is an example when we start an Envelope server. In this example, we get an extremely performant server just by adding three plugins with three lines of code. Use parser cache, use validation cache and use GraphQL JIT. Just by adding these three things, our basic server becomes way faster than probably your server today. And you as a server developer didn't need to do much. You just needed to choose some plugins and add them with one line of code and that's it. But for the plugin developer, they had a very powerful API to hook into every step of the system. And I think that's the power of Envelope. For the users, for the server developers, it's extremely easy. And for the plugin developers, it's extremely powerful. You're not losing. The simplicity doesn't interfere with the power.

And now you could actually, and also when we started building all these plugins, we saw more and more people from the community actually contributing. So we created a plugin hub. It's a place where you can just explore and there's many, many different plugins today. For many hard things that people used to create a lot of conference talks and a lot of blog posts about it, now it's as easy as writing a plugin like there's plugins for caching, tracing with whatever you want, Prometheus, DataDog, New Relic, Sentry, OpenTelemetry, Apollo Tracing, Loggers. You could use persistent queries, all kinds of plugins around security, like rate limiting, depth limiting, cost analysis, all these things and many, many others. So again, you get a very rich ecosystem that you could use with whatever technological choices you want to make.

So, and that leads me to the second point, which is we can now with a plugin solve each problem once and share it across the ecosystem, which is a very powerful idea that for some reason wasn't until now. So it doesn't matter where you deploy, an Envelope server could use the same plugins and be deployed using any HTTP server and in any environment, including CloudFlare workers on edge, which is what we usually do. So this is extremely powerful thing. And also you could use any schema you want, including by the way, Apollo Federation.

So with some clients that we have that use Apollo Federation, we actually replace the Apollo Gateway. We just in place, we took out Apollo Gateway on the existing federated services and put it, and put in Envelope with the Apollo Federation support. And now we get both the benefits of Apollo Federation and all the powerful plugin system of the ecosystem. And that was really, really cool to do.

The third thing that I think was really cool with Envelope is that it now became a framework for frameworks. You could use it just as is, but it's also a plugin system that is very powerful. So now all kinds of different frameworks could actually be built on the same core infrastructure. Instead of just building on top of GraphQL-JS they have the Envelope plugin system. So each framework can choose their opinions and make it easy for you, but still share plugins and still share solutions. There's many different examples of frameworks that already work with Envelope. The most famous one that you're probably gonna see today and there's a talk later on in GraphQL Galaxy is Redwood-JS.

Redwood is an amazing framework. You can build apps extremely quickly with this. And they, at the beginning, were based off Apollo Server. And then for all kinds of reasons, they decided to also add Envelope support. Once they added Envelope support, their initial idea was to actually give the users options to use Apollo Server and Envelope. But after a month of using Envelope, they just removed Apollo Server completely. And now, with their 1.0 version, they're completely on Envelope. And they wrote an amazing blog post about why, and then forum posts about why they did it. And I think you should read it because there's a lot of benefits to do that. And there's many more frameworks coming. So you could use Envelope as is, but you could also use frameworks that are built on top of Envelope. And there's one more thing that I'll mention soon.

Another thing that we saw is that when we started using Envelope and we started sharing these pieces of code and plugins, a lot of our clients are actually large corporations and they want to have a certain way. They have many teams that are building their own GraphQL server and they're also in charge of deploying them and maintaining them, but they want to have some kind of conformity. For example, one way of logging or, you know, saving tracing, or all kinds of security rules that they want to share between all the different teams and all the different GraphQL servers that they have.

So what we created was kind of like an envelope of envelopes so you can create basically a base plugin that has all the different, all the shared plugins in your company, and then you can share that across all the different servers and the servers could add and customize their own plugins. But now you basically created a powerful server that has all the shared infrastructure across all of your organization.

One example is Klarna is one of our great clients, and recently they actually tweeted and talked about how they moved their whole infrastructure to envelope and the amazing things that it made them, that it helped them across the whole company. There's many more of this, and I hope to soon share more and more of these case studies and many companies that did that transition.

But the last thing that is really cool with envelope is that it also acts, because we are hooking into the system, it also can act as basically a Babel for GraphQL. So if you think about the JavaScript ecosystem for many years now, we're using all kinds of features that are not necessarily supported with all the browsers that are not in the spec. But we already use them thanks to like, tools like Babel and many others. With envelope, we now have the same capability, but with GraphQL. We specifically, the Guild are using for over a year now across all of our servers, we're using defer and stream, live queries with the one off directives and many other very powerful tools and many very powerful GraphQL primitives that are not yet in the spec. It takes time for things to get into the spec and for good reasons, but it doesn't mean that you can't and shouldn't use them. All these tools are extremely powerful and made the way we write GraphQL servers way better. And thanks to envelope, you could actually use that today.

So to learn more about envelope, you should go to our website, also on the YouTube, we have a YouTube link there on the bottom. You can actually find a talk that I gave that for basically in 15, 20 minutes, I start a server from scratch with zero lines of code into a full server with defer and stream and live query support. So you should check out the talk and also of course the docs and start using envelope. But today I have one more surprise.

Envelope like I said is a framework of frameworks. And at the Guild, we always try to be, to start with the core and being open and very flexible and not be too opinionated. But if some of the people in the community are aware of this symbol and what it represents, for many years we had basically a very famous GraphQL framework in the community, it was called GraphQL Yoga. It was extremely simple, all the goal of this framework was built by Prisma. And their goal was to make it as simple as possible to start the GraphQL server. And it really pushed at the time it pushed the edge of like how easy it is and how simple it is to start a GraphQL server. Prisma moved on to other ventures and we're less focused around it. But they were very kind to work with us and to hand us over GraphQL Yoga. And I'm very happy to announce today that we just released the first 2.0 alpha version of GraphQL Yoga that you can start using today. The idea here is that GraphQL Yoga, we basically, we build GraphQL Yoga to be a wrapper around an opinionated rapper around envelope. So you can enjoy everything I just said about envelope, but still start extremely easy and basically have a batteries included framework that has, not only like the batteries that it is included with is out of the box, you get GraphQL subscription support, defer and stream support, official and up to date local host graphical support. You don't need to have graphical in the cloud or anything like that. And it's modern, it's up to date, it's extremely performant. It's still very flexible because you can still completely customize it thanks to envelope plugins.

And the most important thing is that like all of the libraries of the Guild, this is gonna be maintained for the longterm. For the past four or five years, we basically showed the community that every library we maintain is there for the long run. And now finally, we have a GraphQL server, a full GraphQL server framework that is here to stay and to get better and better and better. And it's already the best in the community. So I really hope you go and try it out. Just Google GraphQL Yoga, get to the repo and the alpha 2.0 version was just released and we want your feedback.

So to summarize, we thought that you deserve and the ecosystem deserve a better server ecosystem when you actually go into production. It was always very easy to start. But when you go into production, things started to get a bit less flexible and a bit less powerful. So now thanks to Envelope and YOGA, you get a modern GraphQL server. You can use the power of the open community. You don't need to rely on a certain ecosystem. You don't need to rely on the GIL. There's a whole ecosystem of plugins. Our tools and our libraries are always up to date and always well maintained for the long run. So now the combination of Envelope and GraphQL YOGA should give you a lot of powerful, a really powerful server that you can really build upon safely. Not to mention that you can still use all the other frameworks that are, in the ecosystem of frameworks that are still built on Envelope, like Redwood JS for example.

So thank you very much for listening. I really hope to get more of your feedback around this and because we're mostly proud in the GIL of always being there, always listening to the community and improving according to the community's needs and not just by random ideas that we have. Thank you so much and have a great GraphQL Galaxy conference, everyone. We're going to look at the results of the reverse Q&A where Juri asked you a question. So Juri, hey, thanks for joining me on stage. Let's have a look at the results. So the winner is Apollo. Is this what you were expecting? Actually, no, but I think Apollo actually, Apollo server doesn't support the current stream. I think they have like an open issue for about that, but they don't support it yet. From the answers that we can see here, I think actually- I think this one is the best. Which, yeah, the emoji one is the right one. Yeah, there's actually, so most of the answers here are from the JavaScript ecosystem things. I think, I'm not sure actually if Azure supports defer yet or not.

I'm actually, I'm not sure about that, but Envelope and GraphQL-Leoga do support defer and stream and also many other new features of GraphQL that are, even if they're not in the spec, like part of the thing in Envelope, it's kind of like the Babel of GraphQL, so you could use features that are not necessarily in the spec yet and then use it already today. We use it for a couple of months already, especially defer, it's like a very powerful feature and we like it a lot. If anyone watched like the relay talk on the React conf yesterday, relay has defer support, so if you want to use that, you could definitely use it with the envelope in GraphQL Yoga.

Cool. All right, let's jump over to the real Q&A. We have a question from Alexander Vaurvik, who's also speaking later today. Are there specific JavaScript language features that the system depends on? Do you think this method of working could be applied to other languages? Yeah, that's a great question. We do think, and we also have plans, so one of the things we want to do is to, first of all, part of the reason I'm giving this talk is for other people in the community from other ecosystems to look at this approach, because we think just the approach itself should be great and, like, is great, at least in our opinion, and should be copied into other frameworks in other languages, but we also have actually plans to kind of, like, let's say, add plugins to GraphQL execution in a, let's say, language-agnostic way. So it's still in process, and we have some POCs, but, yeah, it's definitely something we're thinking about, and if someone is, like, hears that right now is developing a framework for other languages, or by the way, other, like, frameworks for JavaScript, talk to us. Like, we would love to help and just share the idea and get feedback and work together to, you know, to bring this idea to as many people as possible. And then enhance the whole ecosystem, of course. Nice. Thanks, Yuri.

Next question is from Danny. Danny Z. One of the limitation we now see in using Helix and Envelope is the lack of something like Apollo Studio. Why is this? Our testers are used in testing operations straight into the Studio. The question I have, does the Guild have any plans in having a service similar to Studio? Yeah, so, few things about it. First of all, you could use, actually, GraphQL Studio with Helix and Envelope. The whole point of every tool we created the Guild is that it works with anything. Like, we are not vendor-locking. So, we actually, with Envelope, we have a plugin for Apollo Tracing, for example, and you can completely use all the different tools from Apollo, including, by the way, one thing that we are doing with clients of us that are using Apollo Federation is that we replace the Apollo Gateway with Envelope. So, we actually take the Apollo Federation piece that, you know, combines the schemas and executes them and everything and run it inside Envelope. So, you get the best of both worlds, you get all the plugins from Envelope and Apollo Federation. So, for the first part of the answer, it is possible to use Helix and Envelope with all of Apollo tooling. So, if you're having any issues with that, let us know. For the second question, if we do have a plan for something that is like Apollo Studio, it's not only that we have a plan, we actually have something out there that's called GraphQL Hive, and it's a service that basically is a schema registry and it does many, many things like tracks also your requests live and tells you when you could deprecate them, shows you what our slope queries are. It connects to Datadog and Century and other services. So yeah, definitely also check out the GraphQL Hive. All right.

Well, we have one minute left. So I'm going to ask a short question that was asked by Alexander, again, me, and another anonymous user. What did you use to create awesome animations in your slides? So the credit is not actually for me. I'm the, let's say the, I draw it on a piece of paper and it looks horrible. And then we have a freelance designer that works with that. His name is Idan Avshalem and he's amazing. And he's helping me for years now doing these slides. Yeah, it's really nice that I can like think visually because I'm a visual thinker. And then I can actually bring it into slides and explaining to people. So he's been a tremendous help for me. But he's not available because he's working for you exclusively or people can hire him? No, no he's available for hire. If anyone wants to contact him, just let me know. He's amazing, I highly recommend him for everyone. Yeah. And all the, by the way, all of the actual execution of his designs is on Keynote. Like it's all Apple Keynote, like all the animations and everything and everything that's moving. It's actually Keynote animations and he created it. So yeah, I highly recommend him. I thought he did it like in After Effects.

Well, Jurri that's all the time we have?

So thanks a lot of course for joining us here today. I think you're still joining us later on for discussion room, right? Or lightning talk, discussion room. Yeah, I'm doing a couple of panel discussions. Thank you so much for having me.