Batteries Included Reimagined - The Revival of GraphQL Yoga

Rate this content
Bookmark

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.

Uri Goldshtein
Uri Goldshtein
33 min
09 Dec, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

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.

Available in Español

1. Introduction to Envelope and the Guild

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

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.

7. GraphQL Yoga and the Power of Envelope

Short description:

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.

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.

QnA

Envelope, GraphQL-Leoga, and Apollo Integration

Short description:

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.

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.

Animations in Slides and Gratitude

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Simplifying Server Components
React Advanced Conference 2023React Advanced Conference 2023
27 min
Simplifying Server Components
Top Content
Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.
From GraphQL Zero to GraphQL Hero with RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Local State and Server Cache: Finding a Balance
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
Exploring React Server Component Fundamentals
React Day Berlin 2023React Day Berlin 2023
21 min
Exploring React Server Component Fundamentals
Top Content
I've been developing a minimalistic framework for React Server Components (RSC). This talk will share my journey to deeply understand RSC from a technical perspective. I'll demonstrate how RSC features operate at a low level and provide insights into what RSC offers at its core. By the end, you should have a stronger mental model of React Server Components fundamentals.
Server Components: The Epic Tale of Rendering UX
React Summit 2023React Summit 2023
26 min
Server Components: The Epic Tale of Rendering UX
Server components, introduced in React v18 end these shortcomings, enabling rendering React components fully on the server, into an intermediate abstraction format without needing to add to the JavaScript bundle. This talk aims to cover the following points:1. A fun story of how we needed CSR and how SSR started to take its place2. What are server components and what benefits did they bring like 0 javascript bundle size3. Demo of a simple app using client-side rendering, SSR, and server components and analyzing the performance gains and understanding when to use what4. My take on how rendering UI will change with this approach
A Practical Guide for Migrating to Server Components
React Advanced Conference 2023React Advanced Conference 2023
28 min
A Practical Guide for Migrating to Server Components
Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with. We’ll also discuss next steps and strategies for gradually embracing more aspects of this transformative paradigm.

Workshops on related topic

Build with SvelteKit and GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Scott Spence
Scott Spence
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
End-To-End Type Safety with React, GraphQL & Prisma
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
Sabin Adams
Sabin Adams
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL for React Developers
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
Roy Derks
Roy Derks
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
Build a Headless WordPress App with Next.js and WPGraphQL
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
Kellen Mace
Kellen Mace
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
Relational Database Modeling for GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
WorkshopFree
Adron Hall
Adron Hall
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura