Everything You Need to Get Your GQL Server Production Ready

So I'm Uri. I'm a member of a group called The Guild. How many of you heard about The Guild? No one? I've heard. Okay, cool. So I'll just share a bit. The Guild is a group of open source developers. I personally started this group a couple of years ago. I used to work at Apollo. I was actually in the team that started Apollo. We built another thing called Meteor. It was a JavaScript framework, and we thought what would be the next version of Meteor. Back in the day, it was just the days that Facebook opened source to GraphQL. So we thought that maybe the next version of Meteor will be based on GraphQL. And that's how we started Apollo Client, and Apollo Server, and GraphQL Tools Library, and many things that are still popular today.

So I started there at Apollo, and then after a while, I decided to build another group that is structured a bit differently to basically build a sustainable open-source. So the libraries will be well-maintained for the long run, for many, many years, and there wouldn't be pressure of, like, there would be less pressure of selling a product but more of just making sustainable open-source. So that's the yield, like, tools that we build today are GraphQL Code Generator that I'll talk a bit about today, GraphQL Mesh, Envelope, GraphQL Inspector, GraphQL Modules. Very new, we took over GraphQL Yoga, if some of you have heard in my talk, I'm doing also the keynote for GraphQL Galaxy, and in the keynote I'm gonna announce something about that, so you will know that even earlier than everyone. We basically today are the biggest open-source group in GraphQL, and we also do a lot of work that is outside of the GraphQL realm, like with OpenAPI and all kinds of other APIs, like JSON Schema, grpc, all kinds of other, so we do work there as well, so that's a bit about us, and how we work is that we work with actually clients, with companies. We build open-source tools, and then we consult, and also help them introduce the tools, and improve the tools, and things like that, so all of the tools are being built out of real necessity, like that we don't open-source a tool that none of our clients are actually using in production, everything open-source is something that we use in production, so you can know that you can rely on it, and you know there's an actual need for it, and it's not like something we're selling to you, or we do it for popularity reasons, or things like that, so that's a bit about the Guild, every member of the Guild is a member that actually contributed to open-source before they joined the Guild, and also sometimes maybe it's hard for you to find our libraries, because all of the libraries are under people's names, and not under the Guild name, we believe this is a better model for a more sustainable open-source, it's very rare, it's not something that is very common, but that's how we do it today.

I mentioned the Guild in the beginning, we build a lot of different tools, I won't talk too much about that, but just that all of our tools are built in a specific way, both in the open-source way that I mentioned at the beginning, and also they complete a full platform, so the idea is that it provides you with everything you need from the backend to the frontend to build an app, but you could use them completely separately, we're not pushing you to use them, it's not like a vendor locked platform, each tool could be used by itself, we try to break down these tools into the smallest pieces we can, so they will be the most flexible that's possible. And I'm mentioning it now because I think it's important and that's also part of the reasons of why we created some new tools that I would introduce today, because we think in that way actually we can solve things better. And so, I'll touch a bit about that and I'm also doing my introduction to the tools. I'll share maybe a tutorial with you that I think in my opinion, it's better structured compared to other GraphQL tutorials out there because it separates some things. So, I'll get to that soon. But let's go back to the basics of GraphQL. Again, everyone here knows probably a bit about what GraphQL is. It's a query language. You could describe the data that you want to query in a schema. That data could be any data. That's the interesting part about GraphQL. It's a query language, but unlike SQL, where you need to structure your data and your tables in a certain way, here, you could basically create a schema, query that schema, get predictable results. But that schema could describe any data. It could be something you layer on top of a REST API, which is very common. It could be just a file. It could be a database. It could be anything that you have, any data that you want to query, an Excel spreadsheet, anything. So that's interesting because you can now start building graphs of data, of whatever data you have. And you can also layer it in places that are, let's say, that maybe you didn't think about before. I hope I can touch upon it again. So I'm skipping this one. It's just an example of, with REST, you could like query any, if you want to get a list of chats and stuff like that, then you're gonna like query back and forth and maybe you need multiple requests and response. And you could build custom REST endpoints, right? So it's not always true. You could build the perfect REST GraphQL endpoint and you will still get exactly what you want. But that means that that work is being done on the backend. With GraphQL, the client could just describe what they want and get exactly what they want. So extra round trips is like something that a lot of people are talking about as a, I don't know, is something that GraphQL could solve and also over fetching, right? Like you might have an endpoint and in this case it's a certain endpoint for repos on GitHub and you're going to get tons of information that you might not need. So over the wire where that matters, you're going to get a lot of information. This is just something I copied from GraphQL.org. By the way, we are now kind of like we rebuilt the infrastructure for GraphQL.org and we were trying to make it the better resource. So, one thing if any of you are actually interested in documentation and helping your team on board and things like that, I hope to make graphql.org the best place to go and learn about GraphQL and to find all the resources and everything I'm saying now, hopefully you won't need to talk to me. You can just go to graphql.org. So, if any of you are interested in helping, this project didn't move so much for many years and now we to cover it and hopefully we can make graphql.org a better website. So yeah, so, you know, GraphQL what everyone is displaying is that like, I can query for just the data that I need and I can send one query and get back one result. Today we're going to talk about more advanced stuff as well. A bit about, you know, maybe an illustration of how it works. So we have a client and let's say some data sources and in the middle we put, let's call it the GraphQL Engine instead of a GraphQL server. And I hope you can, later on you'll understand why I'm calling it an engine and not a server. So, and we can describe the data of all these data sources using a schema. So you write that schema. There's many different ways of running that schema. We can talk today also about like different ways of writing a schema, that schema could, it could be written merely. And that manual schema could be written in what's called an SDL. So the actual language of GraphQL, what you can see here on the left, but it's gonna also be written with code. So you could write like classes that represents these data structures and there's plus and minus or objects that represents these data structures. And there's plus and minuses for both approaches. And there's also different libraries for all these approaches. If you're interested in that, let me know because I have a lot of opinions about that. So we describe the schema and then the client can basically query for a certain thing that they want, let's say in this case, the user with AB2 and a name, and then the graphical engine would get that query and will execute it in the most efficient way they can. So they would go and fetch maybe the user and then extract from the user object the name and send us back what we actually need.

And if we want more information about the user, let's say we send a bigger query, so maybe the servo will get us back the user object and then the graphical engine will actually fetch in parallel the name and the messages if they can see that it can. And then maybe the content can come from a completely different source, but the way we modeled it, we modeled it like the client sees the data, wants to see the data and we modeled it like messages and their content are basically look like the content is basically the same. It's part of the messages object so then the client gets back one single results and it doesn't matter how complicated the server is or how many data sources or how many services your backend has. For the client they get the representation of the data that they expect, which is an important point, I think when we'll get to talk a bit about GraphQL mesh, which I'll talk, I hopefully get to talk today.

You will see that there's two different philosophies of how do we describe the schema of the data? The schema that is basically all of our data sources together in a graph or the schema that the client actually needs. And I hope to show you today that those are, might be two different schemas. So, yeah, so that's like a basic illustration of how GraphQL works, very basic. Now let's dive a bit deeper into that just to understand, because for me, when I talk about GraphQL, I actually just see that there's a function. So I'll show what that function is actually and what that function is actually doing.

So when we describe the data, we also write resolvers. Resolvers are the way to tell GraphQL how to fetch each field. In this case, you know, we have a function. Let's say we want the user's name. So we basically create the function that we know what is the object that it's gonna get as inputs. We know what the inputs that were getting into the function. In our case, it's like a user object, let's say. The parent of, the parent resolver, the entry point for the graph. And then we can execute any code we want. It's basically a function. So we can do whatever we want in that function, including calling another server or anything, and we need to return a string because we defined a string. So that's what we need to do when we create a GraphQL server or a GraphQL engine.

Now, everything you're gonna see in this slide is basically a slide that I'm trying to explain to you like the basic work of what the GraphQL function is doing internally. So everything here, I always, when they show that slide, I ask people to think while they are seeing that slide, where do you write the code today? So the GraphQL function basically gets these resolver functions that were created in the schema. Then it creates, and the other argument that it gets is a query. Really, think about it as a function that's called GraphQL and gets two variables, two inputs. One is called executable schema is that definitions that we see on the left, and their functions. And the other argument is that query that might change between different calls. And then what the GraphQL function will do is that it will get that id 10 that we got on the top, on the query, and execute the first box, the first function. And it will get back an a result. That result would be a user object, let's say. Now it knows by the credit that we need a name and a message. So what GraphQL will do is it will take the boxes and will execute them in parallel because it can, because both of these boxes are actually requiring the same parent value. So it will execute them in parallel. One box, the name will give us the string, we're done. So it will put that in the right place. Then the messages, we actually get three different messages, objects. And for each one of them, we want the title and the date. So now the GraphQL engine will actually run all these different boxes for all the different results. And when the results will arrive, because all of this is async, every box here is an async function. So we can call a remote endpoint or something like that. When the results will get, it will put all the results in the right structure in the right place and will give us back the results. That's the GraphQL function.

