From a fully featured Apollo Server into no-code GraphQL Mesh with the same functionality

Thanks to our sponsor, ReactJS. Thanks to our partners, React, and Accelerator. Thanks to our sponsors, React, and Accelerator. Thanks to our sponsors, React, and Accelerator. Thanks to our sponsors, React, and Accelerator. Thanks, everyone, for coming. This workshop is about GraphQL Mesh. I don't remember even the title, but I guess something about GraphQL Mesh. Oh, probably the Discord channel is saying that, yeah. And, yeah. GraphQL Mesh is like something that we created... I mean, we created it about a year-and-a-half ago, and then, after using it in production for a while, we decided to open source it. And the interesting thing about the library is that it brings... It came from all kinds of different things that were helpful for us in all kinds of different scenarios. So people always look at GraphQL Mesh as one thing, but then it's another five other things that people don't think about. So I hope today to kind of like give you an overview of the whole thing. And the workshop that both me and Arda from the Guild prepared is kind of like walks you through and like different ways that you could use GraphQL Mesh, like starting for something very simple and growing into something like a full gateway.

Now, it's like three hour workshops. So there's a, we have a lot of time and the thing is, I give a lot of lectures but I always prefer to just talk to people and get a lot of questions and have conversations than just telling you this is how you should do it. And I think this is also something like that is different from, that's also maybe better for you because you can ask me questions which you can't do if you just watch a YouTube video of me talking or something like that. So I prefer that you would like interrupt me as much as possible and ask questions as much as possible. And I hope this thing would be more than like just you can do this or you can do that because, because I also, wait, let me, like I shared in the, if you look at the, if you look at the Discord channel, then I shared like the basically the GitHub of the workshop. And it's open source, you know? So you don't, you can just like do it now. You can do it later and we'll do it together. Don't worry, we'll do it today. But there's less stress of like, you know, we have to finish everything and we have to make sure that everything will be perfect and stuff like that. You can just do it at your own free time. And so what I think I'll do now is just, maybe I'll give a short introduction on GraphQL Mesh and then I'll maybe give like, do like a quick overview of the workshop. Like you can already by the way, look at it. Like if you look at the link that I send in Discord, there's basically a list of commits. So what we're gonna do is basically each step of the workshop would just be a commit. So you can just see the dif, the changes between commit and commit starting from the first commit and then going all the way. And that's basically the workshop. So I'll go through that and then we'll just start doing it together. Now, but again, what I hope is that, I don't know, it's also for me, like I've been in a house for too long because of the situation and COVID and stuff. So actually giving the opportunity to talk and make it more of a conversation than just like me showing you stuff is even better for me and more interesting for me. So really like I want you to ask questions and bring up your use case and talk in general about GraphQL or anything that you want to talk about. So give maybe, I'll try to make the introduction short because you can watch my talks online all the times or there's no real point for you to look at, you know, to just see another talk from me. So I'll just go through it really, really quickly and then we'll get to the actual stuff. So yeah, if you still don't know who I am or who the Guild is, we're the largest open-source group in GraphQL today. We build a bunch of tools that you've probably heard of like the graphical code generator that I mentioned that basically takes your schemas and your queries and you can generate any code that you want. There's tons of plugins, but there's also a lot of people create their own plugins for their own specific use cases. GraphQL inspector like the, you know, basically checks the differences between different versions of your schema and make sure you're not breaking any breaking changes. GraphQL CLI, GraphQL modules, GraphQL tools that I'll talk a bit about. I dunno if it's probably one of the most popular libraries in the GraphQL world. And it was unmaintained for two years. And then we took over this library, completely rebuild it, and basically also brought back schema stitching. But if you thought that schema stitching was deprecated then it's not. There's the old version of schema stitching that Apollo just decided to desert and go for all of Federation. We rebuild schema stitching because we had a lot of clients that were still using schema stitching and Apollo Federation didn't really replace schema stitching completely. So we took over it, we rebuilt it. And today we actually think that it's better in many ways it's better than Apollo Federation. So if you have questions about that, like about the Apollo Federation, schema stitching and all those things, please ask. Like I'm talking a bit also about it on my main talk in the conference, but I would love for you to ask questions about that because there's a lot of misconceptions there. And yeah, we build a bunch of, a lot of tools. And the idea is that, we build a lot of small tools that are maintained for the long-term. We think that, you know, the GraphQL community was suffering a bit for a couple of years because a lot of companies created open source and then stopped maintaining it. So we're kind of like, came into the picture to basically keep those libraries maintained for the longterm and for years. And you can use all those libraries together. By the way, it's like one big platform, but you don't need to. Like you can just take one or two pieces and just slowly, gradually, you know, use GraphQL. So today I'm gonna, okay. So let's start. So how should I, so first of all, maybe I'll ask a question, like, and some of you can share, maybe I'm gonna stop screen sharing for a second. Does everyone here know GraphQL? I don't know how we can do this. Like, how can I ask questions? Like, I don't know how it works here, but yeah, I guess we can just write in the chat. Is there... How many people of you... Okay, it will be hard to do these questions like that. So I'll just continue and then we'll go back into like a whole conversation. I'll just finish the presentation really quick. I'll share my screen again.

Okay. So, GraphQL Mesh, the idea of GraphQL Mesh basically came to us or to me when I kind of like wanted to think again about the basics of GraphQL and maybe come up with different use cases that GraphQL could help us like. And what is the basics of GraphQL? It's basically like we can describe any data as a schema and any database that can be API, calls. It can be a file system in memory, whatever, we just can create this, you know, a schema that describe the data and then we can query it how it is.

Like let's look a bit about like how we know it works though by describing a schema, we creating resolvers, which I talked a bit about, we basically get this like GraphQL engine in between the client and the server. And then the client, you know, can start asking for queries. Like I want the user ID and I want just the user's name. So, you know, it will send one request and you will get back the user object and then we'll extract just the name from it. And then the client will get back, you know, one response with like exactly what we expected it to be. But then, you know, if we want the users name and messages, then again, the client will send one single request and the GraphQL engine will go fetch the user. Then in parallel, we'll get the name and the messages. And then for each message, it will go and fetch the content. And maybe the content actually comes from like a third party API or CMS or something like that. The client doesn't know, it doesn't care, the client just get, you know, back one single response with exactly what it's expected to be. And, you know, you already know all those things, like you get back, you know, that means that we send less data over the network and less requests over the network compared to REST. So everyone is talking about the performance benefits of GraphQL and that's fine. But I think that there's better, there's more to GraphQL than that.

Basically, you know, if we look at the resolvers, like they just, it's basically like small functions that get a parent object. They do some work, any work we want and they need to get, bring back like one results. And, you know, if we build those resolvers and we order all these things, then the GraphQL function, what you're gonna see now in this slide is basically the internals of the GraphQL function. Like, it's kind of like a weird pseudo code of what GraphQL does inside. So now that I'm running through the slide, I want you to think, where do you write that code today? How do you do that code today? So basically we tell GraphQL, hey, here is the reservoirs and the schema and here's the query that I want. So then what GraphQL will do, it will go and take the ID, number two will run the first function and will give us back the user object. Then it will go and fetch the functions that we already created and run them in parallel, send the user object to both of them in parallel, get in the first one will get just like a string result, we'll put it in the right place. But from the other function or resolver, it will get like three message objects. So from those objects, now it will go and run all of those in parallel, get the right boxes, like the date and the type and put all the results in the right place. All this work, but that basically understanding what you want and going and doing that work, basically orchestrating all this work and gratering all the results and trying to do that in the most efficient way. All this work is automatically being done for you, but by GraphQL that in my opinion is the core of what GraphQL is. Looking at the study query and doing that work automatically instead of code. Why, I don't know why this slide is here just a second. Oh yeah, okay. So basically that's one part of GraphQL, but like I mentioned before the beginning of the talk, those resolvers can be, those resolvers could actually be typed as well.

I hope that most of you heard about GraphQL code generators so when you write your resolvers as well, because we have the schema, we can generate the inputs and the outputs. And that's cool, but the thing is, and now we have a fully typed system, right? It's not only the GraphQL automates a lot of those that work for us, it also brings us types. All the, like the resolvers are types, we know the types of the query that we're gonna get. It's very powerful. But the thing is, usually we put GraphQL on top of existing systems. Like just like the guy who I mentioned before. Usually we put it on top of an existing system on a REST API or something like that. And the thing is, when we call that existing system, like all those different backends, basically this is still the same old code that we did before. We don't have types for that. So it's a shame. So the first reason when we thought about how to use GraphQL mesh was basically, could we use all kinds of information here and type those calls? Like, nothing changed in the way that we call the old APIs. Could we take some of the benefits of GraphQL and use it also there? And some people have ways of doing it. For example, some people maybe are saying, okay, let's go and convert all the old APIs to GraphQL. Which is possible, or maybe let's build like small gateways in front of all those old APIs, and that's also possible. The thing is, if you're an existing company, that takes a lot of work. And those things have enough things to do by themselves.

So what we thought is like, could we leverage somehow GraphQL? What we want from GraphQL, it's kind of like a static schema and a query language automates all the things that I just showed you, but on top of the existing APIs that you have today, because the things you have today, they're probably, they're existing. It's not like there's nothing there. There's maybe that use a rest with a swagger or open API, which is still a schema and you still can understand the types from it, or maybe use gRPC or SOAP, which even is more fully typed. But even if you don't have a schema, it's just like an old rest endpoint. You can just look at the, let's say the logging system or the live data that our example data that goes from that, and then you can generate from it JSON schema. So you have some information. So what we thought was like, could we maybe like take this information and convert it into GraphQL? And in test, we did something similar. I don't know if you heard about SOFA, but SOFA does the other way around. It takes a GraphQL schema, a GraphQL API and generates rest out of it. You know, sounds weird, but you know, there's many reasons to do it. I want to dip into that, you can ask me about that later.

So what we want here is to do the other way around. We want to think of the existing old schemas and we want to generate GraphQL out of them. And later on, we can even take all those GraphQL sources and merge them into one breadth into one thing, which there we use like schema stitching in the Apollo federation. There's a lot to talk about that as well. So that's GraphQL mesh. GraphQL mesh is basically a library that takes all those different sources that you see, any source almost and converts it to GraphQL. And then can also merge those different sorts together using tools like schema stitching and using an Apollo federation. So the aim is to think the best sort of GraphQL but using your existing services, like you don't need to just build manually all that work. And GraphQL mesh is... We have handlers for many, many technologies like I'll skip that part with the demo because we're actually gonna see it now. But we have handlers for OpenAPI and Swagger, GRPC. So we can take into the mesh, we can also take of course, GraphQL and GraphQL federated services. We can even feed like SQL databases like PostgreSQL, MySQL and SQLite. If you want to use SQL server, tell us because we want some use cases and people to help us do that. So we want to do that. And also OData. By the way OData, we work with Microsoft on it. Microsoft has this thing called the Microsoft Graph is basically an API for all the different services in Microsoft, but it's written in OData. So we work with them actually to convert it using GraphQL Mesh to GraphQL so people could just query GraphQL from the Microsoft Graph. So again, the idea was to just... We just wanted to type, get an SDK, like if you're using Apollo data sources, for example, the idea was just to get the better Apollo data source. Like that you can actually get the fully typed, get all the types. But what we got was something more powerful. It's an SDK that you can actually send queries to, and it can even like call different sources. So you get the types, but you get the whole GraphQL experience from it. And I mentioned a bit in the talk, also like it's completely pluggable. Like, of course, a lot of automated automation stuff that are happening.

It's an SDK that you can actually send queries to, and it can even like call different sources. So you get the types, but you get the whole GraphQL experience from it. And I mentioned a bit in the talk, also like it's completely pluggable. Like, of course, a lot of automated automation stuff that are happening. It's everything can be customizable. Like, because, you know, you can do a cool demo, but then when you go and like do it in production, there's a lot of, you know, stuff that you want to customize and change. So everything is pluggable and open-source of course.

