The Guild has recently released Envelop - a new, modern GraphQL Server Framework and plugin system. In this talk I’ll share a brief overview of Envelop and why you should probably upgrade your existing GraphQL server to it.
Batteries Included Reimagined - The Revival of GraphQL Yoga
AI Generated Video Summary
Envelope is a powerful GraphQL plugin system that simplifies server development and allows for powerful plugin integration. It provides conformity for large corporations with multiple GraphQL servers and can be used with various frameworks. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild offers GraphQL Hive, a service similar to Apollo Studio, and encourages collaboration with other frameworks and languages.
1. Introduction to Envelope and the Guild
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. The Guild is the largest open source group in the GraphQL ecosystem. We develop many libraries, they all fit into one big vision.
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.
2. GraphQL JS and the GraphQL Server
GraphQL JS is the core of the system, providing functions like validate, parse, execute, and subscribe. However, a GraphQL server needs additional features such as schema creation, communication layer integration, and operational aspects like caching, tracing, logging, security, and error handling. The current server ecosystem has issues with opinionated and poorly maintained frameworks, which can limit flexibility and updates.
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.
3. Introduction to Envelope and Plugin Integration
We needed more complex setup and handling all kinds of cases. The current libraries were hard to maintain and required writing weird code. Frameworks make you build things in a certain way and limit sharing solutions between different servers and schema creation methods. Some frameworks wrap the entire request pipeline, limiting flexibility and making it difficult to use custom solutions for complex applications. We went back to the drawing board and created Envelope, which hooks into the GraphQL system and allows for powerful plugin integration.
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.
4. Leveraging Envelope for Efficient GraphQL Servers
So, Envelope is a powerful GraphQL plugin system that allows you to optimize your server with ease. By adding just a few plugins, you can significantly improve your server's performance. Envelope simplifies the development process for both server developers and plugin developers, offering an easy-to-use API and a rich ecosystem of plugins. With Envelope, you can eliminate repetitive tasks and share logic across your entire ecosystem. The plugin hub provides a wide range of plugins for various functionalities, making it easy to enhance your server's capabilities.
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.
5. Envelope's Power and Framework Compatibility
With Envelope, you can solve problems once and share them across the ecosystem. Envelope is a framework for frameworks, allowing different frameworks to be built on the same core infrastructure. Redwood-JS is an example of a framework that has adopted Envelope. Many more frameworks are coming. Envelope also provides conformity for large corporations with multiple GraphQL servers.
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.
6. Envelope: Sharing Plugins and GraphQL Yoga
We created an envelope of envelopes to share shared plugins across servers, creating a powerful server with shared infrastructure. Klarna is one of our clients who moved their infrastructure to envelope. Envelope acts as a Babel for GraphQL, allowing the use of powerful tools and primitives not yet in the spec. Check out our website and YouTube talk for more information. We also released GraphQL Yoga, a wrapper around envelope that provides an easy way to start with batteries included.
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.
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.
7. GraphQL Yoga and the Power of Envelope
And the most important thing is that like all of the libraries of the Guild, this is gonna be maintained for the longterm. We have a GraphQL server, a full GraphQL server framework that is here to stay and to get better and better. 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, thanks to Envelope and YOGA, you get a modern GraphQL server. You can use the power of the open community. There's a whole ecosystem of plugins. Our tools and libraries are always up to date and well maintained. The combination of Envelope and GraphQL YOGA should give you a really powerful server. Thank you so much and have a great GraphQL Galaxy conference, everyone.
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.
Envelope, GraphQL-Leoga, and Apollo Integration
Envelope and GraphQL-Leoga support defer and stream, along with other new GraphQL features. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild plans to add language-agnostic plugins to GraphQL execution. They encourage other frameworks and languages to adopt this approach and are open to collaboration. Regarding Apollo Studio, Helix and Envelope can be used with GraphQL Studio and other Apollo tools. The Guild has a plugin for Apollo Tracing and is compatible with Apollo Federation. They also offer GraphQL Hive, a service similar to Apollo Studio, which includes a schema registry and other features.
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.
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.
Animations in Slides and Gratitude
In response to a question about the awesome animations in the slides, the speaker credits a freelance designer named Idan Avshalem for his amazing work. The speaker mentions that Idan has been a tremendous help in bringing their visual ideas to life. Idan is available for hire, and all the animations in the slides were created using Apple Keynote. The speaker highly recommends Idan's services and clarifies that the animations were not done in After Effects. The speaker concludes by expressing gratitude for the opportunity to join the event and participate in panel discussions.
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.