Now I think, so what we saw here is GraphQL not only like just minimizes the data that we send over the wire or something like that, but actually GraphQL automates a lot of the data work that we do ourselves, maybe in code or in other means. So GraphQL awaits and orchestrates all the different network calls that we needed to make and all the different actions that we needed to take in order to get the data that we want. And then it also shaped the data in the way that we want. And I think that's the biggest benefit of GraphQL in most environments. In most environments, it's not about necessarily saving some bytes over the network, but actually automating a lot of the data work that we do anyway. And the data work is done in many different ways. It could be done on the client, it could be done on a server, it could be even done on like data analytics services and stuff like that, they query many different services from many different data sources, get the data that they want, and then do some analysis. So all of these could potentially benefit from GraphQL. So, that's kind of like what I just said, like we get network performance, we get like schema of the data graph, but also we get orchestration and automation and we get to have relationships and to model all of our data in a certain way, even if there's many different sources that might not necessarily be connected otherwise. So those are some of the benefits that I think GraphQL has. By the way, if it's very basic, let me know and if you have questions or you want to take me into other directions while I'm saying that, then also let me know.

So many times when we go into a company and we start to work with companies and we actually want to bring GraphQL into like an actual implementation and solution and get it to production as quickly as possible, we think, well, where should we start from? And in my opinion, the best and the easiest place to start from in order to, I really believe that the sooner you get the use case and go into production, the better. Instead of preparing too much, you need to go into production as fast as possible with this very simple use case, and then you actually see what you're really gonna hit.

Of course you can prepare and we can talk about it today, but still I think all the workshops in the world wouldn't prepare you as much as just trying it out. So our goal is always to, how quick, what's the quickest way to get GraphQL into production? And that's why I asked you in the last slide, where do you think that logic that you saw GraphQL was doing today, where do you think it's happening today?

So I'll give you an example of where many of the apps that we work with, where did they have that logic before we came? Most of them, they had an app that's use REST API. Those REST APIs we'll build or very generically. So they were like very restful and kind of like a very neat and organized. So that meant that on one hand, it's very easy to navigate the API. On the other hand, the API like the client actually needs to go. And like I demonstrated at the beginning, it needs to fetch a couple of different endpoints. Then take the data and then maybe remove the data that they don't need. Then maybe merge it in some other ways and then structure it in a way that the UI actually needs. The app actually needs. So a lot of that work is actually code that runs on the client today.

So what we are doing many times, and that's why I call it the GraphQL engine or function instead of a GraphQL server, is that we took that work and we took everything I've showed you before, and we just put GraphQL as a function on the client. So what you see here is that we are still on the client and we're still orchestrating and doing all the work, but now the UI components actually could query in GraphQL the data that they need. The queries are very similar to the structure that the UI needs. And then GraphQL is doing a lot of automation. Basically, we could remove a lot of the manual code that is being done on the client and just using GraphQL GS, let's say, or whatever client you might have. Where you run that logic through GraphQL and over the network, we still use the same old APIs that we had before.

Now, that's interesting because I think it's a good also for many different reasons. The first one, like I said, the goal here is to get into production as fast as possible. So it's easier in terms of convincing people in your company, right? Like you didn't make a huge architectural change. You actually just installed the net, let's say if you're working in JavaScript, you just installed another NPM package. You didn't do anything. You didn't add a server, you didn't add a gateway, none of these things. But you already start using GraphQL and you already started removing a lot of manual code. And what you also started doing is you started modeling in a schema, in a graph schema, the data that your app needs. And that's the important part here.

The second important part, like I said, so the first one is to get into production as fast as possible. The second one is to start model data according to what your app needs and not necessarily according to what your server exposes or what your data source is exposed. Now, that is a powerful thing because I'll give you an example. One thing that we still have an open source, but if anyone here wants to start trying it out you can try because we just tried it on a couple of new clients. We just now created a Figma-GraphQL-script plugin. There's an old one that someone built many years ago. So we now build a new one. And the idea there is that you could look at the design. You could actually look at the designs of your app and then you build your GraphQL queries on top and according to the design. And I think that's an important mindset because now you create a schema that actually represents your app data and you might not even know if like if the data actually exists and where and how your server exposed it. But that's, I think how we see like the best GraphQL schemas that serves the products are being built. They're being built from the product perspective. So that's, you know, the... So the second part, what it's important to maybe start is helping us to sort like that is that we by definition describe the GraphQL schemas as what the app needs and not necessarily this generic or server driven schema. It's a product driven schema. So that's another benefit that we get from this approach.

Now, and again, this thing is now something that basically orchestrate our data flow. It explains to us what is the data. There's in a schema in a very clear schema that it's easy to share and show everyone what the app needs. And now we can figure out where to, how to do the orchestration automation work. And then we can take, let's say later on, let's say we could now take the same code, even let's say we wrote it in JavaScript. We can actually take the, almost the same code and almost the same function and move it to the gateway, let's say. And now we also get the benefits of network calls and things like that. By the way, if I go back to this state, someone mentioned, for example, so here, maybe we don't get the network, more efficient network calls and stuff like that. That's half true because someone mentioned the N plus one problem in data loaders. Everyone knows how to use data loaders on the server but here we can actually start using data loaders on the client already. So we actually might get like a very efficient or better ways of querying our data sources even though, or start optimizing the calls for our data sources, even though we're still running on the client. So yeah, so that's just like one thing that we see a lot when we go into production. Let me skip this. Okay, so I'm going through a bunch of things. And again, yeah, let me know, yeah, if you have any questions or things like that. And the other thing is that I talked a bit about these resolvers, these functions that GraphQL executes the end. And because we defined the schema, we know what's the inputs and the outputs of each of those of these resolvers. That means that we could actually generate in whatever language we want, we could generate using code, GraphQL code generator. We could actually generate the inputs and outputs of these functions. So we get a fully, if we're using TypeScript, for example, or Java or.NET, it doesn't matter. We don't need to manually create these types. We could automatically create these types and have these functions fully typed when we give it to a person to actually execute their tasks, right? So it's a very clear definition of what the task is and the types that we were gonna get and the types of the thing we're expecting to get back as a result from these functions. So it's a very, very powerful idea. So if any of you are not using GraphQL Code Generator, many people know about GraphQL Code Generator for the front end, which means you could take the query, understand from the query, the types that you're gonna get and then generate the types and maybe even SDKs and type SDK to query the server. Here we're using GraphQL Code Gen on the front end, on the backend, sorry, on the resolvers themselves. Like I'll just show you if you go to the Code Gen websites, maybe you know all of this already, but on the Code Gen website, you see, we have this like playground here.