And the most important thing about that, I think, and that's what I want to demonstrate today is that you know, GraphQL Mesh can take all those different sources, merge them together. And we can have like a, you know, a very powerful gateway, like one source that everyone can query this thing and then get the experience of GraphQL and the one graph and all those things. But the thing is, that's not necessarily what you always want. What we can do with GraphQL Mesh compared to other, you know, gateway solutions and GraphQL is that we can also take all those different sources, older schemas, convert them into GraphQL, merge them into one schema, but then generate from that schema and SDK. So that SDK can run as an Apollo data source in your resolver, it can run as an SDK on your client app. So you can basically get like a SDK. So you could query GraphQL on your client app, but from your client to all your existing services, you could just use the same rest APIs. And all you can even like run it what we see a lot is people running it on like their other services, like service to service communication. Like if you have a data service or like a machine learning service, now that service can call many different APIs, like it's one graph, but it's that's what's why we call it the GraphQL mesh. It's a service mesh, basically it feels like the developer's experience, like it feels like all the data is just there in one graph, but in production, it's actually like complete mesh. It calls directly to all those different sources and then automatically merges this data for you.

It calls directly to all those different sources and then automatically merges this data for you. There's many, many, I'm going to skip this part because it's not that interesting and there's many other things to talk about. And I'm also not gonna like you should watch my keynote tomorrow in the main conference because it's more, there's much more to talk about, but what I want to do today, so first of all, I want to show you how to do it. Like the, you know, let me go very quickly to go through the workshop, like the workshop structure.

And then I want to stop and ask you some questions. So that's the workshop what you see here. I'm gonna run it locally, but the idea is that we have here basically a server. I'm gonna show you the code for a second. Yes, so I have here like Apollo server, and by the way, before I'll start, I'm gonna ask you some questions. I mean, if you don't know what Apollo server is or stuff like that, don't worry. But basically what we're gonna start from is a basic Apollo server. It's a basic Apollo server that calls to Rest sources. That's the classical way of, now if you go to the Apollo website and you're wanting to create your own server or something, that's probably how the tutorial would tell you to do that. So you're basically, you have a server, you can use Apollo server, I'm sorry, my computer is slow because sharing the screen and all this is like killing it a bit, but we have an Apollo server, we have a couple of data sources of Apollo server. One is like we're occurring, we're basically querying a rest API that gives us all the breweries, like all the pubs and breweries and stuff like that around the world. And the other way, and the other API is basically a Geo API. It gives us all kinds of information about cities and stuff.

And what we actually want, let me try to run it. What we actually want is we want to actually query let's say to query for a city and then get all the bars or the breweries in a specific city. Let me show you that just for a second just so we know what is our goal, yeah. So I'll give it a second. Again, my computer is heating up, I'll close this slide. So I have an API, you know, that gives us cities and I build a schema for it and I have an API for breweries. I can, you know, find breweries in a specific city in GraphQL. Yeah, it takes a while because my computer's heating up, yeah. And just I'll go very quickly through the code. So what's happening here is like this is the classical way of doing it in GraphQL. I'll go through it in a second, don't worry. We have three hours, we have all the time in the world. But usually what you do is that you build a schema. So here is a schema that describe basically like, you know, what we want to, the schema that we want to expose to the user, like, let's find the queries by city and that will return us an array of breweries. And then here is all the information that we can get about a brewery. And GraphQL, you know, and then in the resolvers, what we do is we're gonna call a data source or just a REST API. And that REST API is just, you know, it's a simple REST, like we're going to do get breweries from this public API that I have no control of. And something very similar is happening here in the GeoDB. So, that's nice. Like, that's already, it means that we can do, you know, get all the GraphQL experience, right? I can go here and I can, you know, I can get auto-complete and I can, you know, query for another thing, you know, like the phone or whatever. And I will get back just what I want and you know, all kinds of other things. I don't know what we want, like a latitude or something or the country. So, and I get the documentation as well, you know, and all the cool stuff, but so that, you know, I get the GraphQL experience, but I needed to write all of this manually, right? I needed to go and do the GET and then go and write the resolvers manually and go write the schema manually. And also what's more interesting is here, you know, I'm using TypeScript here, but this is not typed. Like I have no idea what are the types that I'm gonna get here. So, this is basically like any and I think we could do better. So, let me stop this for a second. Let me also close Keynote. Quick question. And let me... Yes. We're currently working on Node.js and working on the backend part of GraphQL, correct? Yes. So, currently we're working on Node.js and the backend part. But the interesting thing is that everything I'm showing here, you could actually do on the client. That's the point. So, all the work that I'm showing you here, which is... By the way, everything I showed you here is still manual. And I'm going to show you basically how... Many more and more automation and generate the types and generate the case and stuff like that. Right now, I'm talking about the server or basically the middleware between the client and the server, which is the most popular use case. But as I talked before in the slides, you could basically do the same everywhere. Like, you can take all the things that I'm showing you here and just run it on the client, which we see... This is a very, very popular use case in general. Like, I have a whole talk and a whole discussion about why so many people in the community are not actually using GraphQL on the backend. They just run the GraphQL engine, like GraphQL.js, on the client for easy integrations and stuff like that. So that's the plan for today. But before that, I wanted... Because we have a lot of time and there's so many hours, and also you can run the code yourself and do that now or later, I want to hear from you a bit. Like I hope you can now... All of you are opening the code. Maybe I'll also again, share the screen so we can have it in front of our eyes. And I want to hear a bit, like some questions. Like, first of all, this is the first step. Yeah, I just showed you how to basically do that. That's the beginning code. But then what I'm gonna show you is basically, first of all, how are we gonna link the two together? Basically, so I can query not, like I did before, like not just one query for fine prairies and one query for fine cities, but I can do both of them together. Like basically I want to get Chicago and I want to get the boroughs of Chicago. How would I do it manually in the regular GraphQL manner? But then the next step after that is I'm gonna actually use GraphQL Mesh. And I'm gonna use GraphQL Mesh to basically replace the data sources. Like that, I'm basically gonna call, instead of the data sources, I'm gonna call a generated SDK. But first of all, it will give me those functions with auto complete, like it's gonna be fully typed and it's gonna be completely generated, and it's gonna be generated from the schemas of the original services. So all I need to do, and don't worry, I'm just going like really quickly about what we're gonna do. I'm gonna put the source like the schema of the source, and then I'm gonna put the URL and that's it. And I'm gonna get all of these things out to generate it for me. And then I'm gonna basically slowly replace and more and more stuff from Apollo server to GraphQL Mesh. So not only using GraphQL Mesh instead of the data sources, but also using GraphQL Mesh basically as a server, like GraphQL Mesh connect to its own server to basically slowly replace GraphQL. I can just put the configurations here basically to replace all server run GraphQL Mesh as a server, but then I still have, at this stage, I still have like a bit of resolvers that I need to write and a bit of code that I need to write. The end in the end result of the workshop, if you wanna check out the master branch and just gonna get to the last commit, there's basically no code here. There's two files. We get the Mesh RC file, basically all the configurations in one file and the package JSON. That's it. And we have a full running server taking two sources that I have no control of and I could query everything I need. So that's the workshop.

Now, I want to hear from you a bit. Like I want to start a bit of discussion because I can go through that workshop step by step and we can take a whole two hours to do that. But I want to also hear a bit from you. Like, why is it interesting for you? What not, all the questions that already are popping into your head. So I want to give a couple of minutes for people to ask some questions or to raise ideas or ask if this is possible or this is not possible or why it's not interesting for you. Yeah. So go ahead.

Is it as performant as native GraphQL would have been or does it get a bit lagged up like REST is? Can we utilize the full power of GraphQL as it work? I hope I'm making myself clear. Can you repeat it but it's a bit slower and maybe closer to the microphone. You were sound a bit far away. Okay, okay. Let me just try it again. I guess it's better now? Yeah, better, better. Yeah, so my query was that, since we are just keeping a gateway in front of the actual thing, the actual service that we're trying to run. So does it give us the speed that GraphQL provides or does it have this inbuilt capability of that if it is REST, it's gonna be a little bit laggy as opposed to GraphQL. So how does that work out? Yeah, good question. So first of all, kind of like, so first of all, it depends where you run it, right? Because let me share the screen for a second. So first of all, what we have here right now is we have a Node Server that basically will get a query from the client. The query will run, let's say over the network. And then that means that we will send one request over the network from the client to the server, then the server will do some work, you know, like all the work that basically GraphQL does, like the same slide that I showed you about how GraphQL is working, like it's automating this query and it will run, it will call this function and will call also this function and it will wait automatically for those responses to come, then it will extract just the data that you need, will create the one response that you need and will send it over the network to the client. Now, in that case, you basically solved, if you care, you know, about let's say less requests over the network and making the request slower over the network and also if you care to make the client as thin as possible, meaning all this work that this GraphQL is doing for you, you want basically that the client will just get a ready, you know, the response as it wants to render and that means that you don't need a lot of code on the client, then yeah, you basically, you get better performance because now it's all trade offs, yeah? So it means that over the network, you know, it will be much faster. But it still means that now you have this gateway, this GraphQL gateway, no matter what technology is being used, it does some work, right? Even if the code is automatic, it still does some work. Now, again, you can take all that work, all that code that I'm showing you here and basically put that same code on the client. And what will happen then if you do that, over the network, you still get multiple requests and multiple response, right? Because the client will call directly those resources but it means that the code that waits for them to arrive and the code that extracts just the fields that you need and all of those things is automatic. You don't need to write that code. So that's already very powerful. Now, what we're gonna do here is that we're gonna slowly take that code, those resolvers and the data sources and everything and convert those into GraphQL Mesh, like to convert this into automatic code and that's not gonna change anything. In terms of like the efficiency is the same thing. We can even make it a bit more efficient but that's like a more advanced use case but basically it's the same. It's just, you don't need to write code. So the difference between performance, if that's your question, the difference between performance between this part and this part, there's no difference. Like here we don't write any code but is as efficient if not even more efficient than this part. So that's a very powerful thing. And by the way, the same for each step of the way here. So everything here is basically in terms of efficiency is the same but you just write less and less code. So if you look at the current state which we have a bunch of files and everything, and then you are going to end up with basically just a mesh RC file in a package, JSON. Yeah, it will work basically the same. The whole point of the workshop is that we're gonna have like a query here. This query, that queries the cities and the breweries and we're gonna use the same query. It will gonna work the same for all the different steps here. We're gonna basically delete more and more code and the query will keep working as it was before. So extremely powerful thing. I hope it answers your question. Is it answering your question? Cool. Cool, more questions.

Hi, thank you by the way very much. It's very interesting. I have actually two or three questions. So maybe I'll just ask them together. Hopefully it's not too much. Yeah, that's good. And I'll just tell all the rest. In the meantime, try to clone the repository and try to run the first step and then try to already start going through it. So maybe you already start asking those, like getting more and more questions while you go through it. But yeah, please continue. Perfect, thank you. Yeah, so the first one, can I also use GraphQL Mesh in order to query RESTful API like Airtable or Ghost? I don't know if you're familiar with that, but it sounds like that's the case. Yeah, so just to answer your question before you can continue to the next one. So yeah, the answer is, yeah, GraphQL Mesh can query any API. And I'll show you, one of the things I'm gonna show today, one of the sources that we are querying, I think it's the, let me just see for a second, just to make sure. One of the sources that we're querying today, let me find it. The Geo API has a Sweger schema. So it's very easy. We take the Sweger schema and we generate it. But the OpenBrewery API, the other API that we're querying, it doesn't have any schema. It just have a website that you can like, look at examples, maybe they're right, maybe they're not. So what we're doing there is basically, we take a couple of example, JSONs that we got from the, or from the example website, or we just send the code and so what we got, we feed that into GraphQL mesh, GraphQL mesh turns that into a JSON schema and turn the JSON schema into GraphQL. So that means basically that any API could be queried. We have, by the way, let me, you know what, I'll put also another, useful link while I'm talking, I'll put another useful link for a very cool blog post that basically shows you how you can take any GraphQL, any, sorry, any REST API and automatically convert it using this technique. Like basically the idea that you don't have any schema. So, you know, you don't know almost nothing about that REST API except the URL and you can migrate it to GraphQL. I'm putting it now on the, on the chat. So I hope that answered your question. On the GraphQL, I'll just mention a couple more things. Like on the GraphQL repo itself, I'll also add the link to it. There's many different examples. So there's the Stripe API, there's like, we just, people are slowly like contributing more and more APIs to mesh. So there's tons of APIs, but again, you can pick any API and just go about editing. I hope it answered your question. Yeah, definitely. Yeah, it is. Yeah. We are basically today actually doing it manually and therefore therefore, GraphQL mesh is very, very interesting, yeah. Yeah. So how do you do it when you, when you say you do it manually, you mean you query that API and then you write the schema manually, right? You can write the GraphQL schema manually. Correct. Right. Exactly. Yeah.

