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 it later. Stay tuned. So 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. So some examples are graphql Code Generator, graphql Tools, and Sceva Stitching, graphql Cache 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 GraphQLJS 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. I'll show you the pseudocode, the 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 GraphQLJS. Those are the things that GraphQLJS gives us. But then there's the server. What are the extra things that GraphQLJS doesn't give us that we need from a graphql server? So one thing is a schema creation itself. GraphQLJS 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, code first with tools like Nexus or Geographical, 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 GraphQLJS to is actually the communication layer. We need to connect it to an HTTP server, maybe work across web sockets, 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 that 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 people to be able to create many different solutions across the graphql server 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 that 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 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 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 for a schema first, 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 that 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 need more flexibility in how you handle these things. You want to hook into this system and have the full power. So you could deploy it anywhere. And some frameworks do allow for like, you know, minimum extensions and things like that. But from our experience, it 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 built 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.js 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 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. And that schema could be anything. Could be 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 HTTP request pipeline. So when you handle the HTTP request pipeline, we leave it to the best tools that do that work, like Festify, 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 Festify or to wrap Festify 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 this system. And today the ecosystem around it is huge and I'll now share why. So what are the things that Envelope helped us with? First thing, there's a lot of hard graphql 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's 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. And 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 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 an 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 replaced 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 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 build, being built on the same core infrastructure. So for instance, building on top of graphql GS, they have the envelope plugin system. So each framework can choose their opinions and make it easy for you, but still share plugins and steer yourself, share solutions. There's many different examples of frameworks that already work with envelope. The most famous one that you're probably going to see today, and there's a talk later on in graphql Galaxy is Redwood GS. 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. 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 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 shared plugins in your company. And then you can share that across all the different servers and the service could add and customize their own plugins. But now you basically created a powerful 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 helped them across the whole company. There's many more of these 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 or 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 of directives and many other very powerful tools and many, very powerful graphical 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 graphical 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. So 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 graphical framework in the community. It was called graphql Yoga. It was extremely simple in that all the goal of this framework was built by prisma. And their goal was to make it as simple as possible to start a graphical 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 graphical server. prisma moved on to other ventures and were 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 built graphql Yoga to be a wrapper around, an opinionated wrapper 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 a 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 going to 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 should try, 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 Guild. 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 all 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 because we're mostly proud in the Guild 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 Jiri asked you a question. So Jiri, 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 different stream. I think they have like an open issue about that, but they don't support it yet. The answers that we can see here, I think this one is the best. 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 Azura supports defer yet or not. I'm actually, I'm not sure about that. But Envelope and graphql Lyoga 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 acts 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 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 and graphql Lyoga. Oh, all right. Let's jump over to the real Q&A. We have a question from Alexander Varbeik, 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 is great, at least in our opinion, and should be copied into other frameworks in other languages. But we also have actually plans to add, let's say, add plugins to graphql execution in, let's say, a 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, here is a, here is that right now is developing a framework for other languages, or by the way, other frameworks for javascript, talk to us. We would love to help and just share the idea and get feedback and work together to bring this idea to as many people as possible. And then enhance the whole ecosystem, of course. Nice. Thanks, Jeroen. The next question is from Danny. Danny Z. One of the limitations 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 a few things about that. 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're not vendor-locking. So we actually, with Envelope, you 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 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 Hype. And it's a service that basically is a schema registry. And it does many, many things like it tracks also your requests live and tells you when you could deprecate them, shows you what our slow queries are. It connects to Datadog and Sentry and other services. So yeah, definitely also check out the graphql Hype. 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. And let's say 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 Amshalem and he's amazing. And he's helping me for years now doing these slides. It's really nice that I can think visually because I'm a visual thinker. And then I can actually bring it into slides and explain it 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, he's available for hire. If anyone wants to contact him, just let me know. He's amazing. I highly recommend him for everyone. And all of the actual execution of his designs is on Keynote. It's all Apple Keynote, all the animations and everything that's moving. It's actually Keynote animations and he created it. So yeah, I highly recommend it. I thought he did it like in After Effects. Well, Jurij, 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 a discussion room, right? Lighting talk, discussion room. Yeah, yeah, yeah. I'm doing a couple of panel discussions. Thank you so much for having me. All right, Jurij. See you then. Bye-bye.