Here, there's a list of all the different plugins that we have on Code Gen. Many different languages, many different use cases, but we also tag them by front-end and back-end, right? So if we see here, let's take this thing, so we get the schema and then we also get the queries. So here we're gonna generate actually the types of the queries, what we're actually gonna get from the query in specific fragments. But also, we can go to the back-end side and generate like what we said here, the resolver signature. Basically what are like types of the functions that we actually gonna execute? Yeah, by the way, this is a new thing, we just rebuilt the website and now there's like a plugin hub where you can explore all the different plugins here and each plugin has a different website, like a different page and you can tag by whatever label you have by whatever you want. If you want purple and see everything works with purple. Yeah, anyway, so that's cool. That's kind of like something that we are, that you probably should use if you're using GraphQL. And it just helps you understand the types and write code and validate it while you're writing it. And another by the way tool that you probably should use if I'm already added, I already stopped this thing is GraphQL ESLint. So that's another relatively new tool we had. There's a couple of other libraries around GraphQL and ESLint. I think Apollo has this library for example. If you're using it, stop using it. It's un-maintained. It's the last commit was 2020. It was by Renovate. It's really old and there's many reasons why it's not so good. There's another one. This one is maintained by us. It's very up to date. Yeah, you can see commit, let's commit three hours ago. And also we just released three hours ago. The idea here is that it's built in a much smarter way. And the idea here is that it validates. It has many, many different rules you can choose from. We added also presets for recommended rules, both for frontend, meaning for queries and for backend. And the cool thing is that it is separated for rules. So it will highlight all of these things while you were working on your code base, but you can also create custom rules. So many companies that we work with have all kinds of like best practices or things like that that they work on that they want to enforce here and they need to teach and they have docs for it here, you can just enforce it with your own tools. Yeah, so. Yeah, and there's like, each plugin actually has like... Yeah, there's like the recommended stuff. But then, and there's how to create plugins and stuff like that. But okay, here are the docs, you can see you have many different, like all this is generated from source code. Yeah, it's just relatively new libraries. So a lot of people are like not still aware of it. And then there's many rules you can choose here. And you can create your own custom rules and then also maybe share it with the community. And some rules are like for actually for front-end. For example, like they need both the documents, like the queries and mutations and the schema. And you could actually, they could warn you if you're, let's say, on the schema, for example, unused types. So you can tell you, for example, on the schema, this type is unused, for example, on any of the front-end, if you want. Yeah, so there's good documentation for everything. I don't know, I just, I'll go back to my slides. But if you haven't heard about GraphQL ESLint, write it down. I think it's a great tool. So then, so now we have resolvers. Those resolvers may be around on the front-end or on our gateway. And we use GraphQL Code-Gen and they're typed, or maybe we used Code-First approach, which also I have some opinions about the different libraries. We are now gonna support probably a new library around that. I wonder, by the way, does anyone here, so some people said they're using Apollo server. So that means you're basically using, probably you're using, like schema-first, which means you're using GraphQL tools, which is also our library. So just one note here, if you're using Apollo server, which we'll get to soon about if you should use it or not. But anyway, if you're using Apollo server, I recommend you to import, when you make your executable schema, like you run your SDL and attach it to resolvers and create an executable schema, I highly recommend you to actually import that function. I'll show you that. From the makeExecutableSchema function that you're probably using when you're using Apollo server, I highly recommend you to use this one from GraphQL tools schema and not from Apollo server. The reason is Apollo server just wraps this function, this library. It doesn't do anything more, but Apollo server is wrapping this function for you, which might sound convenient, but it also means they're out of date. We keep releasing new versions of this thing that are it's for many different reasons, security updates, and dependencies updates, many new abilities, and also new, make it more efficient and all kinds of things like that. And Apollo is not following so often and it's not updating their library so often. So also Apollo actually now on their issues, if you see, and you see the latest comments are also recommending you to use actually make a securable schema from GraphQL tool schema and then fit that into Apollo server. So that's just a recommendation. And this is, by the way, if we're talking about GraphQL tools, GraphQL tools has many, many different things. And we really invested recently in like a very thorough documentation around GraphQL tools. So now I highly recommend you to go through a lot of the things here, even if you are not... It's just, there's an overview of a lot of different toolings that we're building here. And I think it's valuable even just for general knowledge around GraphQL. GraphQL tools is another library that we maintain. As I said, here, you can see in any of our websites, you can see here all the other different tools that we develop and we'll go through them hopefully to explain why we develop them and why we recommend you to use them.

So anyway, but the way I want to say about that is like, that's if you're using GraphQL tools, then you should use it together with the code gen, with graphical code generator and generating the types. But also you might use code first, is anyone here using code first approach? You need to, if you do, you need to speak because I think I can't see. I think I can't see anything. I did before in a project, but the last one was code first approach. Which library did you use? Apollo server. Apollo server but which library did you use for defining the, the schema itself? Like, there's like type GraphQL, there's a Nexus GraphQL, all kinds of things like that. Do you remember maybe? I think, no, I use the Apollo tools for everything two years ago and, and with code first approach I was using NestJS. Ah, NestJS, yeah, yeah, yeah. Yeah, yeah. So NestJS is another framework. I also share, can share my opinion, but it's later. And well, NestJS their code first approach is actually pretty similar to type GraphQL. So it means like you're writing codes similar to that probably, right? Like it's looked a bit like that. Like we, we have classes and- Yeah. Yeah. So, yeah. So NestJS actually was dependent on type GraphQL and then for whatever reason, they decided to move into their... They forked it for some reason, now you import all these things from NestJS GraphQL instead of type GraphQL. I'm not sure exactly why. Yeah. So code first approaches you see has benefits and there's many different solutions like Nexus as well. We are now usually most of the way... So some of the benefits are that you don't need to write SDL independently of... You get type safety and you don't need to run code to get the type safety you need. Not that I think that running code is hard, but some people are getting annoyed by it. So there's many different solutions, by the way, Nexus, which is another famous way of writing your code first schemas actually uses Code Gen under the hood. So it's not really that they don't use Code Gen, but there's also other solutions. There's like GQTX and there's Geographical. And so we kind of like started looking into this and then actually if you are going with that approach, I think the GQTX and Geographical are actually let's say better maintained than the other solutions. You can see here using Geographical with Apollo server. So you basically build your schema that way and then you just send it an executable schema to Apollo server. So you asked me also a bit to recommend some tools. We are now in the process of probably we're gonna work with the person that wrote Geographical and we're probably gonna do a comparison between all the code first approach, like Geographical, GQTX, NestJS, Nexus and TypeGraphQL and probably gonna make, yeah, something like find the best solution here. Now, there's another thing that maybe I can talk about it here, but it's not out yet, but I want to share it with you. If you're thinking, do you have this question around what should I do? And there's another thing you need to take into account. Let me try to find it. Just a second. Yes, this thing. I'll share the link in the chat. Oh, right. I lost the chatbot. Zoom, I don't know how to. Okay. I'm just going around here. Also, tell me if something is wrong. TypeScript actually added a lot of new features recently, and you can start using the actual TypeScript parser to do some really cool things. What this PR is doing, and it's been, we are experimenting about it in a while, but actually, since TypeScript 4.5, it's actually usable. We just feed the schema first, basically the graphical schema, what you see here, the type depths are just GraphQL, so type query full string. Like, it's not code first, it's schema first. But TypeScript understands the types. So in this case, we actually get the benefits of code first. Like, there's no, you don't need to run a generator or something like that, it's something in the middle. You could actually write the types of types. But because of all kinds of new features in TypeScript, SDL1 is typed. So now we can tell the resolvers, just use the types from the infer the types of this and get this fully typed. So this is really cool. You can see that actually recently, Vatan made some new updates here. So we're really close into actually releasing it. And this is really exciting. So probably after we do that, we're gonna release a new blog post. First of all covering, maybe it will be two separate blog posts. We'll see, but like first of all, we're gonna probably work with the guy that wrote GraphQL. So we're gonna make some order in the code first approach, even though until now we were mostly focused on graphical tools, because we think also in the code first approach, there were some libraries that are not so well maintained. Nexus was really popular. Prisma pushed it for very long and then kind of like stopped maintaining it for a while. So we want to jump in there as well and like create better solutions there. And we want to like expose this just second, there's like really crazy storm here and my window just opened itself. Give me just one second. Sorry about that. Yeah, it's in Israel you don't get too many days of winter, but when you get them, it's really stormy.

I hope you don't hear a lot of noise while I'm talking. I do. I hear all kinds of things flying around my building. Anyway, yeah, this is just some background for this code first, schema first debate that a lot of people want me to comment on so, yeah.

Just a second. Okay, so, wait. The zoom is weird, just a second. Okay, so going back to the resolver part. So again, I'm covering here a lot of subjects. So I hope you're writing some things down I hope you will stop me and ask me questions about all of this.