Yeah. It's probably the same way that you actually start demonstrating with the data sources. Exactly. Yeah. And then the second question, maybe also the third which is kind of related, I also wonder if it's possible to add any kind of middleware between the generated code and the resolver, like to just manipulating the data. And also the third which related, also it's kind of like what about also caching and where exactly that also getting into play?

That's a great question. So because the workshop is like short and we didn't demonstrate it, but I'm gonna already go and put like those parts of the documentation. So I mentioned it a bit in my very quick slides, but I'm gonna share first of all, this thing, I'm gonna put it again in the Discord channel, if someone doesn't know about the Discord channel or where it is, then let me know or someone else can post in the chat. But what I put here was basically, there's a list of many different transforms. So basically, you can control every part of that automated step. So, let's say you get some schema, you get some schema and then it's being generated, and let's say, maybe that schema is not correct, or maybe, you know, because we know the schemas, swagger schemas are always not updated, like in real life, or maybe it is updated, but you want the output to look different. So in the step of the transformation itself, it's completely pluggable and you can completely control everything. So what I list now is basically just an example transform that you can rename things. And if you go there you can see there's many others, there's graphics and all kinds of things like that. But also there's caching. So you can also like basically create like, a cache transform on each one of those generated things. So let me put that there as well. So basically GraphQL mesh in that case can act as a full fledged, as a full-fledged API gateway, right? And you have full control. You can also, what you will see in the later stages of the workshop here is that I'm adding additional resolvers. So I'm using the two sources, but then I'm adding more. I can add like custom resolvers and custom schemas into my gateway. Yeah, I hope it helps, it's answers your question. But if there's more keep them coming. Thank you so much.

Okay, cool. Okay, I saw someone wrote actually a message in text. I have a REST API that uses JWT for authentication and the token is sent with the request and limit what's returned to the user. What would I need to take and to change in order to include the API into my GraphQL Mesh?

I see. Yeah, good question. So you can, in the Mesh config, you can just configure headers as before. Like you still want to get the JWT token, you want to let's say, add it into the header or something and then send the request. So Mesh is completely configurable for that. Like you can add like even environment variables like the Mesh config is very, very flexible. So you can add headers and you can do whatever you want. So yeah, basically you're doing the same. You still like that Rest API will still get the same JWT token. No reason, no reason to change that. And by the way, that's also kind of like the best practice if you write GraphQL. A lot of people when they write GraphQL, they think oh maybe I should now move all the authorization parts inside GraphQL and I need to annotate my schema. I think that's not necessarily a good practice because you basically want your sources to control the authorization and you want to authenticate before. So anyway, if you look at the request coming in, you want to authenticate the request then pass it through GraphQL. GraphQL shouldn't care. Just go like take that header and just pass it through and then the authorization will happen in the sources themselves as they were before. So then let's say it enables another really cool thing in GraphQL, which let's say in one source, I have permission in one source I don't have permissions. You could get back partial results, unlike Crest, which will just fail the whole request. So that's in my opinion the best practice or some misconceptions that people have about authentication authorization in GraphQL. That's a very good question. Yeah, I think Aleksandra are you here? Oh yeah. Okay. Yeah. I saw that I edited everyone. Okay. More questions. Hello. Yeah. I have a quick question. Is that, is that, you know is it possible for the server to be aware of these auto-generated queries in order to use persisted queries on the server side?

That's a good question. So when you say auto-generated queries you mean like when you use the SDK? Yeah. That's a good question. So I think we don't have something that does it automatically today but it's pretty easy to do. In general, by the way one thing we want to do right now is like the current support like current toolings around persistent queries in the community is like half-baked, I don't know, in my opinion. So we're actually like we have two clients that we just started building something that makes it a bit easier. There's Apollo automatic persistent queries and all kinds of things like that. We think there's better toolings for that. We're going to, we're gonna open source like a basically a registry where you could, if you think about like you have all kinds of different sources also in GraphQL mesh you can have, you know, some sources that are GraphQL and some sources that are not GraphQL. And again, we want to kind of like have a view of all the different APIs together without necessarily running them all in one place like Apollo Federation. So what we're doing is we're building our open source registry that could take in GraphQL services, REST services, SOAP services, then use the mesh abilities to convert all of those and then look at all of those just as a GraphQL API, just so you could explore it. It doesn't mean that you need to query everything from it just to, so you can have bigger, better visibility of all the data in your network. I didn't mention it to answer. I didn't say that to answer your question. To your question, we think that registry also helps in terms of like registering all the different queries that you want to have, registering it somewhere and then generating the IDs of the persistent queries and stuff like that. So just to say that the whole tooling is around that we have some internal tools that we're gonna open source that will make it easier. For your question about taking the mesh generated queries, it's a good idea. And I mean, if you can open an issue on GraphQL mentioning that it will be really cool because it's very easy to do. And also this code that generates the all possible queries from a specific type or something like that, we want to actually move it so people could just use it even without using GraphQL mesh. So it's a good idea. That would be good. Yeah, thanks for the question. I see more questions on the text. You mentioned before that you might want to change from GraphQL to REST. When and why would you need to do that? Oh, interesting question. So it's called SOFA, the thing that I mentioned. Let me put the link to it just so, just find the link while I'm talking. But so the idea about SOFA was I had it a pretty long time ago, I think two years ago even more, and the idea was so GraphQL, in my opinion, is kind of like everyone was talking about, like should I use REST or GraphQL? Like what is better and blah, blah, blah. And what I thought when I looked at the core technology, I thought, well, GraphQL in terms of the information you have is basically like a super set of REST. Like you have the schema and you have the data and just the, you can think about it, the controllers are just being run automatically or executed automatically and you have a query. But if you think about the, let's say a REST endpoint, it's basically there is a query, right? Like there's something that is being returned, just nobody tells you that it's a query. So I thought, well, can I change that debate? Can I just show that GraphQL is kind of like can do all the things that REST can do but more. So that's why we created SOFA. I just opened, I just shared the blog post in the channel again.

So what SOFA does, it takes the schema, it generates automatically REST calls that are kind of like the same as what we just talked about, what mesh does. And it looks at the types and generates the possible queries like the query beforehand, all the, like, let's say a query of all the different fields of a type and just generates like a RESTful API. So for each type, you get like a, you know, like you get basically an end point that queries all the different fields. So that does that automatically. Just one line of code and you get the REST API on top of your existing GraphQL API. The reason you want to do it is because, the reason we created it was we had, we were working with this big airline and the web parts of it moved into GraphQL, but the mobile parts thought like, yeah, GraphQL is just it's not interesting at all. But we still wanted to maintain one gateway. So we basically exposed REST for the mobile themes without them knowing that under the hood they're actually using GraphQL. And the coolest thing about it was when they wanted to customize, like one thing that happens when you, you were dealing with REST about these themes are coming, the front of the themes are coming and say, Hey, could you custom, could you change the endpoint or give me a new endpoint to give me a bit of this data and a bit of that data. So in what we did is we just re-created a new URL and attached a query to it. And that's it, you get a new custom endpoint. So, instead of now taking a whole week to create a new endpoint then now it just, it takes like five minutes. So that's what SOFA, it's basically the other way around, 13 GraphQL into REST. This game of like adjusting REST to all the different other sources is very interesting for us. Like we learned a lot about other protocols, like OData, which is super interesting protocol. So, JSON schema, like there's a lot of interesting protocols and playing with them really gives you like a different perspectives of what is possible and yeah, I hope it answers the question.

Cool. What are the caching capabilities of mesh? So I think I just answered to Liron's question. I shared the link also on the Medium. So you can look at it like there's basically you can, you can configure basically which fields, like you can configure the cache keys. You can invalidate it, you can use TTL, yeah, there's many, many different options there. There's a lot of options like I want, it will be cool if you could look at it and tell us if we like missed some capabilities or something in the caching that you might need. But basically the idea is that today, Meshed is also being used as a full fledged gateway with many of our clients, so it's needed to support all of it. So, again, in the beginning of the workshop, we just starting to use Meshed as an SDK, like as a better Apollo data source, but it also runs as a full fledged gateway, with all the caching capabilities. And actually, like, you can even define those caching stuff even if you generate an SDK, but yeah, hope that answers the question.

Again, we have, like, I think, even still like two hours to go through all those steps, so I want more questions. Like, if you- I have a question. Yeah. Okay, so I want to use a GraphQL Mesh, but the problem is like this. The services behind it, like I can have some REST API and some other GraphQLs and maybe a database. They all return the same schema. I need a discriminant on the client side, like let's say a tenant ID, and the logic will put me something like, if you have this tenant ID, I'll redirect you to the GraphQL one. If this is the tenant ID GraphQL two or REST three or directly to the database. So is this possible? How do I do this? Because I need exactly the same query and all of them have to have the exact same schema, but there are three services and each service is for a different tenant. I see. And the question is like, do you want to expose it to the client as a single schema or as kind of like schemas... Yes, no, no, no. I need one single schema, so the client doesn't need to know he's been redirected. It just something in his authentication or something behind the lines that says, oh, you're this tenant so you'll go there. It doesn't matter what you want or what you know, you'll never see the other ones. Yeah, yeah, yeah. So that's a really good question. First of all, the reason I ask if you want to expose them differently because many times there's conflicts between the different sources. And then the question is what to do. And everything is possible. It's just a question of what you prefer. So for example, what I shared was that you can use custom transforms and the transforms could do anything. So for example, you can prefix each one of those with something and then you have a... Even though there's conflicts, it's basically like namespaces or something like that. But that works for some use cases, but for your use case, that's not the case. But I'm just mentioning that it's possible for others. In your use case, what you want is basically you want something that runs like in front of all of those, kind of like a middleware or something that then redirects it to the right source. So there's few ways of doing it. I would suggest looking at like Resolver composition, like basically you can define some functions or it's kind of like a middleware that run in front of all of those. And like this run every time like before each Resolver is being called. And then you can run any arbitrary call there. So then you can basically write some code that takes from the context, basically the right let's say the right SDK or the right source and just pass the query to that source. So yeah, so that's definitely possible. If you need like more help with that, like I can even do like a reproduction or like an example, and I can go in and do some PRs if you couldn't figure it out but it's definitely possible.

Okay so, is this possible with GraphQL Mesh? Can I set it up with, what would I need to put in GraphQL Mesh to tell it to use this discriminant and just pick a source? So, what I imagine you are doing and I think you can start doing, if you can start doing it, let's say on GitHub and I can join and help you if you get stuck, is that I would first of all put in Mesh all those three sources. I will generate the schema and then I will use resolver composition to basically tell Mesh which SDK to use for each query. It's a bit complicated, it's not super straight forward, so actually it would be cool if you can have, I don't know if you can, if you have the option but you can create a simple reproduction, like a simple app that does something similar and then I can jump and help you to do that. Okay, thank you, I'll try to see if I can do some. Yeah, by the way, I'll share my GitHub so people, like in my Git, on my GitHub, there's also my private email. So if you want to contact me or you want to like, and of course you can always just like open an issue in GraphQL Meshes repo but yeah, I'm sharing just in case someone wants to. Okay, thank you. Yeah, welcome, more questions if you have. Okay, I'll give one more minute for people to ask and then we can actually start going through the steps. Again, you know, you could start doing those steps already, like just clone the repo and do that. I'll talk sharing, but please keep asking. Like I want you to keep asking questions. Like that's the whole, that's better for me. Okay, so what I have here. Okay, so what I have here is basically the first step, like if you clone the repo and then you check out this commit, this first commit, that's where I want you to be. Now and I want you to then, now clone it, check out these steps, then run the yarn to install all the stuff and run yarn start to run this thing. Now do it again. And just to go very quickly through the setup. And, again, if this is like, let's say you never run a GraphQL server before and you don't understand what's going on here, tell me, like, please stop me and please ask questions, there's no dumb questions at all here. So what I'm doing here is that I installed basically Apollo Server, which by the way, I'll just mention, I'm using Apollo Server here because it's the most popular option, but it's not the best option, in my opinion. So if you are using Node, let's say, and you want to build a GraphQL Server, you should look at, let me show you where... By the way, I'm going now to graphql.org. We kind of like rebuild graphql.org, we build it in Gatsby now, and we change the code sections. So now it's much more organized, and you can see it's organizing by languages, so if you go to JavaScript, we have the server implementation client libraries and tools. And we also ordered them by how popular they are and how well maintained they are, and stuff like that. So Apollo Server is one of the most popular options. But in my opinion, currently the best... But it's not well maintained, to be honest. The dependences are very old, and there's tons of issues, open issues there, and open PRs, and they're just not super active there. But in my opinion, the best option currently is this one, GraphQL Helix. I'll share the link with you, even though you can find it yourself.