So we started from creating a GraphQL executable schema whether it was code first or schema first, and then the describes the data from the client or the product perspective, that's an important part. And now when we get into the implementation, into the resolvers, we got those resolvers typed, whether it's code first or schema first thanks to GraphQL code generators. But what we usually do then is we call the underlying data sources. That's the most common way that people are working on this. And at that point, that's where when people started GraphQL, that's where they stay. It's like, okay, I have a GraphQL thing working and I'm enjoying the types of GraphQL and I enjoy code. And maybe if I'm more advanced user and that's great. But then after they get that and maybe they get this minimal thing in production, some things, the first things that I think people are seeing are that they really enjoy the GraphQL experience but on the resolvers when I call a remote call, let's say I called my arrest data sources which is the most common use case, I still have no types for that remote call, right? Like we didn't change anything on our backends. Like the backends, let's say it's a REST API and we don't maybe have a swagger definition or anything like that. Or maybe we do and it's up to date, outdated, it doesn't matter what. It's still a REST endpoint. So the endpoint is still not typed. So what we started thinking was, well, if we're looking at this diagram of like the client and then we put the GraphQL engine in, let's say it started from the client then moved to the gateway. So could we actually also simplify the work of querying our backend services? Maybe our backend services are... Why can't we also enjoy all these cool stuff on the backend? And some people, what they do is they start using GraphQL on the backend, which has benefits, but also has downsides. And that's a good debate to have, by the way, like, should we turn everything into GraphQL or maybe there's other protocols that are better? I would say, you know, we can also also kind of like... So there's a couple of things here. First of all, depends on your use case, maybe usually this thing is just not realistic. Like you have a lot of existing data sources. Those data sources are probably written, depends on your company, but probably written by other teams. These are the teams don't have the time to now move to the latest cool, fancy technology because you just decided this is the cool, new, fancy technology. So usually it's unrealistic. But let's say it is realistic, let's say we can now choose to move all of our data sources into GraphQL, should we do it? And that's a big debate. Actually yesterday I was in a panel with Lee Byron and I raised that question and we debated a bit about it. So one thing is that, like I said, all the existing data sources we have, there might be, maybe they don't have time to migrate to GraphQL and it's unrealistic, which is the most common usage. But also if we can, think about the work that we saw on the slide of, where is it? The, this slide. In GraphQL, this is the work that's being done on the GraphQL box or basically the provider. So when we talk client and server, let's say this is the server, right? Let's say this is the GraphQL server right now. The work of like manipulating the data and like manipulating the data, orchestrating the data, waiting for all the network calls. All of this work is current, is done by the provider. The client doesn't need to do it to the network. That's okay, but that's a trade-off. We get the trade. What we get from the trade-off is that over the network, we get less data. So it's more efficient for the network calls. And also we save a bunch of code on the client. But like we said, for all kinds of reasons, we might do a different trade-off and actually move this thing and do it on the client. Now, if we're talking service to service communication, we're talking gateway to backends, like in this case. In this case, we care a bit less usually about the size of the data that goes through the network. So the fact that we can do GraphQL here, like on the servers, that means that now the data sources will actually need to do more work, right? They need to filter the data and they need to do all that algorithm that GraphQL function is doing. And that will also make it harder to cache. So maybe it's not the right trade-off. So I'm not saying it's nothing, I'm just saying it's, yeah, it's, I'm just saying it's a trade-off and you might choose this and you might choose that. So another option, by the way, is gRPC, right? gRPC is a very efficient and still-typed protocol, like protobufs. So we still get some of the benefits of GraphQL, like types and generated SDKs, but we don't get the query language. So the query language is the thing that like, has a trade-off and we need to think for each source, do we want gRPC or do we want GraphQL? Yeah, so that's the debate. Also, yesterday, I had with Lee and he talked a bit about how it is, what's the setup in Facebook and now Robinhood, where he works. And it was also part of a bigger debate about Federation, because Facebook, what I always say is that Facebook, and in this case also Robinhood, and Facebook is the largest, it's the largest GraphQL schema in the world, doesn't use Federation. Right? So we keep telling us that Federation, you need Federation in order to scale your GraphQL APIs, but in that case, then why Facebook doesn't use Federation? Right? So maybe there's, it's not necessarily the right solution for scaling for whatever that means. So that's why this was important to me to share with the audience, actually, what's actually happening in Facebook, and it was good that Lee Byron was there. So there's like all kinds of trade-offs and we're maybe, we're not gonna convert everything into GraphQL for all kinds of reasons. Now, but we still want to get some of the benefits of GraphQL. We still want to get the type schema and we still want to get maybe the query language. But maybe we don't want to change our data sources both because it's unrealistic to change them and both because maybe it's not architecturally good to change them. Maybe they need to be gRPC, maybe they need to be REST, and then it's easier to cache. By the way, we will talk also about GraphQL caching later, but in general, like if you have predictable results, it might be easier to cache. So, let's look at our existing backends. What we thought was like, can we look at our existing backends and generate... Like, and get the information that we get from there anyway, right? Because their existing backends, even if they're not GraphQL, they might be open API, so we have schemas or JSON schema or gRPC. Maybe they don't have all of this, but there's documentation about what's happening there.

Like, we can look at the documentation, but the documentation could say, this endpoint returns this JSON, and this endpoint returns this structure. And maybe we just have the logs, right? Maybe we can just, we have the live data, or we can ping. Like, what do we do when we start developing an Apollo data source? We just call the endpoint for whatever information we get, we try to understand, and then we call it handpoint, and hopefully we understand the data that we get. So what we thought was to make that process safer and more efficient. So maybe we'll take all those different ways of understanding what all those different sources are giving, and maybe we could actually create schemas out of them. And if we're gonna create schemas out of them, why not actually create a GraphQL schema out of them? So, you know, we could take JSON schema, Swagger, GRPC, maybe we'll manually create a JSON schema or whatever, and maybe we'll record responses, and then just from that we can actually generate GraphQL schemas. I'll skip that part for a second. So that's GraphQL Mesh, which GraphQL Mesh is a library that takes all kinds of different sources, no matter what sources they are. It could be SQL databases, all kinds of things. And it generates GraphQL schemas out of them. It takes them, it converts them and generates artifacts that you could save locally, like if you don't want to introspect your backend, your services all the time, it generates artifacts. This is by the way, a new change that was made recently. If some of you are using GraphQL Mesh and haven't updated for the last, let's say two months or three months, this is a new change that we've made. It generates artifacts, and then you could treat those artifacts as if they were regular GraphQL endpoints. I'll show that in a second. But now you basically could do anything you want with those artifacts, as if they were great endpoints. You can query them, you could link them, you can send them into GraphQL Inspector to check if there weren't any breaking changes, anything like that. So yeah, so that's GraphQL Mesh. So as you can see here, like any source you could query, we worked with many different, that's why we also expanded into other API technologies, and we started seeing also kind of like pluses and minuses there. There's a lot of cool things. For example, in JSON Schemas, we don't have the GraphQL, so we started and also in OpenAPI. So we started actually, we started adding new features to GraphQL. We started adding features to the GraphQL spec, which is another subject I want to talk with you today. There's a lot I want to talk with you. But in other subject I want to talk with you about how with Envelope, which is the new GraphQL plugin system we build, you could use GraphQL features that are not in the GraphQL spec. So when we're talking to what's a GraphQL servers you should use, I have a very specific opinion about. I hope we can get to that soon. So again, GraphQL Mesh, and we get to query GraphQL, but using our existing services. And like I said, we didn't put that burden of, it was the same idea of running GraphQL on the client. We get like a GraphQL SDK that has been executed by the client, or in this case, the service that queries the services. So let's say the GraphQL gateway gets an SDK. I'll show you that in a second what I mean, maybe it's confusing of it, but basically, everything I taught until now, if you're using Apollo, this is a replacement for Apollo data sources. So let's use using Apollo server. And then when you call remote data sources, you use Apollo data sources. This is basically a way more advanced and better Apollo data sources. So the first phase that I think you should do if you're using Apollo server is to change and remove your Apollo and migrate your Apollo data sources into GraphQL Mesh SDK. That's one of the first things we're doing. That's one of the first steps we're taking once people already have a GraphQL Server in production. We're changing the Apollo data sources into GraphQL Mesh SDK. Again, the scheme, if you can see on the right, the GraphQL server, let's say in your case if you're using Apollo server hasn't changed. You still wrote a GraphQL schema and you still wrote resolvers. But inside these resolvers, you're gonna use a GraphQL Mesh SDK's instead of Apollo data sources. And the GraphQL Mesh SDK not only can take each source converted into GraphQL and get you a fully-typed SDK, it could also take many, many different data sources and merge them into one single GraphQL SDK. Now, that's interesting because what we could do with that is basically, let's say I'll give an example of a client we have. I'm not gonna name the client, but it's a huge e-commerce website. They're commerce, actually. They have also commerce and they have also a huge e-commerce website, and they have tons of, tons of different services. For the services, they use Java and OpenAPI and stuff like that, and then for the gateway, they are using TypeScript. And migrated recently from Apollo Server to Envelope which is a common thing with... I'll talk about Envelope a bit later. So what we've done is we've started, that's exactly what we started doing there. We started Apollo Data Source by Apollo Data Source. We just moved source by source and migrated that into GraphQL Mesh SDK. At the end of the day, what we got is basically a catalog, a GraphQL representation of all the data sources in that company, it's huge. It's a huge company. Even though these data sources weren't at all GraphQL. So just that made basically the whole data across the company visible for everyone, more queryable and easier to query for everyone. And even management suddenly saw what you have and started seeing duplicates, not this, they're like sort lines of codes, but actually duplicates in teams. There were teams that basically were developing many similar things. So management actually started looking at the whole huge schema that we generated and started understanding like, and managing all these teams better. But again, this was the first phase, we actually didn't do anything with the gateway and we didn't change anything other than creating a nicer SDK for the resolvers. Basically just the type this the key, like everything, all we wanted to do here, I show you all kinds of fancy solutions, but I want to show you again what we did here. We just took, let me maybe show it here. We took the resolvers that were partially typed and all we did was to just make that remote call types, that's all. But in the process, we created a whole catalog of all the data that exists in that company. So that's a bit about GraphQL-mesh. GraphQL-mesh is like, again it's a powerful SDK that merges all of, like the first phase is to take any source and convert it into GraphQL. I want to also show you code and like examples on how it actually looks. And I also see if we want to make it, I'll send you a workshop that you can follow commit by commit. Okay.