And I wonder if here there's a link to the blog post, because the blog post... Yeah, there is a link to the blog post. I'll share it here. It's a pretty new GraphQL service, but it's like, if I would build the dream GraphQL server, that's what I would use. And again, if I will do the work manually, internally in GraphQL Mesh, by the way, we just converted from ExpressGraphQL to GraphQL Helix. So yeah. Just to mention that if you were starting from scratch and you have the option to move, I would actually move today from Apollo Server to GraphQL Helix. But Apollo Server is still probably the most popular option, so that's what we're gonna use now. So install Apollo Server, which basically gives us the option of, we take a server and we can send like type definitions from it and resolvers from it, and then it will run the server. So that's cool. That's Apollo Server. We're also gonna install GraphQL-Tools Merge. What GraphQL-Tools Merge does is that many times what you want is... So people are thinking that you could, let's say you start to write your GraphQL schema. Yeah, but you want to separate it like here. We want to basically to organize the code beta, we want to separate the schema into responsibilities. So some people think that you need to use Apollo Federation for that or something like that, but you don't. You can just put those two, the schemas and the resolvers in two separate folders and tell the specific team or specific person, you're responsible on this part and you're responsible on this part. And then you need to merge them together so you could use GraphQL tools merge. That means at build time, it will take all the different type devs and all the different resolvers and to merge them into one and then feed those into Apollo server or whatever server you're using. So that's just like, so you know some people think that in order to separate your code between different places, you need to use Apollo Federation or something or schema stitching, you don't, you can do it at build time and that's actually is much better performance than Apollo Federation or schema stitching. So just so you know, and if you want to even create that separation even better, there's also a GraphQL modules, which will create the same separation that I just showed you but also separate the context and we'll use dependents injection to make sure that there's really good separation. But again, at build time, it will merge all those together. We just released 1.0 by the way, GraphQL modules, so also gonna add this here in case this would be beneficial for you. Okay, so that's GraphQL tools merge between stones. Then of course we want to use GraphQL because that's the case. We're using TypeScript and we use TSO to run it but again, TypeScript setup, it doesn't matter here. You can use whatever setup you want to use TypeScript or JavaScript, again, doesn't matter. But what we do here we use Apollo data sources rest because Apollo, this is like the, again, the most common way today for people to actually call rest data sources. So then let's look at the code. So let's start from let's say the GeoDB. So first, you know, we manually write the schema here. So we write, you know, find cities and we have the response and then here is the thing. And all of those things we configured manually. If you want me to go through it like, you know, slower or have questions, please ask, but I'm going through it really quickly because it's, you know, every GraphQL tutorial out there will show you how to do it. But now you have me here. So please ask questions if you need. And then in the resolvers, yeah.

Just a quick question. So I was actually using the GraphQL merge because I was basically extracting to, from a microservice, the Swagger definition and generate the GraphQL scheme out of it. Then I end up not being able to use like the, the raw generated file because I didn't want to expose all the types to the client. And I couldn't find a way to just expose some of them and hide the ones that I- Oh. Interesting. So you want, you have. But are you talking GraphQL Mesh now or like- No. Or you're talking just a regular GraphQL? Just the merge. Just, I mean, not really with the merge, but I guess I was using the merge to kind of merge those automatically generated GraphQL schemas with mines. Interesting. So what you've done, if I understand correctly, is that you've done something in between of what we're doing here. So you had like Swagger schema. You generated this thing, like you generated a schema from it, but then you manually went around and deleted some fields or renamed some fields. Correct. And then you did it. I see, and the reason you did it is because let's say you generated this and you generated also this schema. And then you wanted to merge them into like one schema to expose, but you wanted to whitelist basically or blacklist some of those. Yeah. Right. That's an interesting question actually, because in GraphQL mesh, we give you the option to do it. Like in GraphQL mesh, you have the transforms, the schema transforms, but I never thought about actually using it in the graph tools context to basically in that build time to do with the whitelist and the blacklist. And that's interesting. We could easily, very easily do that. So maybe even, I mean, GraphQL tools is used. So maybe we have it and I don't even know about it, but it's very easy to do. So it will take us a couple of minutes even. So what I suggest is open, instead of you manually doing it, there's no reason. Like it will actually, what you would want is here to have like, you know, take the merge and maybe like add some, some function here that's like, you can tell like, you know, white list. And then I don't know, you could do like, you know, asterisks or like whatever dot something or some kind of rule to filter those. And then it's fine. Yeah. This is a really cool idea and I think it's super useful. And if we don't have it, then, so please, please open the... Wait, I think there's people waiting for the, to get into the, how do I... Okay, so anyway, open an issue for it and we'll take care of it. So you won't need to do it manually, no reason to do it manually. Okay. Yeah. Thank you. I'll do it. Yeah, yeah. Cool idea. Thanks. Yeah. So, okay.

Just a quick question. You were mentioning the different Apollo tools that we could use and you mentioned that you would go with the Apollo Helix, but this is only for backend solutions, right? Yeah, yeah. I'm talking now about the server implementation. Yeah. So the server... Because now what we see here is now we're using Apollo Server. Basically, I'm not talking at the client at all. Again, I mentioned that like basically if I remove this thing and this thing, like theoretically, everything you see here can run on the client. Yeah. So you can take GraphQL and GraphQL tools, run it on the client as if it was a server, but here I'm just, I just wanted to mention that we're now running a server basically, or a gateway. And I just wanted to mention that a lot of people are calling Apollo Server, but I wanted to mention that I think Helix is, this is way better maintained and there's a lot of cool new features in GraphQL that I talk about in the lecture next week that Apollo Server doesn't support and Helix does, so yeah.

This is only for Node.js backend, right? Yeah, yeah, good question. So here we're talking now about JavaScript implementation. There's a final question regarding this, front-end, like the client side and the server side are completely independent of each other. We can use either, like whatever technologies on either one and they wouldn't affect each other, right? Exactly, yeah, exactly. Basically it's not even just the front end and the backend, it's even the query part and the execution part, right? Like because I could actually run this not between the network, I can just run all of this in the client and then again I have a, or it's on a service and then I have the query part and I have the execution part. And that's why, in mesh, we use it a lot in environments that are no JavaScript at all. We create meshes and SDK for Java applications, for.NET applications, things like that. So in that case, the execution will be whatever you wanna choose to do in the backend in this scenario. And on the front end, whatever you do, that will be the query part. Yeah, we don't have too many like open source examples to it because we don't have too much of those use cases, but if you have, for example, a use case like that, then let's talk and let's create a public example together. Like I think there's a lot of people would find it useful. Okay. I think it's a good question. Yeah, I saw there was a chat and maybe I'm missing like stuff on the chat. Let me just check. Yeah, okay. People are, thanks for covering on me. Okay. So again, so what, I'll just go very quickly. So we have, you know, we wrote this manually, then we created a resolver, right? And this resolver is not typed. Again, if you're having a resolver, in Node.js and using typescript, this thing, the query, like this, sorry, this thing in the find cities, it's not typed. You see, it's all any, any, any, any, and the return type is any for that. I mentioned it before. You should use, I'm not gonna, again, I'm not talking about this today, but if you are doing this code like that today, you should go to GraphQL code generator and use the, it's loading, but use the, basically the resolvers signature plugin. And the resolver signature plugin, what you see here is like you get the schema and then it will basically type those resolvers. So you would automatically get those functions, the old route, the args, the context and the info type and the return value being typed as well. So just so you know, like that's, it's a very popular tool and we will probably use it. But there's more things that are not piped here. This is a function like, you know, find cities. This is the resolver function and this is the content of that function. What I do, I go to context data sources because that's how, you know, you work with Apollo server data sources. And I created a Geo DB API data source that has a function that's called find cities. Again, in that function, you'll see there's no types. So basically I have no, if I'm making a mistake here, I'm calling the rest API and it doesn't even have the things that I need.

I would know it until I go into production. So this is the data source, by the way, I'll go here. Again, it's just a manual function that I create, manually class Geo DB API, from race data source from the same function that we created. I give it the best URL and then I can do get or post and I give it, you know, some arcs. And in this case, it's a name prefix. You can, by the way, go to this, you know, Geo DB. If you want to look at the sources that we're creating here by the way, you can go to those URLs. I mean, I don't need to share it with you because you have it in the code. But, yeah, those are the sources, like Geo DB I don't remember. Even if you Google it, you get this. And the same goals for the Open API, Open Brewery API. Open Brewery API, I'll open this one as well here. So you can later find it out. And yeah, so that's the case. So again, everything works, like let me close those things and close a bunch of those things here. To find this, yeah. And everything works, you can see, I have a running GraphQL server. I have the documentation that is based on the manual schema that I created, I can search the docs and I can query. So I can go in and I can find cities. And again, I can write something here like longitude or something, and in this case, Chicago and I get this. Or if I write here, I don't know, Tel Aviv or something, I get Tel Aviv. So that's cool. And again, I'm sending this query from a client, it goes to my server, my server parse this thing, called the data source, everything is fine. Now, we want to actually move to the next step. Now the next step, I'm just gonna check out this thing and then we're gonna just look at the changes. And let me hide this, let me see if we can... Nothing controls. Let's see if we can bring this up. If this is smaller, then we can increase this. I wonder if I can make this bigger and if not larger. If this is bigger and if not larger. I can also open it here, right? Let me get up just so it will be easier to look at. And then we also look everything we see we're gonna show you in the code itself. I'm gonna also rerun the server. Okay, so let's look at what we're gonna do here. This is again, still GraphQL, still nothing to do with Mesh. What I'm doing here is that I want to connect. So until now I queried each one of those APIs separately. I have find cities and I have find breweries and they work separately. But what I actually want is I want this, let me refresh this so it will pick up the new server. What I want is basically I want one query. I want one query that I get find cities, I get the city of Amsterdam and then I find all the different breweries in Amsterdam. And I do it in one single query, one graph, as it's called. So how did we do it? It's actually pretty simple. I needed to add to extend the type, the city type and add to the city breweries. So I just, we have the city schema, let me show you that. Where is the city schema? Here, I have the city schema, schema doesn't have breweries. So what I need, I need to basically take the city schema and extend it from another source and add this field breweries. But then I also want to create the resolvers of the resolver for these field. And the resolver for this field is basically what it does, it takes, it uses like the root query, like the root, the root information that I got from the parent resolver, I'll show you in a second, like, because this thing will run under city. So it will run first, the city resolver get the information and then it will run this, this resolver. And if this is basic again, like, it's fine, I just wanted to go through it. And then it will take the value from here, extract the name from it and send it to the other data source to find breweries. So it's basically, I'm doing an extension here. The reason I'm showing it now here is because we would later do it with mesh. And again, using the GraphQL tools merge, I just take those two extensions and I just add them here to the merge resolver function. If you look at the diff, that's all I've done. I added this thing and added this and this, and that means that now, if I look at the docs, for example, and I'm looking to, let's say the city type, yeah, the city type. You'll see that it has breweries. And for breweries, I can go here and get all the breweries. So that's cool. If you don't create this type of thing, again, let's like change to another city like Athens and see if it will get it. Cool. That's good for me. I'm currently in Athens, by the way, so now I already know where the breweries are, even though I can't leave the house. So. So this will be an automatic way to do it instead of doing it manually, because you're just overriding it instead of going to the origin of the data, correct? So this is the GraphQL way of doing it, not but the manual GraphQL way of doing it, right? I needed to write that code, right? Yeah. So I needed to create that, I told GraphQL, look, here is a new field, and, you know, here is how you get the data. And because it's a field under city, it will first have GraphQL works, it will first run the city resolver, like this findCities resolver, like the root, basically the root, this one, the root query. So it will first run the root query, will get the result, the result will come from here. And then, because it's a field under here, it will first run that, take that as a parent value. That's what I'll get here in the root. And then I'm taking the parent value. What I got, they picked the name, and I'm passing it in as a parameter to this function. And again, this function can come from something completely different, but in our case, it's actually the other data source. And now we get the connection. We get this connection between a city and a brewery that we created. Those connections are business logic, right? Those connections, you know those connections because you create the product. Like if I create, I don't know, let's say a different app that doesn't have to do anything with alcohol, then I wouldn't create this connection, right? It will be weird. So this is like, let's call it a business logic, but you create the graph of your own product. I hope that answers. Yeah, sorry. Yeah, it does. It does answer. And then this is possible because instead of like, you wouldn't instead go to the origin and edit the origin because this is assuming that you don't have access to the origin or am I wrong? I mean, the signal, the origin is yeah. Oh, I understand. The origin is this thing. It's like, first of all, in this case, it's a public API that I have no access to, but also maybe this is a micro service. Like this is a thing that is responsible for cities. And we want, we don't want the team that's responsible of cities to know everything about breweries, right? Like this is the whole point of like microservices.