But then we also merge that into one single SDK, very powerful SDK. By the way, that's merging. If we're already are talking about it, this merging can... It's a merging of many different GraphQL sources. GraphQL-mesh supports two different types of merging capabilities. One is Apollo Federation, and the other one is schema-stitching. I also have a lot to talk about these things.

Apollo Federation was marketed as the next version of schema-stitching, but to be honest, it's a different thing, and it has a lot of trade-offs. And they also stopped maintaining schema-stitching and GraphQL tools. So what we've done is we took GraphQL tools from Apollo. We completely rebuilt schema-stitching, and today schema-stitching is actually a more capable solution in terms of abilities than Apollo Federation because in Apollo Federation, it's like a very opinionated solution, which might be beneficial. With schema-stitching, you could actually federate Apollo Federation services today. But you could also do more. You could give some of the responsibilities also for the gateway and not just for the services. So also if you're now debating with yourself as you grow in your scaling, do I need to use Apollo Federation? Do I need to use schema-stitching? Or maybe I don't need any of those at all. We could definitely talk about here today or you can also text me later and talk to me later because as I just talked about, there's many different approaches here. And even though some companies wants to show that the only way to go with scale is Apollo Federation, always think that Facebook is not using Apollo Federation. Uber is not using Apollo Federation, Twitter is not using Apollo Federation. And they're probably a bigger scale than you. So there's other solutions and you should just be aware of all the different trade-offs that you get. Also one benefit of schema-stitching is that you could see it has different, similar mechanisms to Federation, but it's just GraphQL. There's no new spec here, the servers that you write are just plain old, simple GraphQL servers. You don't need to lock yourself into a certain ecosystem into the Apollo ecosystem in that case, or any other company that now is using, that has there's all kinds of Federation solutions out there. Yeah. So those are just things to remember.

So yeah, so GraphQL mesh, like I said, the first phase is to create it as an SDK. Like you see here, let's say I have a service, a gateway that has a GraphQL schema and things, I can just use that as an SDK. But I can also take GraphQL mesh and actually run it as a server, as like a central place to execute all that I call and everything goes past through this thing, and then this thing sends it to all the other services. So you can think then about, in that constellation, you can think about GraphQL mesh as like, like Apollo Federation, but for any source. It could be anything and not just federated services. But the thing is about GraphQL mesh, even though this is like Apollo Federation, but for any source, we still not necessarily think it's a good idea. Maybe you don't want the central place that everything goes through. Maybe you can take the same experience and get the whole graph of all the different day so data sources, but the execution will be on the producers. It will be decentralized and distributed. So there's no one point of failure. So the gateway here, when they call the service, it feels as a developer that you have one place with all the information, but what's actually happening is that like the network requests are going directly into the services and not through a central place like Apollo Federation or like all kinds of other solutions in the community. So that's another trade off that, when you grow and you scale and you should probably think about it, right? Because if now you're creating a central place that everyone and everything is going through, the bigger scale you're going to get, if this thing's is going to, if this thing, first of all, there's going to be more load on this thing. And second of all, if this thing is going down for whatever reason, you're basically fucked everything. So maybe it's better that like it will actually be distributed.

So I wanted to show a bit, to demonstrate this approach of GraphQL Mesh and all the things we could do with it. So actually we created a workshop that commit by commit walks you through this. So first of all, I'll share the link. So you could also do it really close with yourselves at your own pace and at your own time without stress. This is the workshop, the GraphQL Mesh workshop. Let me just share it here. But anyway, I'm writing here my email, I'll write my details here. I think you should copy it because I don't know if it saves all the history. So you always can contact me for anything. Also my details actually are on my GitHub profiles. I'll just share my. Just so you have it. Anyway, so that workshop, you see there's five commits in that workshop. Each commit is a working phase of what I just said. So the first phase is just probably what you have today with Apollo Server and Apollo Data Sources. Probably the server that, the first server that you will go into production with, most users, that's how they work with. And then we're basically commit by commit. We're adding a mesh gradually. So first it's just replacing the data sources with mesh SDK. Then actually, you know, until we get to the point where, you know, we call it no code. Basically there's nothing out, existing outside of the, just the graphical mesh configurations. And each step here is a good step. Like you don't need to go all the way with your servers. It depends on your architecture or all kinds of things like that. But yeah, so let me just, you see my screen, right? I think you do. So I'll just, instead of running all of this, I'm going to just walk you through the server. So this is a regular server of Apollo server. You see, we installed the Apollo server. We have an Apollo server instance here. We have basically two APIs here. One is APIs of breweries.

And the other way, another one is a geo API, just all kinds of cities around the world. And we also have a Apollo data sources. The rest API of geo and the rest API of open brewery. That's probably similar to what you have today. Maybe I'll, let me try something. Just a second. Okay, let me, I'll go here. I just, I have a white canvas here. Let's see if it works. So let's say we have, let's see if this will work. Yup. So basically what we have here is two data sources. We have, this one is a geo API and this one is, let's call it beer API. Okay. Those are REST APIs and those are out of our control. Let's say they're microservices of a different team or in this case, it's just third party, right? That's what they are. Now, what we are building here right now, what usually we're doing is we're taking, we'll building a GraphQL API. Let's say this is Apollo server, and this Apollo server, this Apollo Server sits here and queries this, and then we have, of course, like a client here, so many, all kinds of different clients here that are querying this. Are querying this GraphQL server using GraphQL. So, yeah, so basically like, this is GraphQL. Yeah, so that's cool, that's what it is. Now, let's go back to the setup. So, this is the, and probably everything I'm showing you here is what you're used to, right? So, I'm not installing the dependencies right now because I want to like, do it really quickly. So, we have Apollo data sources, right? Like maybe I will, let's see, just so there won't be errors. So, I have an Apollo data source, interest data source. I give it, you know, like a base URL, and I'm creating a Find Breweries API function, with the Get of breweries, right? That's what I get. Same thing for the Geo API, right? I have a base, and I call it here. What is the problem here, with Apollo data sources? Then, in the resolvers, I want to call this data source, right, like I'm adding it here, you know, if you're not aware of, so I'm adding in here all of my Apollo data sources, and then I can, to the context, this is how I put it into the context of my GraphQL server, and then, I can bring it from the context, and call the function. This is my resolver. That's cool, but if we look at this, this is ME. This is not type at all. I don't know what I'm gonna get here. So even if I got GraphQL Code Gem, to generate those ME types, GraphQL Code Gem, what it will do, it will automatically type all of the things here, and it will also add automatically a return type here. So that's what GraphQL Code Generator. So even though GraphQL Code Generator will basically generate the functions for this function, when I call this, I don't have any types. Okay. So then we're moving. What we're doing is we're gonna install GraphQL mesh. I'm gonna switch to that commit. When you're going through the workshop, I'll show you that commit here. So you can actually go to the commit and look at the diff. Like what we are actually doing. So we're installing npm install GraphQL mesh CLI, open API, and JSON schema. I'll explain why in a second. That's all we've done. Now, let me also, one yarn, once we're here. So what we've done is we installed here and then we introduced GraphQL mesh yamo. Let me show you that GraphQL mesh yamo. GraphQL mesh yamo lets us and it lets us basically define what we need. Like our sources. So we said one source is geodb, this is this API, it's the geo API. Now I want you... The thing about this API, it has an open API Swagger definition. Let me just go here, geodb I think, not geo, what is it? Mesh, build mesh. Okay, so this is an open API, it has a Swagger, let me show you. Oh, it's good that it's printing this as well, so I'll show you in a second, the process what it's done here. So this is a Swagger file of that API that describes all the different things we could query this from. So that's one API, the other API is the open breweries API, this API doesn't even have a Swagger, it just has a website with documentation. You know, think about probably you have a team and the team has a docs website, they don't have actually like anything real to work with. So all they have here is examples, right? You see, they have an endpoint and the example. What I've done here with Mesh, I told this, hey, Mesh, this is like an open brewery, it's a JSON schema API, this is how you call it. And those are the things that I want to get from it. It's a method called Get, this is the path breweries, you see, I got it from here, breweries, I want to generate the query field. And here is the example request and here is the example response, those I just copied from here. And then what, just so this is the whole GraphQL Mesh config, okay. I just, basically what I've done, what I'm doing manually anyway in my head, I just put it here. Now when I run Mesh Build, what happened is you can see here, I hope you can see it big enough, cleaning existing artifacts, reading the mesh configuration, generating mesh schema, generating artifacts. This thing I'll get to in a second. So let's look at what we have now on here. Let's look at the sources.

This is all generated, dot mesh is generated. Let's look at the GeoDB. What it did, it called that endpoint that we said, and it basically downloaded the swagger schema here. So we have all the swagger schema locally. So next time if that's that, let's say the swagger file is not available, we still have it locally here.

And here we have the generated, basically GraphQL Mesh generated the JSON schema for us from based on these examples. So that's cool. That's the first phase. Those are the sources that we can work with. But then what GraphQL Mesh did, it generated this thing. What you see here is a GraphQL schema file that is generated according to these sources. So all of that schema file, we didn't write anything here. You see, there's like tons of like countries here, enums and things like that. All of this is generated according to the sources. So that's what Mesh did for us.

Now, let me go back to that commit that we've seen. So that's what Mesh did. Now let's look at how it affected our project. First of all, we completely removed the code for the data source. It's gone. But now let's look at our, what happened to our resolvers. Instead of having this data sources.godbapi.dat, we have the GraphQL Mesh SDK that we loaded here. And we have this thing. Find cities using get query. Let's look at it on the source code to make it actually interesting because now it just looks the same, but we just removed the data source function. But if we look here, this is the interesting part. Let me, yeah. Let's look here. Look at this function. This is completely typed. The arguments are typed. In this case, they're not typed because the source is not typed, but here you see, it's completely typed. And more than that, I can now do this. You can see I have all the different functions that this API is with autocomplete that this API gives me. If I'm going to call something random, not true, it's not going to compile. So I got this like amazing type safety like being generated for me. So that's why this is so much better than Apollo data source but that's just the first phase of using GraphQL mesh.

Let's look at that. That's the only one step of the commit of the tutorial. The next step is we can even take this further. Oh, let me the way what we have, this is the SDK. I didn't explain the other part of here is this thing SDK. I just told mesh to generate the SDK. That's what I told mesh here. Please from all these things, give me an SDK. So that's what mesh has done. By the way, mesh generated that SDK using GraphQL code generator under the hood. So it's mesh itself is broken into a lot of small libraries. So then let's move to the next phase. So let me check out the other, the next. Let's see. So what we're doing in the next phase is let's look at the mesh RC, instead of generating an SDK, we told mesh first of all, we merged those different sources. So we can have here, we can tell mesh what we do here. We can actually all kinds of custom code. Let's say we want to add custom resolvers to that. Like we have the generator resolvers, but we also want custom resolvers. We can have mesh just put it here in the config file. So we just put here the extended SDL that we wanted because you want to connect actually those two sources together. So we just extended it here and then the resolver itself is just a file. And that file is fully typed by the way, because everything is fully typed and that's the connection between the breweries and the mesh. Maybe I'll explain it better. Let me run it. Maybe it'll be easier. Yeah, so what you see here, by the way, are you, I'm not sure if everyone is here and hearing me. I don't know. Or I'm just talking to myself. Let me. I am. Okay, okay, okay. Okay, if I'm not being clear, then let me know.

So what you see here is a query. I'm querying the finding cities using GATS, so I'm querying one source, but then I'm also querying the breweries inside that city, like as if it was one source, but it's two different sources. So that connection, I could do it in code, but in this case, I actually did it like here in the mesh configs. We also, by the way, we have no easier way to even define those. And with the custom resolver, I don't know why this is like this. I think it's just, anyway, but this is, yeah. So I think it just did an update to the VS code. So that's the next phase. Like what we've done here, let's look again at the def of that thing. What did we remove? We removed the resolvers and we removed the type defs completely. I mean, even the index, right? All of this, we removed. We didn't left with much, right? We removed the Apollo server completely. Now mesh acts as our server. Right, so that's all we have. Like think about the project before, we had tons of code and tons of stuff. Now everything is generated and all we have is this additional resolvers function. But then let's take it one step further. No code. We can actually do this connection right from here, from the configuration. Like the connection between two sources, we can basically say, from the target, where do we get it? What's the selection set? And then from the source, where do we get it? And how do we connect them to? There's by the way, an easier API even. And now that we're doing this, let me check this thing out. I'm jumping here, like this is a workshop, that I usually do for like, but let's see. How do I get, let's check out master. Yeah, that's just switch to bench. Okay, so now if we look at this, we have no code here, we just have a package JSON. A meshRc file and the sample resources, sample sources. That's it. Just the meshRc is everything we need, and also we can, it's a server now, so we can tell it which port to run. So that just shows you like, how flexible mesh is, and the gradual, like, you know, where it could be introduced into your environment.

So, yeah, so there's, this is like, so I shared the link of the workshop. Save it. Before I go into tons of more things that I want to do, and it's already, we have 40 minutes, questions around that? I'm sure you have questions, so. I have one. Okay. Let me do it this way. In my company, we have, I worked for Zillow in the US. In the project I'm working, we have a lot of endpoints. You know, every endpoint is like a function, right? You know, like find this or get that. So what I did is I used code chain, and I created a resolver by hand for each one of them, you know like a function for each one of them. So now I have 10 REST APIs and then functions. Okay? So what you're using GraphQL Mesh, what you're saying instead of doing manually creating the schema GraphQL, do all the typing, do all the, you know like the running code chain. I can use GraphQL Mesh? Yes, so here comes the, so let me maybe share the screen. It's a great question. So first of all, this is cool what you've done and the code you've done, what we're using here in GraphQL Mesh, sorry for the noise, by the way. There's crazy storms here and it's really not regular. I hope you can still hear me well. Anyway, so what do you see here? Wait, let me. Yeah. So we basically took these sources, like those ones and you generated some resolvers and functions from them. This is what's GraphQL Mesh and GraphQL Code Generator already are doing. So you could like look at our solution and maybe like reuse some code and things like that. Now, the question is, do we still need this, the custom schema created here? Now this is the question that it depends on many things. It depends on what's, like, is the schema that those two services are exposing. Is it good enough? Because sometimes in many companies, the schemas that these APIs are exposing is not so good. Like even if you convert them directly into GraphQL, it's not exactly what the client would ask for. So in this case, you would have a custom schema here, but like we did in the middle step, like in the middle step here, you would still have a server and a graph, you'll still have, let me just check this out, like you will still have type definitions, right? Like you still have the type defs here because those type defs will be different. The client would want here different type defs than the generated type defs that Mesh is building, but maybe the type steps that are generated are exactly what the client needs and then you don't need it at all. In any case, Mesh is helping you because, and maybe it's just parts of it, right? Like maybe some services are exactly like you want and some services are not, maybe some services gives you like huge enums of 200 values and you don't want to create them yourself. So you just want to auto-generate them and then add to that custom schemas. All of that is possible, but at least here you could look at all your different sources and use all the information that you have on them. So it's a good question, like the answer is it mostly depends on your use case and that's why you would build GraphQL Mesh to be very flexible. So in all those different cases, it could help you. In my case, it will work great because that's small REST APIs created just for the project so I can do one-on-one and only the middle one. Okay, great. You could generate this GraphQL, show it to the client, then the client will give feedback, the client could say, oh, I want this field, I want it to be renamed or something or I don't know what. Then you could actually go and change these and regenerate and you get a new GraphQL API. Exactly, so that's really, really cool. By the way, in that context, why are they originally a REST API in general? They are REST APIs because they have a huge backend, Java backend, so it's kind of the, everything comes from that. In Zillow, they have millions of inventories and stuff. So we cannot access directly with GraphQL. It's just where taking that portion, those services and then using them, yeah. Okay, so yeah, so that sounds like a perfect use case for GraphQL Mesh, you know? Like also I wrote my details. Like later you can even show schemas and you can ask me what I think about it. But really this is why we created GraphQL Mesh. Exactly these types of reasons. Okay, so again, maybe here, you know, so theoretically this could just turn into a GraphQL Mesh gateway. By the way, this is, we deliver GraphQL Mesh as a Docker image, so you could just provide, you basically take a Docker image, if you're using it in this context, you can just take a Docker image, send the Docker image, the GraphQL Mesh config, and that's it, you get a server. Let me, someone from the community did it, but then we started publishing ourselves. But I'll just, I think the guy that's created it did like a cool illustration. Yeah, this thing. Right, so you basically just, you get the Docker with the GraphQL Meshes DK, and now you have an automatic GraphQL gateway for all your different sources with no code, basically. So it's just, again, it could be with code and it could be customized, so this is just one example of how you could do this. Okay, so that's GraphQL Mesh Gateway. Now let's go back to, let's say we have Apollo server here and let's say we use GraphQL Mesh as an SDK, right? So we have like this. This is GraphQL Mesh SDK that's calls our different sources like yeah, this is our Meshes SDK and this is great. Now the next topic I want to talk about is Envelope. So let me see, I don't know if I'll go through all the slides, it's not really necessary, but I'll go through some of the things that we can do. So what do we want from a GraphQL server? Let's say now again, our data sources, we have an Apollo server. What do we want from Apollo server actually, or just a general server? Because a GraphQL JS is the one that does all the execution and all these things. So what do we want from a server? So in my opinion, what we want from a server is a schema creation. It could be with GraphQL tools, it could be with the code first, whatever we want. We want it to handle communication for us, right? Like maybe it's HTTP, maybe if we're using real time, like it's like web sockets, SSP, things like that. And maybe we actually want to deploy it on edge, like serverless environments like Azure functions, AWS Lambda, and maybe even on edge, like CloudFlare workers, which is something that people forget that it's really, really cool, actually, to deploy your GraphQL servers there. And of course we want caching performance, monitoring tracing, logging security and often error handling, all things that we want from our servers to do. And we want a whole ecosystem of these things, right? We want all the, because everyone has their own different solutions. Now this is a very opinionated slide. Yeah, this is my opinion. But in my opinion, the current frameworks, including Apollo Server are very opinionated and they're not super well-maintained. What does that mean? It means that they took choices for us and they wrapped a lot of dependencies for us.