That's another thing, by the way, that people are mistaking about. Like if you do architecture in a large company, it's where does the breweries field under city actually belongs. Many, a lot of mistakes that people do architecturally is they think oh, breweries is under city, so the city team is responsible for it. But that's not the case. Actually, someone else should be responsible for this. And maybe that someone else, like, and it's a question, by the way, we have a lot of this discussion with a lot of large companies. Like is this thing belongs to the city team, or is this thing belongs to the breweries team? Or maybe it doesn't belong to any of those, it actually belongs to the product team that builds the app because they know the connection. Like, maybe this team doesn't care about cities, and this team doesn't care about breweries, and it's good that way, because they can focus on their service. And then this connection can actually come from another place. So that's a more philosophical question of who's responsible for the connections, which I have a lot of opinions about. Yeah. And then, GODB would be like the city's database or the city's data. And then OpenBrewery would be like the brewery source. And then the index in this case is joining them both and giving you a new endpoint, to say it that way, or a new query, or a new mutation. Exactly. But also I could create here. Oh, sorry, continue. So basically this project, or what we're trying to do right now is just emerging this to microservices into one and exposing it again. Yes, exactly. And exposing the API that is best for the product, for the consumer. Yeah, that makes total sense. That's pretty cool. And then you're seeing we're currently doing it manually. And now we're going to check the solution of how to do it with Mesh, is that correct? Exactly, exactly. Yeah, yeah, that's a good way to put it. And it's like, so again by the way, this thing, this connection, it's not, I wrote it here just because it's simple but all this code can sit in another file, again, like in another team, maybe the connection team or the app team. And then again, just import this code from the app team and put it right here in the merge type. So, you could put that, that's just for the point of like, you don't have to use, I don't know, Apollo Federation or schema stitching in order to separate between different teams and the gateway between different teams, you can just import it and just use GraphQL merge or if you want something a bit more sophisticated use GraphQL modules that I put the link before. So, I hope, by the way, does everyone have this thing running? Like this current step? You could write it manually, by the way I'm just like, you know, checking it out, but just to save us all time because you don't care about me typing, but you could type it if you want and you can again go back to this workshop at any point in time. In the future I'm going to add more features to it as well, but that's basically all I've done. I hope everyone has this now running and again has this thing running, right? We did, first step was just to create a simple GraphQL server where we take the existing micro-service sources that we use or the sources that we use, and we could just pick and choose the right fields we want, which is already cool. But then we also add the disconnection. So we can not only pick and choose the fields we want, we also can create in one request. We can actually create one query that does those connections. And everything I showed you until now is basically like the most basic GraphQL tutorial, like nothing super fancy, nothing new, but it's still important to know. So that's cool. But now what we're gonna do, is we're gonna take it to the, we're actually gonna start using mesh, the GraphQL mesh, which is the thing that I just wanted to talk about. So let me do that. I'll stop the server, and I'm gonna check it out, but I'm gonna do all those commands with you, and you can do this with me or check out this thing. I'm gonna do yarn. Why I'm gonna do yarn, because we basically, we are installing new libraries. What new libraries? Let's look at the package JSON. So we're installing GraphQL mesh. So that means, if I wasn't lazy, I would do, like, let me add this. I would do, npm install, or, yeah, sorry. npm install, or yarn add, graphql-mesh-cli. The CLI is like the basic library or the core library that we're gonna use. GraphQL mesh config is the one that, like, we can, you know, send the config to. Runtime is the library that, actually, we can run GraphQL mesh, like, as a server. As a server. I installed it here already, but the truth is we could just do it in the next step. And then we installed, we have the handlers. So we're installing GraphQL mesh open API because we have one source that has an open API schema, I'm going to show it now, and another source that is JSON schema. It's a source that we don't have a schema and we want to feed it with information and generate the schema from that information. So let's see, so that's the first step that we've done. Let's see if the, it will probably take a bit over a while for this to install. That's fine. Now, so we ended mesh, that's cool. But what do we actually want to do? We want it to take the data sources that we had before. Let's look at it here. You see, we completely deleted those data sources. And we, but we want to generate them. We want to do, have something that replaces this with something better. So for that we have the mesh SDK. Do you want me to increase the font by the way? Like I can zoom in a bit or something. Is this better? It looks fine for me either way. Okay. So because for me, this is now huge. So it's a bit harder, but depends on you guys. Like, I can, if this is smaller, let me know. Yeah. So I can make it bigger. So what am I doing here? I used to have two sources. Let me just remove this for now for like clarity. So I used to have two sources, but I want now those sources to be created for me using RoughGl Mash. So first thing in match is sources. I can define how many sources I want. I can name them in this case, I'm just naming it godb, but it can be, you know, whatever I want. And then for each source, I need to basically create the handler. The handlers, if you want to get the list of the handlers, let's go here, roughglmash.com. And here in the documentation, you can have, Oh, by the way, first of all here, you have like also an online example. It will take a bit of time to load because my computer is like screaming at me, but here are all the handlers that you can use. So in this case, we want to use OpenAPI and Swagger, so we're just gonna do yarn ed roughglmash. And then in the handler, we're gonna say OpenAPI. And here you have like all the different options you can send to it. You want to use gRPC. Again, you will install roughglmash.grpc, handler gRPC, and then you get all the different configurations that you can send for it here. Same for soap and others as well. Yeah, so here is the list of everything. In our case, we want OpenAPI.

So in OpenAPI, the options that we get, let's look again in here. We have source, source format, operation headers, kind of like similar to the questions that were asked here. For us, all we care about currently is source and base URL. What is base URL is basically the same thing that we configure here in the data source, right? Just where to send the calls to. But then we have another thing. This is the source. What is the source? The source is, in this case, we have a swagger schema and in this case, it's all, we can even like call a URL and get it. So we just put the URL in. Now it could accept, by the way, not just URL. It could accept the local file or whatever, you know, you have it too, but here we have all that information. So we could now take all this and convert it into GraphQL. So that's all just by doing this. We basically, let me, the yarn star.

So a handler is basically a protocol? Yes, exactly, exactly. So because I can have multiple open API handlers, I can have multiple JSON schema handlers, right? So handler is like, I can do like, let's say another one here, and this is another open API, but that will call, you know, I don't know, HTTP dot another thing, dot com, yeah? And that's fine. And another URL like, you know, another thing, thing.com slash swagger, yeah? And now, and I'll call it like, another thing source, whatever, yeah? So, just as an example, yeah? So I can have as many sources that I want and each source, I just need to give it what type of source is it and what handler it needs.

I have a question. So this measure C file, it seems static. How can I make this configuration environment specific? So I can run the same code on them more production integration environments, but for example? Good question. Yeah, good question. I have a environment viable support. I think we just added it to the like how to like, we have it as an example somewhere, maybe in recipes. Don't remember it. Basically, but yeah, it's possible. Like you can just, the measure C accepts like, first of all, you can by the way, everything is like also can be run programmatically. I didn't mention it, but you can load the everything here that I'm doing statically. I can also do programmatically. I can like load this programmatically and I can now load this from a code file and not from a YAML file, but even in the YAML file you have support for like environment variables, for example, or headers or things like that. Like, I think if you just google GraphQL mash and environment variable, I'm sure it's like gonna find like probably the first result will be something like. Hmm, I don't know. I don't want to do that. We should make this the computation more obvious, but also in the examples we have. So yeah, it's completely like you have support for environment variables and also other things. So yeah, that's not a problem. It's a very basic use case that a lot of people are asking. I don't know why it doesn't bring me like a valuable source in the Google search, but it's supposed to. I'm gonna take a note about that. So it will be much easier to look at and to find. Maybe there is some more here, I don't know. Yeah, I can put root code. Yeah, there's, I don't know. I will find an example in later in some but it's, it should be easy to find. We get this question a lot. Okay.

So just, but I wanted to show you the total. Like, let's say just define this and that's it. And again, I removed, look, I removed the data source. So now in the resolvers, let's see what's happening. Let's look at this. So let me find this code. So what I'm gonna do now is I'm gonna find and parse mesh config. Like here, I'm not sending it any, anything so that, you know, the default thing is like dot mesh or C dot YAML. So it just gets that measure C, you get the mesh config and then get mesh. Basically I'm sending it the config and it will get me an SDK. It will make it get me like this and then I can get the SDK. So this is the SDK. Now, what is that SDK? This is basically at this stage, just a data source. Why is it better? Let me show you. You see this? So now what you see here, this is pretty cool, right? Like I'm sending a REST request, but I get autocomplete. I get autocomplete of all the possible functions that this REST API could give me inside my IDE if I'm gonna like write something weird here, it's gonna fail the build. And more than that, if I'm now, like I will send here something that is, in this case, it's like not that, but if I'm gonna send something here, it's gonna like it depends on the Swagger file, but it's even gonna type my arguments. So how does the API know, or how does this library know which are the available queries so it can pretty fail to the SDK? Ah, so yeah, that's a good question. So like it takes each one of those, where's the, let me find, I heard that there's like, for example, for the HTTP protocol, I heard that you're supposed, if you follow the HTTP protocol, you're supposed to expose this, like all the possible queries that you can have and stuff, but what if it's not correctly implemented? Which tends to be the case. Yeah, so here I'm not basing my thing on the fact that they implemented my queries. Swagger files basically describes end points. I know what end points, let's find this end point that I'm calling to, yeah? Let's go to the resolver of the GODP, find settings using get. You see, I have this operation, I find cities using get. This is REST, yeah, and this is like the, it says what's the URL for it, it says what the parameters are. And it also tells me what the responses is, yeah? So now basically I can take that and I convert that into an SDK. So basically each operation from here, I'm not counting on anything, I just count on the swagger. I just see that here, I get all the operations that I get and I get the, yeah, and I get like, I add a query, but this is, again, this is something that you can configure. I get this thing, and I also get the result. Like, you see that the result is typed. You see here, like the result, also the result is typed. So I have this and I can get data and I can get entries and whatever, yeah? So this is fully typed. But does this mean that this is swagger dependent? Yeah, so okay, so good question. So this is specifically the swagger implementation. So what I want to do here is I want to rely on the swagger. I believe the swagger is good, but first of all, like you say, maybe the swagger is not complete or is not accurate or something like that. So I can customize. They haven't transformed that I can use in a mesh and maybe I'll show you how to do it later, but that's more related to the JSON schema part, I'll get to it, yeah? We'll get there. I'll show you also that what I think you're meaning, but this is a bit of more advanced use case, like I want to get it in steps. So yeah, so here what I, again, the first thing I'm doing is like, I'm relying on this. I believe...

No, I'm sorry. I was just gonna say that so far I was trying to see how this magically made everything, but now I understand that it's basically more of an automation for manual labor. So basically, I'm posting this like, what if the swagger is wrong? But the fact is that if the swagger is wrong, you cannot do it manually either. And that is where this comes into hand. If you don't know about it, yeah. I see. So what you're saying is like, this swagger is wrong, but I don't know it's wrong. No, no, like you would use mesh if you wanted to automate this process, right? But it's also like, it's limited to where manually you could do as well. Ah, yeah, you mean like, if you could just guess things, I don't know, how would you do it? I'm trying to understand how you would do it another way. Yeah, exactly, that's the thing. I thought that it would automatically guess this stuff that you wouldn't be able to do manually, I would like to make it some, I don't know, checking all the queries or somehow. But now I see that it's not that, it's just to make the manual process. Mm, I see. I wasn't understanding exactly what mesh was, and now I do, that's what I'm trying to say. Okay, okay, so this is one part of it, there's another part, which is another more advanced use case that we do as well in some clients, which is, let's try to guess those things. But that's more related to the JSON schema part, I'll get to it, yeah? We'll get there. I'll show you also that what I think you're meaning, but this is a bit of more advanced use case, like I want to get it in steps. So yeah, so here what I, again, the first thing I'm doing is like, I'm relying on this. I believe... I believe G-O-D-B, that their swagger is correct. But then again, instead of like having what I had before, which is this REST data source, it didn't have any type. And if I would make mistakes here, I wouldn't know. Again, I get this how to complete and everything we've seen here. And also in here... Where is it? Here for example, in the brew set up, I also get the input. So if I write this, I get an error. So again, this is a REST API. This is not a GraphQL API. And I still get the in editor errors. So that's in my opinion, like the first... This is like how would, let's say you're already using GraphQL. This is the easiest place to start using mesh. Like you can start getting the benefits of GraphQL just instead of your old data sources. Like, you don't need to replace all your code and everything and let's look at all... What are the changes I've made here? So this is one source. I just told it like where to query from and the source of the swagger, like that will basically from here I will generate the SDK, but then I have another source. Open Brewery. Excuse me. Yeah, yeah, yeah. If I want to pass through the authentication where do I need to put that code? Here, let me show you. By the way, here you have a list of them. By the way, let me, I'll try to find also an example of what you said, but here basically you have operation headers, schema headers, like for example, a schema headers is like... If you want to fetch that, let's say this schema is public like the actual swagger schema is public, but let's say even the schema itself wasn't public and you still want to even authenticate just to get the schema, then you pass it with the schema headers and the operation headers is where you send the actual, when you call something and you pass through the, whatever you want, JWT or whatever you want to send through it. Yeah, but if I'm doing manually, I'm at this step where you just use the SDK, when it builds the SDK, it will automatically pass through the headers and I can just call that function where you're right now in code. If you want. Yeah, yeah, exactly, yeah, yeah, yeah. Like you can. Ah, so it will do that automatically. I don't have to make some, to put it here in the resolver. I don't have to query the context or take something from the context and pass it through the. No, it's a good question. So you have the two options. One is you could like take it from the context and then pass it in as like as parameter or something like that. But also what you could do is you can actually reference the context here. Like what you could do is you could do something like operation headers and then you can like from here, you can reference like you can do something like that, like I'm not sure I'm making it then get exactly the right. But I can look later in the context dot whatever. Yeah, and then you can pass it through, yeah. And I think we have a number of examples like that. I don't remember which one is what. Let me see if there's something obvious that I remember. You see that there's a lot of stuff here. I think the stripe API has something like that. I'm not sure, let me look at the mesh code. Yeah, you see here, operational headers. And then you get the authorization header and then you get the parent of the stripe token and then token you get from it's an environment variable, or something like that. So you have different options to do that. There's more options. Yeah, thank you. Yeah, so, okay. So that was this source, this source, but then we have another source, the OpenBrewery source. Now the OpenBrewery source is a bit less nice than the GeoDB source because we don't have a schema. Like the best we get in this case is just like the documentation website. And maybe that's not even that is not something we get. So you see, they don't have a schema. In this case, what I've done is that they have example output and example inputs. You see, they have CD by name. So what I've done, you can see again in the, let's go back to the diff. Too many tabs. Where do I find it? Yeah. I'll just stop at it here. So what I've done here, I created breweries input sample and I just copy pasted this from the website. Yeah, and then this is like a response sample. Like example, input example, output. And then I told mesh, hey, this is this handler, the open brewery sample. This is a JSON schema handler. It's a different handler than the open API. This is the base URL. This is where you call it. But here are the operations. Like you have a query, on the query you have filled breweries and this is the path and this is the method.

And for the schema I want you to generate the JSON schema. Here is an example request and here is an example response. And again, those things I could feed from anywhere. So this is, and here you can get very advanced and very sneaky. This is also related a bit to what you asked before. I forgot your name, by the way. So sorry, can you repeat your name that you asked about like automatically finding those connections and stuff like that? I forgot your name. Juan? Juan, okay. So Juan asked if we can like automatically find those things. So here, first of all, I get an example like logs and I can like connect and direct this to my data dog or whatever I use to like query, to store some responses or something like that. Here, I just copied it from the example website, but I can get more, and then there's tons of tools that would help us basically take this and generate the schema from it. And so, and here you can get very, there's many, many interesting tools but like guess things and everything, and you could fit those things. But here I'm deliberately using the most simple example. I have those examples, I don't have a schema and it still will still, GraphQL Mesh will generate that same SDK that I was talking about. So still, if I will take the SDK and I will do here and I have brewery, I'll get this thing and it will be completely typed. You see, I have the variables and everything and also the return type. So, you know, if I'll get back here, this thing is typed. I know exactly what I'm gonna get here. Yeah. So that's extremely valuable. So this is why just by doing this simple, I'm walking through very slowly about everything I've done here, but like for the changes and everything. But basically I didn't change a lot, right? I just installed Mesh. I gave Mesh this input and ran here to generate an SDK. And that's it. Now I got like a completely generated SDK with all the types and stuff that will take me ages to create and also to keep it updated and everything. And I could delete the data source and just replace it with this, you know SDK that I import from the generated thing. So if you have existing GraphQL servers today, this is the first step you can do and you could do it in a matter of like a couple of minutes. And you get now not types only on your GraphQL stuff, but also types inside the resolver calling your existing old REST services. So that's a very powerful thing.

By the way, let me see if people wants to join. I'm keep missing people that wants to join. Okay, so yeah. Yeah. Even outside of the GraphQL context, this way of being able to study, I'm not sure about the verb, all client library, all servers is really interesting. Yeah, exactly, exactly. So this thing, this is very interesting because that's the point that you can use. That's the one thing that it's very hard to explain to people. This library, just removed the name GraphQL and it's still a super valuable, right? Like all those things, this is related, this is also related to like the fact that GraphQL is just an evolution, in my opinion, of other APIs. So you could use the same techniques and toolings and everything in the GraphQL world, just don't call it GraphQL, you know? Yeah, but is it, this client library, is it available outside of the mesh library? Yeah, I mean, this is the mesh library. You just, you don't need to, it happens to be called GraphQL mesh, but you can just, again, everything I've done here, you get the safe SDK, yeah? So this SDK, like, you know, I just called the SDK, yeah, so this is the, I put it in the context, let's put it, let me use it here, easier, yeah? So SDK, you see here? So maybe I don't even use GraphQL. Maybe this is just a regular Express server, right? And I got all those benefits. So you're very much right, like, this is something that, even if you're not, I'm doing this workshop here because I started from GraphQL because most people are coming with the knowledge of GraphQL. But that's the thing. Like, I could do the same lecture, remove Apollo server from here at all, and just do SDK, whatever, and we could be in a Express conference, you know? Or in a React native conference or a React conference where I do this SDK but I just run this on the client. Right? Not even on the server. Yeah, that's a very good point. Okay, so that's all I've done, yeah? I got this SDK and I just happened to use it on the GraphQL server that I wrote. So that's cool. So that's GraphQL Mesh. Pretty cool, I think. Pretty cool library. And we're already using it. So that's nice. Now I want to go to the next step. So let me jump to it. And let's see what the next step is. Okay, so first of all, let's stop the server and then do a yarn again. Not because actually I'm installing something new, but because I'm removing now a lot of stuff from NPM. And we're gonna see what I removed just now. So while it's running and removing some stuff, let's look at the commit. So first of all, the commit says switch to mesh serve instead of SDK and Apollo Server. So we used to use mesh as an SDK inside a Apollo Server. But now what we're saying is basically, let's remove. We can actually take mesh and let me show you. You can see how much code we removed here. But let me go here. Yeah. Let's look at the court for a second. Again, I want to do load this. catch. Yarn. Yarn start. Okay. Let's see what's happening here. What yarn start does? Yarn start does mesh serve. It doesn't anymore goes to index.ts. You saw that index.ts, basically the thing that, you know, our main server file where let's me find it here. This thing is gone, no more Apollo server. What did I replace it with? Let's go to mesh. I had the same sources here as before. Let's skip this part for a second. We're gonna forget about this part for a second. I'll just remove it like this. I just said serve port 4000. Here is an example query for you to like show. And this is, you don't have to do this. Yeah, you can remove this. This is just like, I want to get this query just to put in graphical playground but it's not really needed. So that's also now GraphQL mesh is our API gateway. It does everything for us.

So that's cool. So, this is everything, but... Wait, let me also... Just a second. Yeah, but I still, I had some logic in this, where is it, I had some logic here, right? I created this, extra stuff that I want and I still need those extra stuff because just from those sources, it's not enough. Those sources basically generate this SDK for me, so I can call this handler as a GraphQL and this handler as a GraphQL, but it's not enough, right? I didn't, I wanted to do more than just call the find cities and just call the find breweries. I wanted to have the breweries under city. So how did I do that? I also could put it here. I could have additional type depths. I can take all those different sources, generate the GraphQL schemas from them and then add whatever I want. So you see, I extended the type in this case because it was generated. It's not called city anymore. It's called populated place summary because it really just generate, like just it's generated type from the sources. And I just added breweries under this thing. So this is manual schema that I can just add to my generated schema. And I still want a resolver. I want something that will connect those two. So in this case, what I'm doing is I'm calling, I move the logic that I had before if you remember of the resolver, I just move it to a code file that I use here. And again, I still use like, you know, this thing and it's still updated, you know, like auto generated, like all the code here is fully typed. Like if you see here, this is fully typed as well, this resolver, because I know all the inputs and the outputs just like the GraphQL code generator. But I also know the context and everything that comes with it. Like, you know, open API, brewery API, all those things fully typed. And I just, while having all of this fully typed, I can just create the connection. And I know it's build time, it works because it's fully typed. And instead of now having like imported and all those things, mesh is my server. So I just took additional resolvers and referenced the file. That's it. So now again, I removed the pull-off server completely and let's just refresh it. And yeah, oh, sorry. I want to go back. No, it's never. So I wanted to show you that the first query didn't work because now this is generated. So it's not anymore called cities, it's called find cities using get because find cities using get is actually a GraphQL. You see here, it's generated all the different APIs as GraphQL. So I can just start querying this as if it was a GraphQL, you know, I can add here. I know in city, I can whatever else I can take it from like country and like, I don't know. What else we want? We get that ID, whatever. And then I can also have breweries. And from the breweries, again, I can query for whatever I want. It's like possible code, but same. I can send this and I get all the results. So I got here again, a GraphQL gateway that calls the different sources with very, very little amount of code. Like let's look at all the code we removed. So I removed a lot of libraries, yeah, but I removed the resolvers and the typedefs. I removed the indexts, also the resolvers and typedefs of the OpenBrewery. Like I removed most of the code, but it still works as before. Right, so that's very, very powerful. So that's cool, but maybe we can do even better. So let's go to the last step, that happens to be called no-code. May I ask a question meanwhile? Is it possible to maybe some, to have some debug mode to actually understand what actual queries are running behind the scene by the mesh? Ah yeah, yeah, yeah, yeah. We have, it's just a middleware, you can put it there. Yeah, I think, I mean, again, we already have it, but I'm not sure how, if it's super visible. So if like, if it's not obvious from their website, that let me know and we'll improve the, Oh, I want to show you something by the way. Just a second, but yeah, of course you have to again, this thing acts as a gateway. So all the things that you would want from a gateway, for example, I'll give you another example. What if I want to start updating those things at runtime, like I have one service and now it gets updated. How do I, you know, when you have a huge gateway that now works between a lot of, with a lot of like different sources, those sources can be up to date and we don't want to have downtime. We don't want to take down the gateway, recompile it, and do those things. So all those things are possible. The documentation currently is like sometimes missing, but it's possible. And in terms of the documentation, just before I'm going through the last step, I want to show you something. If you go to GraphQL Mesh or, if you go to GraphQL Mesh or any of our websites, you see this thing, it's the annoying thing that jumps here. This looks like an annoying marketing thing, like an annoying bot that will ask you to buy something from the guild or something, but no, this is just an actual chat that actually goes to us. And we answer here for a lot of people. Every time we give an answer here, we ask people, okay, we got you the answer, now tell us how to improve the documentation so we won't have that anymore. And this is across all of our websites. Like if I'll go to the guild, and now if you go here to the website and you go to open source, and we have GraphQL modules and GraphQL CLI and GraphQL config and GraphQL tools, let's say if I'll go here, go to the documentation, again, you can talk and ask questions. So I just wanted to let you know about that. Like it's very easy to communicate with us and ask questions and we get a lot of those. Oh, by the way, in other places, like this is, we have also our own Discord, which you can see a lot of people are talking all the time and we have all the different open source libraries that you can maintain. You can just come, ask questions, have debates. Yeah, just so you know. And you can just also, like I said, you can go to my Github and ask directly, but yeah. Okay, I hope I answered your question and if not, ask me again. Yeah, I got the answer. Okay. So now let's look at the code. This is the last step. There's no code. There's basically package.json and a MesHRC file. That's it, right? What I changed here, let me show you this. You go to the no code section. So what I needed to add was basically to replace the resolver. Like if you remember, I had an additional resolver and I wrote it in code, but instead of writing it in code, I wrote it in a config file, just connected the root to the root, which I'll talk in a second about that, but then I removed this mesh, and it's just mesh serve. I removed all those dependencies. TypeScript and all the runtime stuff and VS config, all those stuff. Basically, now all I have is a mesh RC and a packet JSON. I also have the mesh RC once like an example here.