But the thing is those choices, first of all when you go and get into more complex setups, those choices are limiting. And the second thing is not only that they're limiting, if they're not up to date, keeping everything up to date, then we are stuck with up-to-date dependencies and we can't update it ourselves. They're also wrapping usually, the current frameworks are wrapping all the request pipelines. So that means it makes it much harder, we need different, like all kinds of patches and all kinds of different npm packages if we want to deploy on different environments that are not regular node. If we want to use Festify, we need something else. If we want to use Core, we want something else. If we need to deploy AWS Lambda, we need some kind of another thing. If we want to deploy on Cloudflare workers, I'm not sure if it's possible. And it makes it very hard, some people mentioned it. And it's very hard to customize. And other thing by the way, it's all in my opinion, not so it's not just, I don't know. I mean, I think it's not by mistake. I mean, at the end of the day, these frameworks they have a goal for you to use the company's products. So that means that flexibility is not in their interest.

So what we've done, so and we hit this a lot because in the guild we gradually, we build solutions for our clients' needs and we gradually build more and more solutions which didn't start from building the whole ecosystem. We started from very simple things, but more and more things were lacking. And a bit over a year ago we get to the point where the current framework, server frameworks just weren't enough for us. And we try to contribute these ideas to by the way, Apollo server and others, and they just, they weren't there, they weren't flexible enough and they didn't merge the PRs. So what we've done is we went to the board and said, maybe let's look at what core GraphQLJS is giving us, it's given us basically a couple of functions, parse, validate, execute and subscribe. Those are the core functions of GraphQLJS. What if we could hook, build hoops before and after each of these phase? So you could completely customize it with plugins, but we still would expose the same API outside. So everything was still work, and you can still do everything that you've done as before, but now you have a very powerful plugin system that could change anything. Things that until today weren't possible, even in GraphQLJS it wouldn't work possible. And you can use any schema, you can use GraphQL tools, you can use geographical and anything else. And the most important thing is that, the whole request pipeline is completely outside of this thing. Remember the first slides that I showed you, what GraphQLJS actually does, it's just a function. That function doesn't care where you run it, and it doesn't care what kind of communication protocol you have. So why do you need everything convoluted into one thing? Handle the HTTP with the frameworks that are actually best in handling HTTP, like Festify, Koa and Express. Then maybe, you know, if you're going on service environments, use whatever tools they recommended works for them, and then execute GraphQL. Why do you need all of these things merged together? So that's Envelope. Envelope is the plugin system for GraphQL. And it's really cool, because what you can see here is that with four lines of code as a user, I just created a very extremely powerful server. Use schema is just, I'm bringing in the schema. But then the parsing, the parsing of queries, I added a parser cache. I hooked into the parsing of, this plugin is sophisticated inside, but you didn't need to write it. This plugin hooks into the parsing phase of GraphQL.js and then caches it for each query. Same it does for the validation, you know, I validated a query once, why do I need to validate it again and again and again? And it uses a GraphQL JIT. If you don't know what GraphQL JIT is, it's more performant way of executing and GraphQL, I'll just show you the library. It's created by Zelando. They have benchmarks there that shows how faster this thing is from GraphQL.js. Yeah, so this is GraphQL.js, like I said, starting in prospection, let's see a few resolvers, many resolvers. Yeah, you see like this GraphQL.js, did 16,000 operations per second, GraphQLjit, 178, okay? So, with Envelope, you don't need to know all these tricks and stuff, you just need to install the plugin and that's it. And with those four plugins, you get a full, a crazy performant GraphQL server, just like that. And, but the ones, when you do want to recreate a plugin, you get a very powerful API to do whatever you want. And we created a plugin hub, where you can like, just explore plugins for everything you need. Like, you know, let's go to the Envelope. If you go to the Guild's website, I'll put it in the chat also, I don't know, maybe I put it already. So, I go into the Guild website, I look here at all the different tools, and let's click on Envelope. So that's the Envelope website. I'll go through that in a second. It explains everything I just said. But there's the Plugin Hub. And here, you know, what you can see here, you can see plugins for tracing, right? So, if you use Sentry, or Opent Elementary, or, you know, New Relic, whatever you want, you can just hook, because we are hooking into, it's one line of code, because we are, and of course, the configuration, but, like, we are hooking into the actual GraphQL execution phase. So the tracing that you get here are extremely powerful. You know, even Datadog, and Apollo tracing as well. Like, part of the things we're playing nice in Prometheus, we play nice with everything. So, you could use Apollo Server, even, and use this thing. I think I should just use Envelope, but like, you could use Apollo Studio, for example, and we still will work with it. By the way, Envelope can also be the gateway for Apollo Federation, because with the use schema thing, let me show you here, let's do Federation. You see, you can use Apollo Federation, so you can get, Apollo, usually when people are using Apollo Federation, they use Apollo Gateway. But, with Envelope, we could actually use that, and run that instead. We not only use Apollo Federation, but we also could use all the different plugins of the whole ecosystem. It's a better way, actually, in my opinion, to use Apollo Federation, if you're using it. There's more things, of course, here, like security stuff that we'll talk soon about, authentication, authorization, all kinds of things like that. Yeah, and of course, caching, which is, is anyone here heard about Graph CDN? Yeah, I can't see what people are saying. Yeah, I heard by Max Toiber. Yeah. So it's really cool, right? Like he says like, oh, you can cache on everything and everything like that. I don't want to ruin the party, but if you just read this article, you get everything that Graph CDN is giving you, but open-source entry, just so you know. Like everything.

And it's because people are just not aware of it because it's pretty new, but you get all the flexibility and all the power and you can deploy this on edge. So basically all the fancy stuff that they're doing, you can use with just like a couple of plugins, response cache, and all the configurations that you have in their UI, you can put here and it's done. And you could deploy the cache anywhere you want and control it and, yeah, just so you know. So this is how powerful you get when you hook into the system.