Basically, now all I have is a mesh RC and a packet JSON. I also have the mesh RC once like an example here. So I still have those examples, like example JSON. But again, you know, this is just examples, so mesh could generate, but that's it. So that means that you can just take mesh RC and that's it. Like this package JSON is always the same.

So by the way, from the community, if you write GraphQL mesh Docker, let's see. So you see the community just created this, for example, thing where, I think there's an image here. You just, you take a Docker container, like a mesh Docker container, just send it the mesh RC file and you're done. You have a GraphQL gateway for all your sources. That's it. Just mesh RC file. And again, that mesh RC file, I showed you here like very basic example, but we can add here endless amounts of handlers. You can customize, you know, this everything here and way more.

So that's like the basic workshop. Basically the idea here, again, if you go to the workshop, here you see there's not a lot of files here and all those files can again be replaced with just mesh RC file and a Docker container. That's it. And you get a runtime, like the gateway. Let me just show you that everything still works. New yarn to remove all the crap. I assume you should have some tool to validate that the mesh RC is actually a correct file because you basically... Yeah, yeah, yeah. So I, first of all, so I don't know if, maybe it's not installed here, but we have a JSON schema that also describes the RC file. So like it will give you auto-complete and like you know you get errors if this is not handler but handler. I just, I think I didn't install it here, but we have it also for the Cogent like we have the Cogent YAML file and we do the same. So yeah. So I wonder what did I want to show? I want to show that it still works. So let me press. Let's remove some stuff just so you see it's like different. So again, if you think where we started, which is where we started is probably if you would know like let's say you would start, let's say you would start a GraphQL server workshop for GraphQL Galaxy, where we started is where you would end. Is where you would end that works, right? Like the this place, the code here on the first commit, this is the end of the GraphQL workshop. But we took everything you've done in a full workshop of GraphQL and we basically turned that into like one measure C file. And that's the power of mesh. And the power of mesh is that also we did it gradually. You started by just using it as an SDK. And like someone said here which is very, very smart thing to say, I think is like, it has nothing to do with GraphQL. You could just start using it today in your rest applications and in your client code without even thinking about the GraphQL. So it's an extremely powerful thing. Yeah, now I want to mention one other thing that might be important here. So we have been here, those sources. We had also some additional resolvers and stuff like that. Yeah, so and we created this connection between those two. So it's kind of like what I showed in the slides, first we took those and turn them into GraphQL and then we turn them into one graph into one thing. Turning it into one graph, you have few options. I want to show you that. Let me go. Oh, this is another thing I wanted to show you. So I'll skip that. Let's go to GraphQLMesh.com. How much time do we have? Yeah, we have more time, that's fine. So if we'll go here, you can see here like all the basic stuff and everything. Installation, basic usage, Match, Transforms, again, I showed you some. This is, yeah, later you can look at transforms, it's very interesting. If you want to get more than basic use cases and everything and there's a lot of stuff here. Extending schema with multiple APIs. Like, I have multiple different APIs and I want to connect them. So like I said, there's, you can use additional resolvers and we're just attaching those and creating those things but you can also use schema. So merging multiple, there's many ways of merging multiple running GraphQL servers. Most people are known or heard about Apollo Federation So first of all, with GraphQL Mesh, you could choose. So you could use Apollo Federation as the merger strategy. So I can declare merger federation and then I can say, if you know Apollo Federation you heard about it. There's like, you can use directives in order to say which field, which source is connected to each other. Here you can just use the same thing. We actually use Apollo Federation in order to merge those different sources. But there's another, there's the competitor of Apollo Federation is schema stitching. Now people think that schema stitching is deprecated but that's not the case. I wanted to show you something. I'm gonna share a blog post that I think you should read. What is schema stitching? Schema stitching is... Wait, let me... My earphone is dead. So tell me if you... Wait. Can you still hear me now? Yeah, we can. Okay. So schema stitching and Apollo Federation is basically the idea. What if we have multiple GraphQL sources and we want to turn them into one graph, one GraphQL API. Wasn't that what we were doing? We did it even. We took not even GraphQL. We took something that is not GraphQL, turn it into GraphQL, and then the next phase is to merge it. Yeah, true. You're right. So, yeah. So merging those, let's say, it's just, it's a big discussion in the GraphQL world, like I'm not going to dive too deep into it, but I'm going to put this blog post so you can read about it further. It's important blog post if you're, because there's a lot of people are talking about Apollo Federation, and they think it's the only choice, or they think that Apollo Federation, basically, that there was schema stitching, and then Apollo Federation is the next generation of schema stitching. But that's not entirely true. It used to be that schema stitching was maintained by Apollo. They stopped maintaining it. We took over and made it today, in my opinion, better than Apollo Federation. If you scroll here and you read this, you can find here a blog post from Vox Media that basically saying, should I use Apollo Federation or schema stitching? And they're how they decided.

I'm just mentioning it for people here that are from the Grafton world. They're not... If you're already in the community and you heard about Apollo Federation schema stitching, just to let you know that schema stitching has like changed a lot, a lot, a lot, a lot. And I'm putting it here. This is like, I think the most important source out there today for doing those things. And in my talk in the conference, I'm talking about why and why is it important.

So, basically this is like how to run a gateway that merges and stitches, multiple running GraphQL service. So separate instances. So think about it as GraphQL service, but you don't have control, right? That are out of your control. How do you merge them together into one endpoint and run them? And how do you, you know, update them while you're running, like whole schema reloading? How do you do the merging? There's many different ways of merging it. I'll just show you where GraphQL, I'm just gonna mention a bit briefly and then we're gonna go into questions, but let me see schema stitching, type merging, basically, how do you take multiple remote servers and you merge them together? You can do it with code or you can even do it, if it gives an explanation of how it works in execution and it's still being fast and still being performant. Let me see if they have directives here. And how do you declare those merging strategies also declaratively with directives? I'm not gonna talk too much into it, but if you have questions about it, then I would love to answer. So I think that's it, I think for today. Now, there's more things that we want to add for the workshop in the future. But you can do today, like you mentioned, how do you pass headers and authentication, different ways of merging like that, maybe here using directives, how to live reload the services, showing more handlers. I think this is a good start for a lot of things. So, maybe now we could go into questions and then I can show you more, according to the questions. Let me just stop the sharing of screen. Yeah.

I have a bit of unrelated question that I was wondering for a second. We saw the kli tool that you added to the packages. I was wondering, this is for example, you could generate the schemas, or to generate the type, sorry, you would run a command on the terminal, right? To generate... Ah, yeah, so yeah, like, oh, maybe I didn't show it. So in the package JSON, by the way, of each commit, you can find the commands that you need to run. So if you want to run it as a SDK, then you have a command like generate SDK or something like that, wait, I'll tell you exactly. Mesh generate SDK, yeah, so that you can send a flag for it, like where to output the generated code or something like that. So that's one command for mesh. And then there's another command, and again, in a separate mesh, the runtime package that you can run mesh serve and that will actually run mesh as its own server. And regarding this, so this is like our curiosity, what is the Klee running underneath? What is it using for parsing the commands or for analyzing the code, like for parsing the code and for generating the code? You mean the command line? What do you mean? Like, a tool that does what? I'm not sure what I understand. I think it's a GraphQL. Well, I think it's basically the GraphQL server being a spin-up there. Ah, what GraphQL server is like running the whole thing if we're running it as a server? Yep. Ah, a good question. So it used to be, because it's actually changed this week. So it used to be Express GraphQL and we just changed it to GraphQL Helix, the library that I referenced, I put on the chat, because we think it's much better. Yeah. On that note, in terms of performance, I mean, I choose Express GraphQL just because, you know, to a small benchmark that I found, well, actually a few of them, Apollo server is a bit slow when the throughput is a bit high. So I guess the server in terms of performance is ahead of Apollo server, but is it ahead of Express GraphQL server as well? So, GraphQL Helix, it's a good question. So GraphQL Helix, so first of all, yeah, you're right. Apollo server, and I hope more people would know about it, is basically, it's slow and it's outdated. It's because it's unmaintained to be honest. Like they don't put the time there. I used to work in Apollo, by the way, and for many years, they're not updating that library, so it's the dependencies are up to date. And like you said, that performance are not as good and they merged a lot of different things. So it's okay if you have a framework that puts everything together, as long as you keep maintaining it. If you're stuck maintaining it, all the different dependencies are getting out of date. So that's Apollo server. Now, Express GraphQL I agree is better, but then Express GraphQL is also not the best maintained. The thing about GraphQL Helix is that it separates the schema parts from it, then from the web server. So you could use GraphQL Helix with Express, you can use GraphQL Helix with Festify, you can use GraphQL Helix with the Coa or whatever you want. And in my opinion, and not only it's very slim and very fast and not putting, like it's extremely fast. Like you can, all the benchmark that you saw probably from Ben Awad and stuff like that, like GraphQL Helix will be added there and will win like or basic because you could put that with let's say Festify or put it with GraphQL JIT or all the faster stuff. And also what's best about it is that you could just use whatever version of GraphQL of GraphQLJS you want including the experimental stuff. So that means that you could use now defer, for example, and all the new stuff. So I really highly recommend it and we just switched to this library internally in mesh and in our own applications and with clients highly recommend. I'll definitely try that out. We were still in early stages, so I think now it's the time. And follow Daniel the guy who wrote it. He's like part time Guild and part time other stuff and is very smart guy. So yeah, you can follow him and there's a lot of cool stuff happening now. I sent a link to the blog post like you can just follow our blog, we are constantly updating things there and just read through it. There's a lot of stuff that people sometimes miss. Yeah. Thanks. I have a question. So let's say I wanna run the mesh sort of on production. But I also wanna have like logging or set metrics to Grafana or Prometheus or enable tracing. Yeah. So how can I do it? Yeah, so you can just define whatever middleware you want and you have hooks as well. You can like hook into the life cycle stuff. What we are wanting to do now so you can do it. And again if you don't find it in the docs, just send me a message. What we're trying to do now it's not, like you shouldn't care about it. But for us is we care about is that doing open tracing today with GraphQL is weird. You need to like kind of like override the execute function and all kinds of weird stuff. We're now working on like a new thing in the spec where you get lifecycle hooks directly into the GraphQL execution. So then it will be extremely easy to add whatever you know, tracing solution you want. So again, it's possible, but internally the solution is in our opinion a bit ugly. But we're working on something even nicer. But when I say ugly, this is for any GraphQL server, it's not related to Mesh specifically. So yeah, it's a good question.

I have a question about subscriptions. Does it also handle subscriptions? I'm more interested in communicating directly with Kafka or Nats or Redis or something, not with another GraphQL.

Great question. Let me send you also a good answer for it. Just listen to it again. I found the blog post about it, but it says that it will come with another blog post. I didn't manage to find any example. Which? You mean this? Let me unquote the blog post and tell me if this is the blog post you mean? Yeah, this is the one I found and somewhere. And you want an example with Kafka? Yeah, Kafka, I don't know if there's something else. Okay, so we can edit, it's the same idea. Like, we have, yeah, I guess we didn't, we just have one subscription example. But yeah, we'll just have Kafka because we have it internally with clients. So if it's urgent, you can also just message me and I can help you set it up. Actually, the coolest thing would be if you can set up an example of that, and I just, and then we can just, we can just come and PR your example and then you would know it and everyone else would know it as well. And we'll have a public. Sure, okay, okay, thank you. Yeah, but that's a good question and just to expand on it to everyone else, GraphQL doesn't only have queries where you send something and get data. It has mutations, which is like RPC. Like I want to, you know, activate the function, like, you know, for example, like a POST requests, like I want to change something. So this is called a mutation. And the interesting thing in GraphQL is that you can send a mutation and you attach a query to it. So you get back a result, exactly like a query, which is a very interesting concept by itself, but there's also subscriptions. Subscriptions, maybe I'll also link another talk that I gave that are giving like a more overview on it and with a lot of really visualizations and stuff. So, wait, let me find it. So GraphQL subscriptions is basically the idea of, you can also do PUSH, meaning like you could, like you could subscribe to events. Like, for example, every time I messaged Reddit, I want to subscribe to a certain, to get a certain information, like as a PUSH or real time, you can think about messages, a chat app, or something like that. You can still use GraphQL. Like, GraphQL is also good in that. I don't know how much time I have, so I won't dive too deep into it. But I'm gonna send a talk that I gave a very long time ago about this subject. There's a whole, by the way, list of talks there, that I think would be interesting for people. But, so the idea, again, you can subscribe to events and get real time pushes also through GraphQL, and you can attach a query to that as well. So you can say, every time a message happened, I want to get this information. So that's a GraphQL mechanism. But again, with GraphQL Mesh, we can take other different types of sources and convert it into GraphQL Mesh, meaning we could take Redis events or Kafka events or whatever other queue system you want. We could take those and we can consume those events as if they were GraphQL, which is very, very interesting. And for me, probably one of the most exciting things about GraphQL Mesh, because one use case that we actually work with Kafka specifically with a client is that it's like a machine learning or like a data pipeline service. And they want to basically listen to a couple of events. Then every time that those events happen, they want to enhance the data and reach the data, a call to different other sources, get those data and then start processing. And until now they basically did all these codes manually, they went and subscribed to an event and then went and wrote in SQL query and then called an unrest endpoint and then got all this data together and then started to work now. They're just using graphical subscriptions. They subscribe to an event and they send a query and that query is part of like many different other services that are not GraphQL at all. So they just subscribe to an event, get the query and start the work. So it's all running as an SDK on that data pipeline service. So it's extremely interesting and yeah, we definitely need the Kafka example. So thanks for bringing that up and actually working together on that. Like if you can create an example that for your use case and we can like, you know, and we can like contribute and like make it work, it will be really, really helpful. So thanks for that. Thanks. More questions. I think we have still have a bit of time. I was just thinking, so for example, in a scenario where you have a bunch of microservices, which are REST, you know, REST services, and all of them have Swagger. So it's, you know, we can use mash to generate, to generate all the GraphQL types for it. And if I'm using mash server to actually serve all those microservices as, you know, a GraphQL endpoint, and then I have a web app that will use those services, but also exposes his own back end for front end layer as GraphQL. In that case, I would need to have GraphQL query in GraphQL, right? From the server. Okay. So, wait, let me. I just, some of it I missed, so maybe. So what you're saying, I have a number of different microservices. Some of them are REST, some of them are GraphQL. And then, a lot of them are REST. Yeah. Yeah. And then I have a web application that on the backend consumes those microservices? A web application? So it's like a BFF or something, right? Like a backend for frontend. Yeah, correctly. So my client from the browser, it calls the Node server, the Node server calls the microservices. Yeah, yeah, yeah. If I use mesh server to get all those microservices as a GraphQL endpoint, then I guess that my client from the browser does the request to the Node layer. And then from the Node layer, I will need to do queries for that GraphQL endpoint. No. So good, and it's almost the same. Great. And if you would use, by the way, just Apollo Federation, it's probably they would tell you yes, but that's one of the things that... Well, the answer is not no, is like if you want to. So with GraphQL Mesh, what I just showed you now, the first step that I showed in the, like the first commit that we had, that's basically the setup. You have a GraphQL BFF Node Server, and that calls not an endpoint, an SDK. So there's no reason to go through two endpoints. That SDK is running on, as part of the Node Server code, and calls directly those, those services. So there's no reason to have two endpoints in my opinion. Yeah, I mean, if we need to handle authentication on the, on the backend of the web app. Yeah, it's the same. So it's the same thing. I just didn't edit it into the example, but again, it will call the authentication and it will just pass it to the SDK. And then again, you can, you do that. You create, in my opinion, let's say, if you have it already today, start using that SDK today in this node server to replace the REST calls. It will delete a lot of code for you and make it like type safe and all those things. And just like we've done now with the, with the, with the workshop, you can step by step start replacing code from your node server, integrating into the SDK until at the end of the day, you can get an app if you want. You don't have to. Then just basically the node server itself will be mesh. Will be GraphQL mesh.

And all the logic will be part of GraphQL mesh and GraphQL mesh will be the thing that runs the circle. Yeah. Yeah. That makes sense. Cause in that case I can call, call the GraphQL directly from the client. Just, yeah. Just weird that then all the envelopes on the node layer will just go away. Yeah. That's the thing. A lot of code will just be removed, but it's the same thing. And it's also why you can use mesh in many different ways. You could have a central internal gateway that meshes all of those things and then you call it directly. Then from this, you call all the rest. But not necessarily you need it. And another thing is you can take all this mesh and all the amazing things we just created and run it as an SDK on the client and remove the node server completely and the client will call directly the microservices. But then again, then you like it's... If you already have a node and a BFF and you have the performance benefits of GraphQL and everything, there's no reason to do that. But a lot of people are starting to use GraphQL mesh on the client before they have it. Like they use rest everywhere and they want to use this nice option and they could use it as an easy way to get into GraphQL basically. And then when they're ready they take this SDK and run it as a BFF or a gateway or something. Yeah, I'm just thinking that, if we don't do the round trip to go to the server and then from the server calling the GraphQL endpoint, I think other security concerns will raise because at that point your GraphQL endpoint will be somehow available on the client at least the information out to get data from it because you'll trigger requests directly from the browser, right? Wait. Again, I didn't get it. So you have now Node, this Node server that basically does some authentication before you go and call the microservices, right? Yeah. Correct. Mesh is the same. I just, people ask it, ask it, but like I showed it before, you can just do the same logic in GraphQL Mesh. I understand that my only concern is that if I do the request from the Node, then the location of those APIs or dozen points are completely obfuscated from the client. As if I'm doing the requests directly from the client, the GraphQL, it expose- Yeah, yeah, yeah, yeah, no. Again, like the idea is to use it directly as an SDK on the client is if your rest services are public now, meaning like you have a client now and the client goes calls rest, doesn't even know what GraphQL is. So in that case, your rest endpoints are already like secured. But in your case, if let's say you're one step further, you have a Node gateway that calls those different services and the authentication part happens there, that mesh just replaces this, and on the client they just send GraphQL queries, they don't know what GraphQL mesh is at all. Yeah, that makes sense.

Question about error handling. So let's say we have several sources, one is, I don't know, Open API, another one is let's say Drift, and the third one is, for example, gRPC. So, they are throwing different types of error. So HTTP errors, Drift errors, does mesh do anything to sort of consolidate those errors? So, if I'm using, let's say, the SDK, I don't care what's the transport protocol was actually used, but I have the errors in the same shape. So I can write one error handler and it will catch all the errors. It doesn't matter which protocol was used under the hood.

That's a good question. We don't have something out of the box. We have, like, custom handlers that we write in, the custom transforms that we write for clients do that today. But, it's a good thing. I mean, it's also a question, it's also a bit of, like, once you go open source you need to figure out one good answer for all use cases, which is hard. So that's why we just leave it to you. But, so we don't have something that automatically does that but it will be interesting. Like, for example, if you have a use case like that and you can create, like, an example and then we could iterate on it. Like, what will be the best way to, like, convert it? And if you could do it in public, like, as an example app, it would be cool because we could collaborate on it. And then, I think we also would bring a lot of questions because, yeah, errors in general in GraphQL, there's a lot of questions there. Like, what's the best way to do it? And, but it's mostly also because there's many types of different errors. Like, even if we put, you know, the protocol of the technology aside. So it's, maybe it's a good idea to actually, like, create an example to try to, like, demonstrate as many types of errors and how, and maybe find an answer, like, one good answer for all of them? We'll see. Yeah, I'm up for trying. I'm thinking like, GraphQL can represent the data from different types of source in the same shape. You don't really care. So why not do the same for errors? Because errors are also the data at the end. They might be... Yes, it's true, but there's also different types of errors. I think, like, with different needs. And some of them, you can think of them as data, and some of them, you can think of them as network errors, and some of them is just a failure without... So yeah, it's a question of how to represent it. There's a big question in general, how to represent errors in GraphQL. And that question is hard, because there's many types of errors. Some of them are product errors. Some of them are data errors, and it's also the product itself should have the choice of how to respond to different types of errors. So if you dive a bit deeper into that, you see there's union options, and then there's error paths, and all kinds of different techniques, and a question that I believe that the product needs to decide sometimes. But yeah, it's good to have at least some defaults, I think maybe that's good. I think it will, yeah. Because I'm thinking, let's say someone is using the SDK generated by another team, they don't really know what's the protocol used by SDK, so they put try catch around the await, but they don't really know for what kind of errors they, what kind of error they can catch. Yeah, true, true. It's completely obfuscated, which is really cool, because SDK doesn't... So the question is if you are, well, so if you have this in the schema, all the types of errors, and you can represent it in a good way, then yeah, I think it will be interesting. But yeah, I want to see more use case. It's possible, I think, yeah. Yeah, I think if we can give you one, if don't mind like setting up some, a couple of examples like of this, it will be really cool to like think together about it. Like we don't have anything automatic now, but it's, yeah, I can think of all kinds of different ways of looking at it, so looking at examples will be cool. And I think it will be valuable for everyone as well. If you don't mind, if you have time, then let's do this. Yeah, I do have in my agenda to check the mesh as a SDK, because we have our own in-house built SDK, which also does this error handling, a generic one. You don't really care what's the transport protocol, you just have some generic errors, so I will try to do it with mesh API. Let's see what comes out. Yeah, yeah, it sounds super interesting, thanks. It's really cool, would be cool to compare SDKs. It's pretty nice. So our SDK is very opinionated and really built for one use case. So you cannot compare it, but I will try to rebuild it with mesh SDK, so. Cool, thank you. More questions? I think we have like a minute or so before it ends, but feel free to ask. I just want to say thank you for your time. It was a great conversation we had and it was very nice getting all the questions answered. You definitely gave me a lot of, gave all of us a lot of context on it, a better understanding. Thank you for your time. Thanks, thank you very much. It was great. Thanks. And like, again, feel free to reach out. I'm always available and we always look for more use cases and more questions. And like I said, there's no stupid questions. All questions help us understand better what people need from the open source. So yeah. Really feel free to contact me on anything, it could be my email on my GitHub or through the Discord that we have, or just the chat on our website that I showed you. Yeah. So if there's anything else, I think I'll close here. Thank you very much. And yeah, there's... This is just like one thing and there's my talk on the actual conference, which I hope you would like as well. I talk there about more things. Yeah. So thanks for staying and listening. And see you soon. Thanks for the work. Thank you. Bye bye, everyone. Yeah.