Couple more things that are interesting, interested in that. So yeah, there's a whole ecosystem of plugins, and the cool thing is that you could use all these plugins no matter where you deploy. It's not like you need a different library or you need a different code if you want to now deploy to AWS Lambda or to Cloudflare workers. It's the same. It's based, by the way, not only on Envelope but on GraphQL Helix. It's another important piece of the code here on GraphQL Helix, which is, GraphQL Helix is basically a server that I'll show you an example called, let's see, we have 20 minutes. Let's see how much I can make in 20 minutes, just a second. I'll just finish the slides really quickly and I hope to get into code. So, Envelope also is a framework of frameworks, right? So, it's, the idea is not only that you could use it yourself, but there's also other frameworks that are actually using it. Like, I don't know if you heard about redwoodjs, but redwoodjs is basically like, it's a framework that's been built, that was built by one of the founders of GitHub. It's really cool, you should check it out. It's like high level frameworks. So it does like, you know, the front end and the back end and handles a lot of things for you. So, the cool things there is that they used to wrap Apollo server and Apollo client. And then when they started working with us, and they basically gave the users for a while an option to use Apollo server under the hood or envelope under the hood. Basically a month and a half after they gave that option, everyone just switched to envelope, so then redwoodjs removed Apollo server completely and since a couple of months ago, and by the way, the talk from their guy who started GitHub is gonna be also in GraphQL Galaxy. Now redwood1 is using just envelope, they completely removed Apollo server. And they wrote a blog post about it, so I think you should also read why they did it. So that's why I'm saying framework of frameworks. And we also created PRs for loopback for NIST-JS for parse for all kinds of other frameworks that's wrapped in GraphQL. So that's part of it. Another thing we've done because we work with a lot of different companies is that some companies, they have like many different GraphQL servers but they want them to share the same configurations like the same logging, the same tracing, the same security configurations. So we created like an envelope of envelopes, you can create like a preset of envelope and then a server can just import that and then customize their own thing. So you have like one set of how you build a GraphQL server inside your company and then each team can customize. One example is Klarna, Klarna is a client of ours and they basically switched to envelope from Apollo and now all their servers have like one preset of how they do things. And they have many, many different teams who builds many, many different GraphQL servers. Last thing that is really cool that I would just want to discuss and I have also prepared, like called examples for that but let's see how much I can make is it's actually like a Babel for GraphQL. So if you would remember Babel from the JavaScript ecosystem, there's all kinds of features that the browser weren't ready to execute, like all kinds of new features in JavaScript. So then Babel basically gave you the options to use these features even though the browsers are not supporting it. With Envelope because we're plugging into the system, we can actually do the same. So, with Envelope, you can use defer and stream, you can use live queries, you can use one-off, which is a really cool. I don't know if you heard about one-off. One-off is basically, it's something that actually comes from JSON schema. You can, let's say if it's an input field, you can say, it could be one of these options. And this is something that does, it's very convenient to declare a schema like that, and it does very good validations. But GraphQL still is in the process of actually adding it to the spec. It's gonna take a long while. With Envelope, you could use it today. So, that's really cool. So let me just like, I don't have a lot of more time. So, I'll just go quickly through the website but I think it's important. So here there's like introductions on how to do it and how to work with it, sharing Envelopes what I said. These are all cool, but the guides here are the important part. First of all, we handed a guide here of everything you wanted to talk about like around authentication and authorization, not leaking sensitive information in production and protecting malicious queries. We persist the queries, depth limiting and rate limiting. Those are all things that until today you had to go to workshops and there were many cool talks warning you that GraphQL is dangerous and you need to use our special solution for this or that. Now, it's all very simple. There's one article here that explains all of that. I also created code examples, but you can go through that later. And you can actually... You see it's just a matter of setting some plugins to make your server secure, like the error masking plugins. So automatically it will mask all the errors from your server that you will not leaking information or they disabling perspection plugin. All these things are just as easy as that. And then you want to protect from malicious GraphQL queries. Like you can do all these things. So you could actually use persistent operations and we have a plugin for that. And you can choose whatever store you want to do that. And you could query that limiting. It's just a plugin. Rate limiting. It's just a plug-in. So all of these things used to be very hard and there's so many articles on the web trying to warn you from running GraphQl in production. And the reason they wrote these articles and they didn't give you like the best solutions because usually they want you to use some solution that they want to sell you or something like that. Unfortunately, most of the content online is being written by people that you can call developer advocates. And developer advocates, they're very nice people but I was one. I used to be one.

But what you forget is that they're working for a company, they're advocating for a specific solution that you would buy. So giving the simplest solution is not necessarily to their own benefit sometimes. So that's one guide that we have here.

Another thing is like authentication we owe zero and how easy it is to use it in this constellation. Monitoring and tracing, which is something when you go into a production is extremely important. So again, here, you can see how easy it is to basically hook into Sentry. And the same goes for just one line of code. And then, of course, you can customize the configurations and everything, but you can see you have here basically whatever you use for telemetry, whatever protocol, whatever thing, it just works.

This is the one about like features from the future, right? Like, I mentioned all kinds of things. You can see here the RFCs, like the open RFCs for each one of those. And it's gonna take a while. Yeah, like you have here and here and here are all kinds of RFCs. You could already use this with Envelope. So that's really cool. And yeah, you can see here the one-off example. Fragment arguments is something really cool that comes for Facebook is using it for a while, but it's still in the spec process. So if you want to use it outside of Facebook, you can use Envelope. Some people mentioned like data loader, caching issues and subscriptions. So we wrote a bit about that here. We can actually use this with Envelope, but the most important one thing here is that, this is basically graphs in the end in an article. So I would highly recommend you to read that because you don't need a service in order to build very powerful caching mechanisms for GraphQL. This is actually a long article because we wanted to give a lot of context and we wanted people to really understand what's going on underneath the hood, but then at the end, the solution is actually pretty simple. Yeah.

In terms of code, there's a bunch of stuff I wanted to show you. And again, there's much more. So if you go to our websites and go through all this, there's reasons why we created each one of these libraries. So you should go through that. So let's do this. I demonstrated. Another thing, we recently edited a tutorial here, a basic tutorial, because we thought the basics tutorials are really bad. So we created here a new one called no Typescript Helix. This is a tutorial according to how we see the things and how everything should be separated. So if you want to actually start from GraphQL, but in a good manner in my opinion, in our opinion, you should check out this tutorial. And this is actually new and we're gonna improve it. So if you have questions around it and everything, let us know. And we're now in the process of building an advanced one. Let me actually get the link of the advanced one. So you can already use that to include all the things that I wanted to show you today. Actually what I wanted to show you today was, code examples of everything here. So you can also read it here. Everything we want to talk about, but yeah, explore that repo. This is a more advanced tutorial. And hopefully this will also get into how to GraphQL soon. What did I want to say? Yeah. GraphQL Mesh. I showed you a bit of things, but you can see here, there's many different examples of how invent the live examples. Like you can actually play with it. Like, oh, if you have open API, you can even run it on Next.js on the client. Like there's all kinds of examples here. So even in Next.js, you can see the users, there's also examples here, all data slope, and even a part of federation. And all of those things, all these examples also exists basically here on the examples, folders and many more. So you can check all kinds of examples here, but I wanted to show you more things actually. Okay. Wait, a second. Can I stop this example? And let me just... I'll finish with the last example, even though I have many. Let's see. Ah, okay. So here I wrote, there's like basically I wanted to show you a demo of Envelop with all kinds of things, but we won't make it. So I'll just, I put the link here. I gave a talk about it where I actually do, I'm actually going through the code. I'm actually building the server from scratch. Let me link this to you. So you can see here, I'm giving like a background, kind of like a bit of what I shared before. But from basically here, I'm starting from scratch. I have nothing here, like just an empty server. Wait. I have an empty server and I just build the whole server from scratch, including like, like tracing with like Sentry in that case. And I'm demonstrating like auth zero, like auth zero and I'm also demonstrating like live queries and all kinds of really cool stuff. So all of this, I'll just share it with you here.

So you can also go through and again, copy that. Let me know if you can copy that all of this from the chat because I don't want it to get lost, so save it. So that's another demo I wanted to show you here.

I think the code here lives in, let me see, so you can play with the code, here, yeah. This is the PR for, here you can find like, oh no, this is not actually this one, sorry. I should, wait, I think it's just a second. I think that the code actually should be, I will correct myself. Here, this one. Okay, so I'll share it with you as well. This is that code. Again, I wanted to walk you through here, but again, you can go to the video. I'll also share here this thing, which is the last thing I wanted to show you.

The graph revealed bleeding edge. Let me go. Let's go forward. Okay, so this is the bleeding edge is basically an example of all the cool new features that you can do with graph guild that other people are not talking with you about it because their frameworks are not supporting it, but here everything is supported. So this is like, I'll go through it really quickly. So this is just a regular query. I get a thing, I get a form, I get a ping back, that's cool. Here is a mutation, here is a subscription. So I can subscribe count, test subscription, right? So every time something happens I get some subscribing to count, this is cool. But there's stuff here that your regular and also subscriptions suddenly became very hard with a Apollo server. They dropped support for it for some reason, here you could use it, And not only that you could use it, you could use it with like over web sockets or also over HTTP with SSE. This is sometimes better if like some of your clients are working in environments that they don't have web socket support, but you still need real-time communication and through socket IO. Everything is like demonstrated here. But this is the cool thing. Look at what's happening here. We're sending a query with name and deferred field. Name is really fast. I get name really fast, but this field takes long time. If you would send it as a regular query, let me remove this. Let's see what happens. I'm waiting a lot of time. And then when the last field is ready, I'm gonna get everything. But I know this field on the UI, it's fine that I'll get it later. And I actually want this to render quickly. So what I can do, I can add the defer annotations on this. And then when I'm sending this, immediately I get the name back. And then later on, I get, when it's ready, I get this. This is extremely powerful for your GraphQL servers, this ability. So that's one feature. I'm sorry that I'm going super quickly, but and then there's also Live Queries. Like their subscriptions is one thing. But Live Queries is actually, it's, if you don't care why data is being updated, but you just want to constantly show the most up to date data, you can use Live Queries. So yeah, I can just put Live Query on the greetings and it's constantly updated with the latest information. So if you're putting, I don't know, a price of something that is constantly changing or I don't know. There's many use cases for it.