Learning GraphQL: from curious to confident

Welcome, once again. Thank you so much for joining me this morning, evening, afternoon, depending on which part of the world you are joining us from. And as Agatha says, we do have a fairly international crowd joining us today. So once again, thank you very much for joining me.

Today, we are going to be learning all about building and managing GraphQL APIs. So essentially this workshop is going to be about learning GraphQL and going from curious to confident over the next two and a half hours. And what does that actually entail? We are going to be during this period of time, we're actually going to be building out a few APIs. We're going to be managing that using Tyke. We will go into the details as we move along.

Before that, a little bit about me. I am Budha, I am a Product Evangelist here at Tyke coming to you today from Boston US. So that is me, I am working for Tyke. We are a cloud native API and service management platform. A little bit more about us in a few slides. Before that, let's talk about what we are going to be doing today. We are beyond the introductions. We are going to be looking at building out a GraphQL endpoint with Express GraphQL. We will be working to create a very simple GraphQL endpoint and run it on a local machine. We are going to be securing our newly created GraphQL endpoint with Tyke. We will be adding a few security features. I will talk you through some of those. Essentially looking at the entire lifecycle management of your GraphQL endpoint that we are creating today. Finally we are going to be doing something really exciting. We will be looking at building a similar endpoint with Tyke's universal data graph. This is the no code version of what we are going to be doing using Express GraphQL. That is what is on the agenda for today. Without further ado, let me tell you a little bit about, this is the company that I am working with. We are a cloud native solution, cloud native API and service management platform. Essentially, we are powered by our low-latency open-source API gateway, which is essentially the brains behind the operations. Together with our really beautifully designed Tyke dashboard which is essentially a user interface in terms of interacting with all of the different capabilities of our Tyke gateway. Then we have our developer portal which enables you to expose and publish the different APIs that you would have for consumption by third party developers as well as partners. Our API gateway is capable of handling REST, GraphQL, and gRPC APIs. Today, we are obviously going to be looking at a subset of that, we are looking at GraphQL and we support that in many different ways, some of which you will be seeing today, specifically, around security where we talk about not just at the endpoint level around authentication authorization, we are also gonna be looking at rate limiting our endpoints, we will be looking at query depth limiting as well as field-based permissions, so very very specific to the data layer of GraphQL. And then finally we will be looking at the universal data graph where we will be combining REST endpoints, a couple of REST endpoints that already exist and creating a GraphQL endpoint in no code manner in a very very simple and quick way. So, that is who we are, that is who TAIK is, let's dive right into the introduction to GraphQL.

Now some of you might already know this, this particular workshop that we are going to be running today is really for people who are slightly new to the world of GraphQL, they haven't really built much of GraphQL APIs, maybe you have tinkered around a little bit but haven't done a whole lot, much more than that, but you have had… you are being curious about GraphQL for a little while, so hopefully we will satiate that curiosity today and hopefully build a little bit more confidence with some context, with some knowledge base, with some hands-on sessions as we move along, and that will enable you to build your own GraphQL endpoints and write your own queries and your resolvers as we move along.

So just to quickly introduce GraphQL, this is the definition of GraphQL as mentioned on the GraphQL org. It is a query language for your APIs. Now, what would that essentially entail? We are looking at GraphQL, which was created by Facebook. It was developed internally in 2012 with Facebook, and then that was publicly released in 2015. It was built for omnichannel products. Essentially, that was kind of the use case that Facebook used to introduce or build or create GraphQL. They were introducing, they were essentially jumping, diving into the world of omnichannel products, and the efficiency of building them using REST endpoints was proving to be quite a lot challenging in the early days of Facebook. And therefore, they created GraphQL, which is essentially a flexible way that caters to the needs of multiple platforms with varying needs instead of just creating multiple APIs that are really, really focused and tailored to just one particular thing. The challenge there obviously is that, as your distribution channels essentially expand, if you need to build your REST endpoints specifically for each one of those different platforms, then that could essentially build up really, really quickly and it becomes a lot more difficult to manage, especially when you are really working out of a common data base that essentially you're working out of or data source. And then finally, it gives you exactly what you need. There is no concept of overfetching. There is no underfetching of data. It is very, very specific. You query what you need and you get back in a very, very predictable structure what you or your platform essentially needs to consume. So this is again, one of the big selling points, as we say in the world of GraphQL.

Now, moving on, this is again, a very, very typical conversation. Every single time that we talk about GraphQL, there's always a question around REST versus GraphQL, or which is better, which is worse. I think simply put, I believe, I have to say I believe in this case. I'm of the camp where I think both have their place in this world. Each of them has their own benefits. Each of them has their own drawbacks. These are essentially tools. And tools usually are important only in the context of the problems that they solve. Now, if you take REST, REST are again, they are very, very focused on resources and how you would create a request. You get back a response. There is an endpoint that you work with, slightly easier to secure, slightly easier to manage. There are cache mechanisms that will essentially be useful. There are status codes that are dedicated to REST end points. So in that sense, REST can be fairly easy to get started with, but it does have its own drawbacks where there is a distinct lack of flexibility that could come in to REST, especially when you're catering to an omni-channel sort of product distribution mechanism. You can then, therefore, become a little bit more prone to over-fetching of information or under-fetching of information, again, depending on just, if you're asking a request exactly what you need, then that is fine. With the use case that the REST endpoint was built with originally, if you're just catering and tailored to just that, that's perfectly fine, but as soon as things start deviating, things can become a little challenging as you move along. So GraphQL again, comes in to solve that particular challenge where you have this level of flexibility where the consuming application of the front-end developers essentially have that power to request exactly what you need or do exactly what you want, depending on the kind of front-end platforms, so kind of consuming applications that you're looking at. A similar example of this is essentially if you look at, well, I'm looking at the weather at the moment. So if you look at a weather application, for instance, the requirement of a weather application, the data requirement of a weather application on a desktop versus a mobile device versus a wearable device can be very, very different.

And what you want to avoid is essentially having a single REST endpoint that is being called across all of these platforms and half of the information that is going to the wearable devices essentially underutilized because you don't need all of the information. You're not going to display all of that information. That is where graph QL sort of shines out here where you can have that common base of or a schema as we call it in GraphQL, which we'll talk about in a little bit.

You create the schema essentially with all of the different fields that you want exposed, all of the different data points that you want exposed. And then that can be consumed specifically based on the kind of platform that is actually making the request. So that does enable a lot of flexibility, but that flexibility also brings with itself a little bit of a challenge because with that flexibility, essentially, the onus is on the consuming application to essentially use it in whichever way you want, which means that the structure of the queries, the depth of those queries and what order of that query is gonna be is slightly unpredictable. It's a lot more unpredictable in that matter.

Of course, now it is predictable in terms of the way you would query information and receive information, but you as a developer of the backend resource may not have total control in terms of exactly how the frontend application is actually requesting that information, can be requesting in many different ways. So you need to be careful specifically around security in this case, where you need to have the power to essentially expose the different fields that you want to be exposed depending on the kind of users that are gonna be using that application. And to take the point even further, you're also looking at things like multiple depths or multiple layers of depths when it comes to making those queries. So you can go deep, there is really no well-defined limit in terms of how deep you can go with these queries. You can have nested queries within GraphQL and that can again cause issues around server load management and sometimes these can be required but sometimes these can also be malicious. So there are a couple of challenges because you're no longer just working at the API endpoint level. You're not just working at that HTTP level which is essentially what REST does where you obviously need to have an authentication authorization there but you also need to think about what's going on at the data layer as well where all of your queries and the requests are coming from. So, there are a couple of different challenges there.

Again, it doesn't adhere to the standard rules of your status codes and errors. Typically, you can have errors even with a status code of 200 which is again, something that can be a bit of a challenging thing to work around. But again, because it is flexible you can write your own custom error objects and you could provide a lot more information depending on what your use case could be. So there are positive, there are negative. So I think the mantra here is to ask the question that you, the question that you really need to ask here is, what is my use case? And what are my priorities? Each of these tools, each of these, well, API styles have their own positives. Each of these API styles have their own challenges. So which of these challenges are deal breakers for you? Which of the use case are you really, really focused on? And depending on that, you can make a choice. So either one of these essentially could work for you depending on your use case. It is not a question of GraphQL coming in to replace REST. Essentially each one of them have different problems that they can, they are really, really good at solving. And you should ask which question or which problem that you're gonna be, that matters to you, and therefore pick a solution accordingly. So that is a little bit of a gist around GraphQL. A quick introduction into the world of GraphQL.

I want to also introduce a couple of really, really simple GraphQL concepts, which essentially would help you to understand further as we start building out our solution. So what I've done here is I've just taken this schema. This is essentially the schema that we are gonna be building based off of. So this is gonna be the end result of the Express GraphQL app that we're gonna be building over the next hour. So let's start with defining what a schema is. A schema is essentially in GraphQL, a schema is essentially the blueprint of your API. It defines all of the different types, all of the different kinds of things that you can do, the different actions that you can take, the different data that you can request. So that is essentially the blueprint of your entire GraphQL API. Now, beyond that, if you see here on top, you see something called type mutation, you see something called type query. Now, if you go back to the objectives of APIs, you look at perfoming CRUD applications, the C-R-U-D, which is essentially create, read, update and delete. These are the basic tasks that you want to accomplish usually with your APIs. Maybe one of them, maybe all of them, depending on what you want to accomplish. So in rest, you would have something like get requests for your requesting information, reading information, your R within the CRUD, creating, probably making a POST request, updates could potentially be patches, maybe even puts and delete, could be just delete. So in a similar vein, essentially, we have our two different types here, which is essentially querying and mutations. Queries, typically, are meant to request information, as the name would suggest. Now with queries, essentially, this is the structure that you will see, you define the kind of actions that you can take or the kind of information that you can request, and queries will help you accomplish it. Now this is by far the most utilized aspect of GraphQL. Mostly, this is kind of the request that is made. But beyond that, we have what you call is mutations. As the name suggests, mutations essentially is manipulation or changing or modification of data at your data source. Now that would include adding new information, adding new data to your data source, that would include updating data to your data source, or it could be about removing information from your data source. In today's example, we'll be actually looking at how you could add a user. But perhaps as an exercise, when you go back and try it out yourself, perhaps you could also explore how you can update and delete information as well, as maybe when you try and practice these things yourself. But, so those are kind of the big two. If you are starting off with a schema, this is essentially where you would start off, this is kind of the objective of essentially building out your schema. You're either trying to enable people querying your information, querying your data sources, or you're trying to enable people to actually make changes or modify those data sources. So queries and mutations. There is a third type here, which is subscription, which is essentially a listener. You can listen for changes to your data source, but for the purpose of today's conversation, I'm gonna leave out subscription, but do feel free to read up on that as well. There is gonna be an exciting new update that I'll be talking about maybe in a month's time, so stay tuned for that. But subscriptions, again, unlike what you would have with your basic REST operations, subscription comes pretty much built out, built in to GraphQL, and it's a mechanism for you to listen for specific events, or listen for changes, for example, to maybe user information, maybe changes to if there is a new to-do list that is being added, then maybe you want to be notified based on that. So that's what subscriptions do. But we'll stay focused on queries and mutations for the purpose of today's demonstration.

Now, beyond that, if you look at it, the very, very, the, what do you say? The building blocks, the essential building blocks of your GraphQL schema is, or are, your types, your types and your fields. Now, if you see an example here, you've got your type to-do, you've got your type user, and within these types, these are essentially objects. These are objects that are defining the different kinds of data, data that you can, different kinds of fields that are come together to provide the information that you need. They usually have a correlation to your data source behind the scenes, as you will see in really, really shortly, but they're also defined by, these fields have types associated with them. So these are what you would call scalars. Scalars are essentially built out of GraphQL, again. So you have some basic types that are already provided by GraphQL. You have your int, you have your strings, you do have a Boolean as well. And then further on you can also have lists.

So if you look at these square brackets, they are essentially a list of information. It returns an array of information for you. Further inspection, you can also see, you can also have these custom types over here, which is your users. You can request information from the objects that you have built yourself. So instead of just using integers, or strings, or Booleans, you can request for information based on the object that you have created.

Again, we will go through this process of creating each one of them as we move along. The other thing that you might notice here on top as part of the query, is that there is such a thing as an argument. So this is essentially an argument, which is, which your queries gonna be taking in. So in this case it is, getting a user to do, or it could be about getting a particular user. And here, you would fill in, perhaps the ID of the user that you want the information for. This is an argument, this is how you would define it. So this is sort of a brief summary of how a schema looks like. This is the brief summary of what you can do with a GraphQL to begin with. It's kind of an overview. We will go into further details as you move along.

There are a couple of other things that we, I think it's better off shown rather than spoken about, but hopefully this gives you a bit of a sense of what a GraphQL schema looks like, a typical GraphQL schema would look like, and what some of these different elements that you see would look like. Again, the ordering over here doesn't have to be the same as yours. I think there is no necessary order in this case, but typically, you would, your types, the basic types are essentially what you start off with, and then you've got your queries, which would be what's exposed for requests that would come through your GraphQL playground or whichever client application that you might be using. So your queries and mutations are essentially your entry points, and then that goes through to your different data types inside.

So all right, let's move right along. Let's talk about what we are going to be building today. This is the exciting part. So what we are going to be building today is essentially a simple application. We are going to be using Express and GraphQL. We're going to be building two data types, essentially. One is going to be users. One is going to be to-do. So it's essentially an application that handles to-do information based on users. So that is essentially what we're going to be doing. There are two different data types that we'll be working with.

We are also going to be looking at querying information, which is just requesting information that you have, requesting information of the user, requesting information of the to-do list of that user. But also, we're going to be looking at mutations where we are going to be looking at adding a new user and what that would entail.

Now, one other component that I haven't spoken about so far is what you would call a resolver. Now, each of these different fields, some of them are simple. Some of them may require a little bit of a calculation or computation involved. So you create a function that resolves the requirements of that particular field. A case in point would be, if you go back to our schema, a case in point would be, if you look at all of these different queries, then what would making a query to all of the users here, what would that mean? What should this respond with? What should the response look like? That is essentially handled by a resolver. It's a function that essentially computes your request and provides you with the response. So that is what a resolver is. Again, we'll be building all of this as we go along, and we'll see that in action. So hopefully that will clear things out a little bit more.

So further to this, how we are going to be building this, as I said, this is going to be using Express GraphQL. What you would need is having Node or NPM installed on your laptop, especially if you're going to be following along, which I would recommend. I think if you do have these prerequisites met, then I would recommend you to actually follow along. I think that will go a long way in terms of building out your confidence, if you can do so. Because again, hands-on is definitely a lot more different than just looking at me or looking at my screen, which is perfectly fine as well. But I think if you do wish to get that little bit of a taste of building something of your own and then playing around with it in the future as well, then this might be a good option to do so. So as I said, there is a bit of a prerequisite here where you should have Node installed on your system. If you have not, then please feel free to do so. Right now, I think it is in nodejs.org if I'm not wrong, and install Node on your system. It would probably take you just a couple of minutes to do so. Additionally, you need to have some form of a terminal to run your commands. On Mac, of course, it is terminal. On a Windows machine, you can use your command line or maybe PowerShell, if one of the two is your go-to option. But feel free, but you do need a terminal to essentially run your commands and ideally an ID as well for your coding. So, this could be a text editor as well. But an ID could be beneficial here. I'm gonna be using Visual Studios. But if you have any other choice of your preference, any other preference, then feel free to use that on your own. Additionally, we are also gonna be using something called ngrok. Because we're gonna be building this out locally today, we want to expose this out for consumption by Tyc. We are gonna be creating a Tyc Cloud Account in the second half of this workshop. And in order for that to consume the API that we have created, it'll be good if you can expose that API for public consumption. And ngrok is a way to do so. Essentially creating an IP tunnel for consumption externally. So, if this is something that you are unable to do, I will give you an example of already publicly available API that you can also use to essentially perform all of these different things that we're gonna be doing. It's essentially the steps that we're gonna be taking at the Tyc API management level can be utilized across any endpoint, any GraphQL endpoint that you want to use. So there are a lot of publicly available examples. But if you want to use what we are gonna be building today, then we will need NGROK. But don't worry about NGROK so much at the moment, we will install that in the second half before we get started. But for now, I think if you have Node installed with a terminal and ID, we are good to go.

Okay, so let's go ahead and build our GraphQL endpoint. So I hope you can see my terminal. And I think it is large enough that you can actually see what I'm doing, hopefully. Okay, so with that, let us begin. I am going to head on forward to my working directory. I mean, start off with a... And inside here, I'm just gonna be quickly making a new directory. So just feel free to follow along at the moment. I'm gonna take these steps really, really slowly so that I don't rush through it and you can follow along. So I made it sufficiently large enough. So first step is gonna be... We're gonna be creating our working folder, so which I'm gonna be using make directory. Gonna just call it Galaxy demo 2021. That is gonna create my directory. I'm gonna head right on over there. So this is gonna be our working directory. Now if you have node installed, now hopefully you do have that. So next step is essentially initializing our node project, gonna be using put in it.

I'm just gonna be using everything that is default at the moment. So I'm just gonna put in a dash dash yes, so that just goes ahead. But you can just step through, if you want to all of the different steps here. So you can customize, you can essentially change these at the start, but we have access to the actual package or json file which we can make changes in as well.

So I'm not gonna bother with that. So with it, I think it's sort of here. Now what I'm gonna do is I'm actually gonna switch over to Visual Studio Code, VS Code, and I'm gonna open up my folder here so that I can just work off this. We have our demo here. This is gonna be my working directory and the good part here is that I can open up my terminal here as well, which is what I'm gonna try and use from here on in. It is essentially at my project level. And in case you were wondering, we do have our packages on right here. So if you do want to make any changes to this eventually, then you can do so as well. But for now, let's get started here.

We need to install a couple of other things. So once again, follow along. Let me see if I can make this just a little bit larger. There you go. Hopefully this is a bit more visible. We go with npm-install. We're gonna be installing express. We're gonna be installing express-graphql. Just one moment. Okay, express-graphql. We want to also install graphql. And I think I'm gonna save this dependency. It's gonna take a little bit of time. And there we go. We have added our package. And if you see on our package.json, now we have our express-graphql as well as graphql installed here. So, this is done.

I'm gonna be using one other utility, which is called NodeMon. Essentially what it does, is it quickly updates and restarts the server every time I'm making a change on the code. So, instead of me having to manually update and restart my server every single time, it would do it on my behalf. So, this is quite a useful, valuable tool. So, I'm just gonna use, make use of that at the moment. So, that is npm install NodeMon. Again, this is a dev dependency. So, I think I can do a save dev on this. And there you go, got NodeMon here.

One of the thing, now what I'm gonna do next is, I'm gonna create my entry file, essentially. So, again, for the purpose of simplicity today, I'm gonna be working with just the index.js. But of course, code can be split out into multiple folders. It can be split out into multiple organizational structures, which I'm gonna leave it to you to do so. But just for the purpose of simplicity today, I'm gonna be working off of the index.js file. So, with that, I've just created my index.js, and with here what I'm gonna do is I'm gonna start adding my code here. So hopefully everyone has managed to, if you're following along, you've managed to sort of follow along so far, these steps are straightforward enough. If you are stuck at any point, please feel free to put that in the chat. Because of course the further that we get, the more difficult it's gonna be to follow fall back on. So if at any point of time, if you have a question, feel free ask pretty much immediately if you can, I've got my chat box here as well.

Okay. I'm assuming everything is fine. I'm assuming you've got to this point where you've created your index.js? You have all of your different packages and node modules that are necessary, as we mentioned before. So here on in, we're gonna be starting off with heading on to adding the code. Maybe one other thing that we can do before we do that, you could do this a little bit later as well, but what I'll do just for the sake of finishing off my package of JSON perhaps is that if you look at this script section, I'm gonna do is I'm gonna change this to start and I'm gonna change this to be node-mon-index.js. So what this is gonna do is when I'm about to start the server at the end of my first batch of code, I'm just gonna say npm start and it's gonna run this particular start script at that point of time, it's gonna launch node-mon for me, it is gonna launch index.js and sort of listen for those changes that I'm gonna be making on an ongoing basis. So this is just one of the step. You don't necessarily need to do this. You can just run your index.js using node space index.js as well. But of course, you can use this as a slightly simpler, efficient way to handle this, I feel. So I'm just gonna stick with this.

Okay, with that out of the way, let's move on to the actual coding side of things. So I'm gonna start off with a few import calls. Start off with importing Express first. If you see, it might be giving me a little bit of a challenge here because I think what is happening perhaps my ES6 may not be, already in place but we will solve that later on. So for now I'm just gonna do a bunch of imports we'll say GraphQL HTTP from Express. There's auto completing a lot of stuff for me which obviously makes life a little bit easier for me. And then we're gonna be moving into updates. We have, GraphQL schema. We also need, I think we need a GraphQL string. We need GraphQL object.

I think that is the right spelling of it. Yup. Okay, I think that is a good starting point for now. Hopefully I've got my spellings correct. They'll tell me later on if I don't. So, okay, here we go. So this is what we have to begin with. I think we're just gonna start off with these imports. We will build on this if we need other things that we move along. So for now we can be starting off with this.

Now, one caveat here, there are a couple of different ways in which you can write your GraphQL API using Express as well. So that one way is to use what you call the schema definition language, which is quite similar to what the schema that you saw. You're essentially using that. You're writing resolvers, and you're moving forward. Now there can be a couple of challenges with that. I think if you're just using that, then it is quite difficult to actually... It may not actually be possible to write resolvers for fields within a particular type. You can write resolvers at the root level, each of the different rules that we saw previously, but you can not actually do it for the internal fields that make this within the type. Now, there is a way to circumvent that. You can use ES6 classes to essentially circumvent that, which is another way that you can handle it. But for the purpose of completion, even with that ES6 classes, there can sometimes be challenges around unions and interfaces. So maybe it's another example for a different date. For the purpose of completion of this particular demonstration, I think I'm gonna take the root of creating GraphQL objects, and I'm gonna take a more of a code first approach to today's demo. So hopefully you will follow along with this. There is a really good example of just a quick and simple way of creating your express GraphQL endpoint using the SDL method on the graphql.org website. So feel free to check that out as well in your own time, but let's move along to the next step.

So for this, we do have a couple of steps that we want to do. We start off with a very, very simple hello world application first. And to do that, I'm gonna be starting off with creating my root query type. So let's start with defining that. I'm gonna say const query type. This is gonna be a new GraphQL object type. And this takes a few different arguments inside, a few different things inside, configurations as you will, and give it a name, I'm just gonna call it query. I can give it a bit of a description as well if I want. And this can be, this is, well, this is the root query. And then finally, we can start defining our fields. Then here, now we can start defining fields. Now, if you remember, if you go back to our sort of blueprint that we were working off of, we were looking at users. So let me do some, we were using users, so we're gonna be trying to get there first, but before that, for this particular example, we are just looking at Hello World. So let's start with something very, very simple. This is gonna be a query called Hello. And what this is gonna do is it is gonna be of type string, or in our case, GraphQL string. We would also, we can put in a description here as well, if you want, this can be saying Hello. Then finally, what we want to write is a resolve. So this is where we are essentially translating whatever the request is and creating the response that is gonna go back. So in our case, we are just gonna be taking simple function, no arguments needed. It's just going to return a simple. That's pretty much it. That is all you need to do at the moment. That is the simplest resolver you will see at the moment. We will go into more complex examples as we go on. But for now, we are gonna stick to this. We have a couple of other steps to complete this particular example. And to start off, let's go with, now that we have this. And we're gonna create our GraphQL schema. So this is where we are defining. So if you've created a query, whatever is the information that's gonna go into the query, the resolver that is associated with that query that is gonna request information, the next step is to actually build up our schema. We're gonna be doing that with creating a new GraphQL schema. And in here, we want to have our query, which we are gonna call the root query. Essentially, what we defined right here. And we're gonna be doing the same with mutation when we go along. So for now, this is now our schema has been defined. Now let's start off with our Express app. Express is gonna be equal to Express, that is initializing our Express app. And in here, I'm gonna be looking at creating my endpoint. Of course, you can choose to be however you like. I'm gonna just take slash GraphQL. And I'm gonna call it, sorry, I think I have it inside the brackets, GraphQL HTTP. And within here, one of the brackets has gone awry, but we will fix that. I need to now give it the schema that we created.

And we're gonna use a Playground. so it's just gonna be graphical. Hoping I've got my brackets correct. It seems to be that way, which is fine. Then finally, we want our app listening at 4000 to 4001. Okay my cousin might be busy. And here, just gonna say console. Console. Blob. And I'm just gonna put in a message server, is server running? on oracle host 1001 slash craft run. So, hopefully, that is the last step. And if everything goes well, I'm just gonna save that. I am now gonna start off my server saying NPM start. Hopefully fingers crossed, we will get greens coming up. We didn't. Okay, so we have some issues here. Which is what we predicted. So, because import is an ES6 standard, so I think we just need to fix that. In order to do that, we just go back into JSON. And I think if you see the reasoning here, let's say that you need to set a type module up here. So, I'm just gonna go back in here. I'm gonna call it type, and I'm gonna say module. I'm gonna save this. Gonna head back out. I'm going to start my server. I'm gonna restart that. There you go, we have all green. So now let's test that out. Now, let's test this out. We are on local host 4001 slash GraphQL. So let's try that out. Local host, 4001 slash GraphQL. There you go, so this is the graphical interface that you're seeing at the moment. This is essentially a playground. For those who are not familiar with this, this is a playground where you can interact with your GraphQL API. So basically you can interact with the schema, you can request information and receive your response, which we will see shortly. So I'm just going to get rid of all of that. One thing that you would notice here. On the right-hand side, if you look at it, there is the section called Docs. So this will give you an idea about all the different things that you can do here. Essentially, the activities that you can do here, root types that you have defined. So if I go in here under my query, which is my root type, if you remember. What we have done here is we have listed the lobes. That is the field that we have at the moment. This is what we can request at the moment. Let's start off with writing out a query. Just going to say hello. And again, if everything goes well as it has, we will get a hello world information here. So this is essentially running our very, very first GraphQL API. This is the first GraphQL request we have sent in, first GraphQL query that we have sent in, and this is the first response. Now, you might have, again, you might have noticed if you have seen GraphQL queries being made or you might see in the future, that sometimes it is okay to omit this. In most cases, you end up omitting queries, so it will still work exactly the same way as a query is something that you don't necessarily need to make the query, as you say, but it does need to follow that correct bracket structure. So, okay that was the simplest example to get started with. We are at a hello world point once again. Does anybody have any questions? We have, let's give it a minute or so if anybody wants to ask a particular question or curious about anything else, so far that we have gone, because this is sort of the base of what we're gonna be building on from here on in. We're gonna be looking at slightly more complex queries, slightly more complex types, data types that we're gonna be working with. And then we will be heading into the world of mutations as well. So, if you have any questions, now would be a really, really good time to ask, or if you are stuck anywhere, this would be the time to ask. Okay, so far I don't see anything. So I'm gonna assume everything has been going really, really well so far. You've been following along everything that I've been saying. So, thank you so much for following along. So, let's head back now onto Visual Studio with this initial example out of the way. Keep reorganizing the video as well, okay. There you go. All right, so what we will do next is we're gonna start building out our to-dos application a user to-do application as well. So what we are gonna be doing now is first of all we need to have a data source. Now, for the purpose of this example I'm just gonna define the data source right here but you can just as easily connect your application with a database, whether that is Sequel database or it is a NoSQL database or any other data source that you would like, you can do that as well. Obviously you would need different handlers to manage the database connections For the purpose of simplicity again, in our case I'm just gonna be using a simple array of objects to get some demo information out there. So let's begin with this.

I'm gonna head on and create some user data which is what we're gonna be using. So I'm gonna be using cons-users, sorry, Let me create an array of objects, so each one of our users will have a few different fields. So the first field that I'm defining is gonna be an id. So id is, I'm gonna be heading on to name, which is gonna be of type strings. I'm just gonna call it, I'm gonna give it my own name. And I will have email, let's call it, let's see an email. So my email, as most of you would know, is prototype.io. So this could be our first object.

Now, looking at the data source, looking at what you want as an outcome, you can already start thinking about how you can plan out the creation of the data type. Your data type is gonna have id, name, email. Id is gonna be of type integer. Name, potentially string. Email, potentially string. So that starts giving you a bit of an idea, just looking at the data itself. Now, obviously you can do it the other way around as well, where you define your structure first and then start looking at the data. But in a lot of cases you would find that you have some sort of a data source that you already worked on and now you're looking at building out the query language, the GraphQL side of things after that. So, either way works, but for the purpose of this demonstration, I'm just picking up the data store first. I'm gonna create one other example so that we have a little bit else to work with as well. Let's call it James email. I'm just gonna call it, well, James gmail.com. So with that, that sort of creates our very first data source at the moment.

What we're gonna be doing next is we're gonna be creating a data type. We are gonna be creating the user type. Like we did for the root, we're gonna be creating a custom sort of object here. So let's do that. So in order to do that, we are gonna be following somewhat of a similar structure as we did with our root query type. So we're gonna be using const, we're gonna call it user type. This is gonna be a new GraphQL object type. As we start building this, I would hope that you will start seeing some of these different patterns, the repeating pattern, so that you can just start thinking out or planning out your own project in the future perhaps. And this is sort of help you out with it. So the more we try, more we practice, the more confident that we will get and that's essentially the purpose of this demonstration as well. So let's move right along. Let's go and give it a name. I'm gonna just call it user. Not exactly creative, but let's keep it that way. I'm gonna give it a description. This represents a user. Now, I would want to define my fields, which you might already have a bit of an thinking about, I would imagine, based on what we saw previously. So let's do this. So if you see this structure, we've got an ID, I've got a name and an email. So that is essentially what I'm gonna be defining here. Now, the difference here obviously is that it's not just straightforward. We are using objects in this case. So we're gonna be using, say, we have to define our type, what type of information is expected at the ID level. So our type is gonna be what you call a GraphQL int, integer. So let's define that. Okay. It's way too much information sometimes GraphQL int. Okay. That is what I need. I'm hoping I've got my spelling correct. I think that is it. So with GraphQL int now, the thing here though, is if you think about an ID. An ID for a user, is essentially something of a unique identifier. Now, therefore what it means is that it's something that a user should definitely have. Or at least in this case, I want my user to have. Now, I'll address that shortly, but before that, let me just complete this so that you can see what a basic structure would look like. I'm just gonna, I'm using GraphQL string for this. We're gonna be using the same for email as well. So now, going back to the point of, something like an ID is a mandatory sort of field. It's something that is needed, is important. So you don't want this to be a null value or a null field. So how do we define that? We need, we are gonna be using something called GraphQL non-null. When you wrap that around a particular type, which it means that you are, you need to have a value for this particular field. Again, it's optional depending on your data source but for my purposes, I want to have this, and the way you would do it is you would do it using GraphQL non-null. So that in essence, is my user type. This is essentially the structure. Should look quite familiar to what we had in the data source and essentially mapping just that. So now in our original root query, as I said, that's essentially the entry point, this is essentially what you request.

So now in our original root query, as I said, that's essentially the entry point, this is essentially what you request. This is what you're querying. So we need to add on a means to query our user. So we're gonna be adding something called get users. So the purpose of this would be to retrieve all of the different users that I have in my data source. So let's go about doing that. I'm gonna again, follow a similar pattern here. The expected type, however, in this case, as you could see in hello, we had the expected type to be craft your string, which is a scaler as I said before, in this case, I'm gonna be using object, which is gonna be of type user type. Now, the other thing here is, if you notice we don't have just one user, we have multiple users that we're gonna be using. So what I'm gonna do is I am going to create a new craft QL list. This will return an array of type user type. So that is gonna be the type, this is what is gonna get returned. Now, going out launch, we've got our description, which is gonna be list of all users. Then we will write a resolver.

Okay, so unlike the previous one, this one has a little bit more to it. However, because we are just using a single data source here, which is essentially this array, what I can do here is I can simply return my entire array here. So of course, now you can put in your checks and balances here if you want to add something, but for my purposes, I just want the list of all of my users, and this is gonna do exactly that. So what it's doing, it's just returning all of my users in this particular array, and that should be it.

So now I think we just make sure that I have, okay, so there are a couple of things that are missing, and this was expected, because we have used something like GraphQL non-null, we've used GraphQL list, which we have not defined on top. So list and GraphQL int, all of that has come in automatically. I think VS Code is smart enough to do that, but what is missing right now I think is GraphQL non-null. So I think that hopefully was the only thing that was an issue, and we should be able to move right along. I think we have GraphQL list, we have everything else, okay. There you go. So that is done.

Now let's test this out. I'm gonna head back into my graphical interface. Now I do have to refresh this, things to take effect. As you can see in the documentation, you can already see that the get user query is available now to me. So now let's try that out. I'll remove hello, I'm gonna say get users, and now within that, I'm gonna query for specific information. Now if I were to look at the structure of this, and the user, if you remember, we've got ID, name, and email. Now I can request all of them, and I should get back a response. As you can see I've got a list of information here, so I can request all of the information, all of the different fields that are available to me, or I can request a subset of this, where I can get rid of the email, perhaps even the ID. If I'm only interested in getting the names of all of my users, I can request exactly that information. And this again is the power of GraphQL. So you've created the schema. You've created this data source connection here where you can request all of the different users, but it is flexible enough, based on your needs, you can request exactly what you want in your response. So that is essentially, again, demonstrating a little bit of the power of GraphQL. We have now moved on to creating our own user, which is fantastic. Let's keep building on this. Hopefully you guys have been following along so far and there hasn't been any issues so far, but we'll move on to the next part of this. Now, obviously we've just created a query which enables you to query and retrieve all of the different users that you have in your data source. What we can additionally do is if we wanted to just get one user. So we're gonna do that right now. We don't have to change, we don't have to create any new type because we're just gonna be working on the user type at the moment. So we are gonna be going for just get user in this case. And within this, now, plus I'm gonna be creating the same thing here where there's gonna be a new type. In this case, because it is not a list, it's not an array, we are just interested in one user, where in specific user that I'm gonna be querying based on user ID that I'm gonna be providing the query and the arguments. So my type is just gonna be user type. I'm gonna give it a description, which is going to be just wrestling single user. And then we go on to, well, actually before resolving, we do need an argument. So we're gonna be setting up argument here, which for us is gonna be ID, and ID is gonna be of type int. So this is gonna be GraphQL int. But once again, we don't want this to be null. So we're gonna wrap this. And we're gonna put that. That. So that makes it important. And that is all the arguments that I need. And now I'm gonna head on over to my Resolver. Inside the Resolver, unlike my previous times, I'm gonna be taking in a couple of arguments for my Resolver function. So I'm gonna take in parent, and I'm gonna be taking in my ourts. And then I'm gonna head on over to my function definition. I think I've got some mistake here. A-ha, there we go. Okay, so what I want here is I just wanna return my specific user based on the ID that is provided. So I'm just gonna go to my data, which is my array of users. Users dot find. And in here, I'm gonna take single user that is gonna come in. It's gonna traverse through my users array, take the first object, and from here, it will return to me the single object, which is our array entry, which is gonna map to my arguments. So hopefully, this is not too difficult to understand here what's going on. The resolver function is gonna be taking an apparent and the arguments as the, well, the arguments. In here, we would go traverse through our users, data source or users array, and find a particular user that has the user ID, which is the same as the arguments ID that is being entered. So let's just finish this here. We now save. And I think there are no issues. I'm gonna head on over to GraphiQL again. And if I refresh once more, you'll see under query that I've got a new entry here, which is our Get User. So let's do that. Let's go get user. I need to put an ID here as I'm being prompted. I'm gonna go with ID number one. And in here, once again, I'm just gonna query ID name and email.

So that gives me the very first user that exists in our array of users. I can also request for my second user, that's gonna give me James. So I've got this particular mechanism. Now there is a way for me to actually query specifically the user that I want based on the user ID. So now we have done that as well. And well done if you have followed along and got to this point. So, amazing.

Let's move along, let's move on to the next segment of things where we are gonna be looking at mutation. So far, we have essentially just been requesting information and we're receiving information based on the data source that we had. Now what we're gonna be doing is we're actually gonna be adding on to that data source. We're gonna be using a mutation. So unlike root queries, it's gonna be a mutation, a root mutation type that we're gonna be defining. So let's go ahead and start doing that. I see Chad buzzing up suddenly. Michael, hello, welcome from Edinburgh. Sunny Edinburgh, fantastic. It's a bit of a point of envy perhaps at this point because I think a lot of us right now seem to be facing a little bit of a gray sky. But hopefully, you'll find this exciting and interesting as well. Fantastic, lovely.

Okay, let's move on on to the next part of this demonstration, well workshop. Let's get on with creating mutations. So let's start off. We're gonna follow a very similar structure to what we have done for our root query type. So we're gonna go ahead with const root, let's call it mutation type, I think I've got the spelling right, yeah. Mutation type, there's gonna be another new GraphQL object type and in here, we're gonna start finding all of these different things that we have done, starting off with name and a description, let's call it, let's call it root type. Lets call it mutation, let's go with description in here I'm just gonna call it, I'm just gonna stay consistent and say, mutation, yeah, that makes sense, okay. Okay, now let's go ahead and start looking at our fields as you can see, that's what we have done. So that's exactly pattern that we're gonna be following, here, let's go with fields, okay, so in the mutations, just think about this for a moment, what we are trying to do here, is we are trying to add a user, all right. So in order to do that, now, we have three things within the user, if you look at the data structure, if I were to add a new entry, what I want is, I'm gonna add in the name and the email of this particular user, what I don't need is the ID, I want the ID to be auto-generated. Now, I'm not gonna go over the smartest of solution, but it looks for the highest value and then does it and all of that, I'm just gonna look at the length of my array, just gonna go with that number here. It's gonna assign a particular number automatically and that's kind of the purpose of the point, so we just get started with it, so that's what we're trying to do. There are two fields that we want to have as our argument because we want to enter the name and the email when we are adding a new user and it's going to take the name and email that you've created and it's going to create this new array element or new data in the data source. So, let's go ahead. Now, we obviously like previously, we also need to describe a type. So in this case, when I have created my user, I want that user type, I just want that to be displayed back to me. You can also have a list of users as well, if you want, so we can see that as well if we have time. I'm not sure why that's not here. Fine, next we want to define our arguments. And as we said before, we're gonna be taking in two arguments. One of them is gonna be name. This is gonna be of type, we don't want null so I'm gonna start off with GraphQl, type, non null. I am gonna wrap this with GraphQl string. So it's gonna be a type string, which I don't want it to be null, which is what we have done here and the next field is gonna be email. I'm just gonna copy this because it's essentially going to be following the same structure as this. There we go. So these are gonna be the two arguments that we need. Now, let's move on to main event which is gonna be our resolver. So let's, this is definitely gonna be a little bit trickier in terms of the resolver function that we have written so far. I think I've made a little mistake somewhere, have I? Let's go this resolve, I am going to be taking in my parent and arguments again. This is now looking a bit more like a function. So in here, what I want to do is I've got three fields that I need to work with, two of them are already provided. So I'm just gonna copy that first and then I'm gonna create a new user. This user is gonna have, say, can I have an ID which is undertake from users.then plus one. Again, not the smartest way of doing it, but again, this hopefully illustrates what we're trying to achieve here. So name is gonna be our arguments, name, email. And we have arguments.email. And we need to then add this to our array that we have. We're gonna push that into users. User. User. And then finally, return user. I think that should be it. One other thing that we need to do, of course, is if you remember when we had created our schema, we had only catered for queries. Now, we need to cater for mutation as well. We have a mutation. Call it root mutation type. And with that, we should be done. I see all greens, which is obviously preferable. And now I'm gonna just refresh this really quickly. And I see I've got mutations here and the documentation explore.

So on the mutation, as you see here, we've got add user. Let's write that. In this case, of course, we're gonna be talking about mutations. So we have to write mutation here. Within the mutation, we have add user. So add user, we'll take in a name. I'm gonna call it emma, email. emma at gmail.com perhaps. And this is gonna respond. We want to see the ID, name, and email as well. There we go. There you go. Now we have added our third user and we can obviously look back. So there is another thing over here on top, if you can see it, there's history. So I can go back. And if I want to just look at all of the information, my entire data source at the moment, I can go get to my get users. I can see that now we have three elements here instead of the two that we had previously. So that is a mutation that essentially changes changing your data source. Obviously, in this case, the data source is, well, it's not persistent. So if I were to restart my server, I will lose my changes and I'll have to redo it, but you can have persistent data sources as well. So if you're using SQL or any other database that you're using, then, of course, this will persist even after server is up or down. So with that, we come to the conclusion of the mutation side of things. Now let's move on to the next part of it. But like I said, there is one other thing that you can do, which is a very, very straightforward thing. So as you saw the mutation here, what it does is it only gives me, when I'm creating a new mutation, it only gave me one user. I can really quickly modify this to give me the whole list with the new added ones as well. So I can do that as well. So that again depends on your requirements. So I think in the type, I'm just going to call it, I think, as you remember here, a getUser. It was new GraphQLList. I'm going to get a GraphQLList. I'm going to wrap that around my user types. I'm now looking at an array of user type objects. And instead of returning user, I'm just going to return users. So I see green again. And hopefully now, if I were to create a new one, let's say it is Agnes. And my email is going to be, AGNES.GMAIL.COM. Seem to be quoting Gmail quite a bit. I think I do need to refresh this though. Okay, now that I've done that, I see my Agnes here at number three. If I were to add in Emma, I've got my fourth one as well. So as you can see, I'm not exactly persistent at the moment because I need to refresh in this case, but it just works for the time being. So this illustrating how mutations work. So that's how you would do it. That's how I would resolve a mutation. Now let's get back to our queries. And there's one other thing that we want to do because we are looking at to-dos and to-do information, we are now gonna be including to-do information, a list of to-dos that is gonna be associated with our users. So let's do that. So remember we need to describe our, define our data source again. Again, we are doing this locally so let's do the same as we had done with users. I'm gonna call it iConst to-dos. I'm gonna get in a couple of examples here. Let's say we're gonna be, let's talk, think about the structure that I want. So I want to have an ID. This is different from the user ID of course, this is the to-dos ID. So I'm gonna give it ID number one. I want a user ID which is gonna associate this with a particular user depending on the user ID. Therefore, the user ID is quite important because there is a relationship here. Then I want to have a task associated with it which is gonna be of type string and I'm gonna call it maybe Book Flight Tickets which I've done recently after a very long time. It was a very interesting experience. Flying had never been this complicated or nerve wracking as it was this time around, but well. Anyway, so Booking Flight Tickets is one of them. Completed will give me the status of it, essentially whether I've completed this task or not. And this can be type Boolean. As I'm here right now, I'm just gonna call it, well, true because I have completed this task. Now, let's add a couple more. I'm gonna go ahead and add a few more here. Copy this. Maybe one more. Okay, so let's go with user ID two, sorry, two does ID two, user ID one.

I think the first user can, which is me essentially, book my tickets and have to wash my dishes, which I have not done. Therefore, I'm gonna put that as false, and now for the third one, which is our ToDoList ID three, this is for the second user, which is for James, and James would like to visit the Botanic Gardens perhaps. Hopefully, that's what he wants to do. He hasn't done that yet, so I'm gonna move that to false. That's essentially describing our data source at the moment, which is our two do's.

The other thing that needs to happen here is that we need to add these two do's now onto our user type. We are going to go in here, so in our fields we have our ID, we have our name, we have our email. What we need to do next is we are going to add this to... So what do I want for a user? I want to have a two do's. I feel like I might be missing something. I think I might need to create a user. I think I need to create a to type first. Hold on. Stopped, let's see. So, we have our user type, let's do a do type. It'll be a new graph qrl. Object again, object type. It's gonna follow a very similar pattern as we have done before. This is gonna be to lose. Action, is a. User. K? And then we are gonna head on over to our fields. We're going to define our different fields. So as you saw from here, we've got about, we have four fields here. We're gonna keep it very simple. I've already prepped the code. So we're just gonna copy that in here. And then we are gonna run code, we're gonna run our new word interval. I'm gonna select a new way to run these ways. So we're gonna say modify my user here, somewhere in here. And the way I did it, is I took the first expression, I took the first type, so we're gonna put that into a new variable here, and then I'm going to do the same thing for, let's say a class name. I follow the same pattern. Now, next I need is my user ID. Which is also gonna follow the same pattern, because I also want the to do to be associated with a particular user. Oh, sorry, made a mistake. And then we are gonna head on to task and completed. So let's go task. And so task is gonna be very similar to the name field that we had, which is gonna be basically GraphQL string. Then finally, we have our completed status, which is, let's say, Hockey, alliance. Okay, I think with that, we are set, I believe, I think we've got everything covered.

Okay, I think that is covered. So now we need to add to our user type. So now what I wanna do is when I'm querying a user, I also want to see the to dos or the list of tasks associated with that particular user. I wanna be able to query both of these things together. So let's go ahead and do that. So in here, we're gonna say to dos, and then that, we are add on a couple of things. Let's say we wanna add on our type, our type is gonna be new QL list, which is type. I'm gonna skip the description for this one. It's gonna go straight in with the resolver. And our resolver is gonna take a user. And then here, we want to return from our TODOs array, we'll filter out exactly the list of TODOs or tasks based on the todo.userID which should match my user ID, which is essentially this particular object. Okay, so hopefully with this, I think that should be the last step. I think if everything goes well, I see green again. I am going to quickly check up my users and where they are at the moment. I have two because restart again. It's okay. We can work with this. I can add a couple of users if I want, but it's okay. That's not important for this. I'm gonna quickly refresh this so that you can see under queries and under user, now, you will see that there is a TODOs field associated as well. So now, let's do this. We've got our get users, we've got ID and email. What I'm gonna do is, I'm gonna very my TODOs together with this. As you remember that TODO has an ID, it has a user ID, it has a task's field, and it has a status completed field. So if everything goes well, we have our information ready here. We can obviously do exactly the same thing as we have done previously, where we can change this to just get a single user. I can provide this with an ID one, and will return just this particular one. So that in essence is how you would create a GraphQL API with queries, with mutations, creating your own data type with user, creating your own data type with your TODOs, and combining those things together. So that sort of gives you a bit of a gist of what we were expecting. So this sort of brings us to the end of the first half of the demonstration where we were gonna be creating our end point.

There are just a couple of things that I want to show you. A couple of things that you might come across as well, and that is what if you've got a user here? Now in this particular demonstration we've got about two users in our database. What if I wanted to query each one of them but sort of separately? So if I want to do this, essentially, say I want to get user one and two, but I want them to be done in a separate manner. I'm gonna be requesting the same information. I think I got something wrong here. Aha, I think I got this. There you go. That should be it. Now, if I were to try and run this, I think it is going to give me an error because it is conflicting with another field. So you cannot make the same query twice within the same query section, essentially. You cannot query the same thing. But there is a workaround for this. What I can do is there is a concept of aliases. So aliases essentially resolve this particular conundrum, so to speak. And I can give this particular query a name. Aliases essentially describe a name or define a name or assign a name to a particular query that you want. So in this case, I've done that with user one, call this user two. Now it's gonna give me this information for these two users individually, nicely wrapped up with user one and user two. So you can see user one information, user two information.

Now, one other thing that you would have noticed here is that I had to repeat these set of fields for both of these times. Now you might have to do that when you're writing a couple of different queries, you might have to have the similar kind of fields being queried multiple times. Obviously that can get a bit cumbersome. That can be a bit of a challenge. So in order to prevent that, what you could do is you can create some reusable code and that is what you call a fragment. This is essentially segments or fields that you would essentially use in a, well, in a repeated manner. So you can define that and just use that particular fragment as and when you need that piece of information. So let's define a fragment here. The way you do that is you start off with fragment, you give that fragment a name, I'm going to call it user info and you create a fragment on a particular user type. So our, sorry, a particular type, data type essentially. So in our case, this user is of type user. So if you look at here in our documentation, get users returns an array of users. So we are going to be creating this on user. And within this, I am just going to copy all of these different fields. You can have a subset of this as well if you want, I'm just going to copy all of these different fields. I'm going to create a fragment out of this. See the indentation is not great, but fine. It doesn't matter. So a fragment has been created now. So what I can do is instead of writing all of this out, I can use my spread operator, let's say user info. I can do exactly the same here. Oops, I missed a bracket, but I will fix that. Now I get back my same information. I can obviously put in a subset of this if my user information doesn't need to contain the id or the todos, I can get rid of that as well. And now my fragment will automatically just return this information. So there you go, there you have it. Just a couple of extra things for you to just keep in mind in case you come across that, in case this is a challenge that you're facing. So you do have the capability of having aliases to define specific or assign a name to particular queries, as well as fragments that enable you to create reusable query segments that can be used across different multiple queries.

In the next segment, what we're gonna be doing is we're gonna be creating or using Tyke Cloud. I'll talk about what Tyke is and what we're actually going to be doing after the break, but because it takes roughly about five minutes for all the setup to happen, it would be beneficial if we set it up now. So let's do that.

I'm gonna sign out of my current Tyke Cloud account. I'm gonna create a Tyke Cloud account with you. Okay, so follow along with me. One way of doing that is you can go to tyke.io. The other way to do that is just go account.cloud-ada.tyke.io. Do that. Now in here, you have the option of sign up. So I'm just gonna click on sign up here. It gives me a bit of a form which I need to fill in. I'm just gonna go Buddha, I'm just gonna choose a new. Let's say galaxy2001.tyke.io. And I'm gonna put in a password. I would probably want this auto-generated if possible because password strengths can be a bit challenging for me. There you go. I think it's suggesting a password. I'm just gonna take that. I think just pick a strong password if you don't want to use this. But yeah, ideally pick a strong, secure password is definitely what we recommend. We have made arrangements for that. Simple enough form. Let's fill that up. I'm going to need to prove that I'm human, hopefully I will not fail this one. I think that is accurate. Okay, I have verified. I'm gonna create my account. Okay, now that it's done, next step is to set up an organization. So there is a bit of a hierarchy here in terms of Tiche Cloud. So once you have created your account, you've set up an organization. It is an organization that is then set up in a particular region.

Alex you've asked, will you push the code to some repo? I will do that after this. At the moment what I'm gonna do is if you want to access the endpoint itself, we're gonna be using ngrok to expose that out for now. But yes, I will push the code to a repository for you to use it. And I think the organizers of GraphQL Galaxy should be able to get back to you with that, the link. Thank you so much for the question Alex.

Okay, so just going back to the setup. In this organization I'm just gonna call it Galaxy Demo Org. And I need to select a region. The way it works, there is a region where you're, which, this is a region that you need to choose for your control plane. I'm not going into the details of that specifically at the moment, but essentially just know that your organization needs to be set at a particular location. There's a lot of flexibility that comes with Tye Cloud. And this is what helps you out with it. So I understand the risks here. I'm gonna create my organization. And you've got two options here. One is to obviously set it up manually. The other one is that there is a demo setup which will pre-fill some of the information for you. All right, folks, let's continue. We have our final part coming up, which is going to be quite exciting. You're going to be seeing some interesting things happening. I'm gonna move a little bit faster along because I think we want to have enough time for Q and A as well. So hopefully you managed to sign up for, excuse me, the Tye Cloud account. I think the URL is now in the chat box. I think if you want to click on it, you should be able to do that. Feel free to create it. And what we need to do next, I think I'll get back to Tye Cloud momentarily, but before that, let us quickly go back to our slides. And let's start on what we're going to be doing next here on part, essentially, which is the final part of today. We are going to be looking at API management for GraphQL. Now, as you've seen so far, we have now created a GraphQL API. We've created a GraphQL endpoint. However, our work is not done. We need to make sure that the endpoint that we have created is safe, it's secure. It's easy to consume, it is managed, and all of that needs to be handled. And all of that is essentially the purpose of Tike. So we are essentially in the API management space, and we have got specific benefits. And I think I'm underplaying this a little bit, but effectively, we've got GraphQL API Management pretty much on point at the moment, and we're gonna be helping you solve all of the different challenges that you're gonna be facing when it comes to managing your GraphQL endpoint. Because now we've built it, it's fantastic. However, when people are gonna be consuming this, you need to make sure that it is secure, not just at the URL level.

You need to make sure once again, that it is secure at the data level as well, which I'll demonstrate shortly what the challenges can be with this. The second one is, again, question that we asked is infrastructure wise, how do you move to GraphQL? How do you combine things easily? That's a question that we will solve later on perhaps towards the end of the session, but that is one of the challenges that we have targeted and solved as well in a no code manner. So very, very important. So this is essentially what we do. We have got three things that we're gonna be demonstrating here, query depth limiting, field based permissions, and rate limiting.

Let's move on to the next bit. Why you should be using Tyche for GraphQL API management? Well, we are secure, we provide security, you're essentially keeping your service code as simple as possible. You don't have to bake in your security code. You're not going to write the code that is necessary for your query depth limits or your authentication. We have created an abstracted API layer which will help you manage your code better, help you secure your code better, help you scale your code a lot better. So that's what we've done with our API level.

Now, the learning curve in this case is very, very minimal. We have made things as simple as possible, as intuitive as possible for you to get up and running and manage your APIs, and you will see that in action really, really shortly. Then finally, there is, of course, when we talk about API management, it just doesn't stop at security. We also talked about monitoring and analytics and support. So there's a whole range of ecosystems, the entire life cycle of an API. We have essentially taken care of that for you. You build your API, you build your services and let us handle the management of your API so that you can expose and make it available to those who want to consume an application in a safe, secure and scalable manner. That is what we are offering. That is what you're gonna be seeing in this segment of our workshop. So, like I said, we're gonna be doing three things. Let's move right past that. We're gonna be using Tycloud, as you just saw. So Tycloud is our, well, our Tyc, component, our Tyc API management platform on cloud. Essentially, it's a SaaS version of it. It's fully managed by us. It has a sleek UI that is already included and it has all of the features available if you were to sign up. It is a free trial, it has all of the features that you would want at no extra cost available to you for you to try it out. So you try it out, if you like it, then you can proceed further. So, that's what we do.

There are a couple of other components when it comes to Tycloud, as well. You already saw organization that you need to set up, and essentially what encompasses your entire setup of Tyc is based on this organizational setup at the moment, especially for now it's a single organization setup, you can go into multiple organizations, but we won't touch all of that at the moment, I don't want to complicate things too much. And within Tyc, again, when you think about API management, you also think about scalability. You're looking at stability, as well. And when you have to do that, when you're scaling across different regions, you might be scaling across different data centers, you may need to make sure that your API calls are being done, or the request and response are going through with as minimum latency as possible. And that is only possible with the architecture that we have, which is you have gateways that are sitting locally close to the region that you're expanding to, close to the region where your users are and handling all of the computation, all of the processing at the local level so that we have reduced latency for you, but at the same time, what you don't want to do is with that solution, you don't want to end up having to manage individual gateways across the board. So if you are essentially scaling or available in 10 different locations, you don't have to manage 10 different gateways individually. So what we have done is we have created a control plane, which is a management layer that has enabled you to manage all of the different gateways through one central platform. That we have done for you with Ticloud, and you will see that in action as well. So that is what we have done. Additionally, if you have local restrictions, local regulations, then you can set up these local gateway in specific regions, which can pertain to those specific rules and standards, and yet be available and available for management through a control plane. So that in general, that is, sorry, in brief what Ticloud is, that is what we have done. If you are looking at an on premises version of this Ticloud, we also have that available on our website, which you can download and have that installed in your local data, a whole host of different ways in which you can install TIC on your system or Docker, or managed cloud of your own, you can do all of those things for you. We have a whole range of different offerings that you would, you can hook into. But today, we're going to be talking about Ticloud and we're going to be seeing that in action.

Okay, let's move on. Right. Let's do this. We've already started this process of creating an account and spinning up a gateway and going to the dashboard, which is the next step that we'll be doing. So let's get going. I'll quickly stop sharing once again, so that I can get back to my web screens. And once again, if you guys are stuck or having any problems, any issues, please feel free to send in your questions at any point of time. Okay, so I need my item. I need my Safari and I need, I think I will need my Visual Studios, but I'm going to have that, and I'm going to have Postman as well. Just to try it out. Okay. Fine. Right. So next step, once you have done your installation, let's go to our Safari. Here we go to our browser. If you have already got this setup done, you'll see a couple of things here. So this is the control plane. This is the central mode of control of all of your different gateways that you're going to be working with right now. I have a control plane. I have only a single edge gateway that I've created. I can create other edge gateways, but again, I'm just keeping things simple. One control plane, one gateway, nothing in behind you. Over here, we've got a developer portal that you can use to essentially publish the API. You also have the API Manager dashboard, and this is where we're going to be going next. So I'm going to wait for this to open up.

Here we go. This is my control plane now that is now ready and available. I can choose to design a new API or import one. If you see, there are a couple of things that you can do here. For me, what I'm interested in is, I want to design a new API, but we will get there shortly. So before that, let's see if we can make this available. The API that we've been using so far, it's on local host port number 4001. Let's see if we can make that available really quickly. So in order to do that, what we need is Ngrok, and for that we need something called Homebrew. So I've sent the link in our chat box for Homebrew installation in case you don't have it. If we just go to brew.sh, it has the script that is necessary for you to make the installation. This is essentially the script that you just want to copy and paste, and it will do the rest for you. It takes barely a minute or even lesser, depending on your system speed and internet connection, but it's a really quick process. If you haven't done it, feel free to do so. Brew.sh, you will need this to install Ngrok, which we are going to be doing next. So with that, let's move on to actually installing Ngrok. I have already done that, but for you to check it out, just type in brew install Ngrok. That's all you need to do. For me, I've already installed it, so I think it's not really gonna do much for me. But if you haven't done that, then this is gonna be the command to do it, brew install Ngrok. I'm gonna put that in the chat as well, so that you can just copy paste it if you want. Brew space install Ngrok. So if you just wanna use that.

Okay, now that that is done, what we want to do is, now we're gonna be running the server for Ngrok. So the way that that works is, I see a chat. Where is the repo for this? Can anyone share me a link? Samuel, which repo are you talking about? The code that we've been working on or the brew code or the Ngrok? Which repository are you talking about? The code you're working on? It's not on an active repo at the moment, but I will push that to a repo and make it available to you. So yeah, don't worry about that. And I think this is gonna be recorded as well, so you should be able to follow along with that as well.

Okay, cool. With that, let's move on to Ngrok. So the syntax here is, we start off with Ngrok, HTTP, and the port number. So we've been working with 4001. If you're working on something else, feel free to do that here. I'm gonna press enter. So if you look here, it has created a bit of a tunnel, which I can now use, which is all mapped to my localhost 4001. So there is an HTTP, there's an HTTPS version of it. I'm just gonna copy this. And I'm gonna go over to my browser, Safari. And this is the URL, of course, this is not enough. I need to add in my GraphQL. With that, what I should do is, it is now publicly made available. Well, I say publicly, but yeah, it is made available, my localhost installation for consumption list here. So of course, I wouldn't recommend this for an ongoing basis. It's just purely for this demonstration. This is not a production conversation at the moment. There are more secure ways of doing this, even with NGROK, because we have a user account, we can add authentication mechanisms on top of it. But not everyone is gonna get access to this. But right now I'm just keeping things a little open. So that basically the purpose of this is to demonstrate not to go into details of NGROK. So let's move right along, let's go on to, type right now. So I hope you can see the dashboard, what we're gonna be doing is, I'm gonna be now, step one, I'm gonna be mounting my GraphQL API that we have just created. So we'll just call it user todo. And I'm gonna proxy the URL that we just had. And I'm gonna go as far as just taking it all the way to GraphQL thing, I just want to do that as well. I'm gonna now configure my API. So in here you see a couple of things, there are a few different options over here. What I'm gonna do first is I'm gonna go right to the bottom of this, where it says authentication. And just for this particular step, I'm gonna remove my authentication mechanism and make it keyless. And I'm gonna save this and go back out. So you see a couple of things here. First thing you'll notice here is that there is a schema. So it has automatically retrieved the schema that we're working on. So you might not have seen this yet, but this is essentially the schema that was generated by the code that we have just written. The GraphQL API that we've created looks essentially like this. This is a schema that describes the blueprint of what we have created. This is automatically generated. Now, the other thing is Playground. This is essentially a way to interact with it, but we're not gonna be using this for now. What I need to do as one additional step on the cloud is because there is an edge gateway, multiple edge gateways, I want my processing to be done at the edge gateway level. So in order for me to do that, I am gonna go all the way down here where it says segment tags or node segmentation. I'm gonna add in a tag. So this tag is something that you would see here under this tags edge or the location, there are two different tags I can use either or both of them. I'm just gonna use the tag edge. What this will do is it's gonna mount my edge gateway and attach that to my control plane and use this API's gonna be then processed through my edge gateway. So with that now I have added my tag. I'm gonna update this. The other thing that we can do here is it comes with a prebuilt playground. So I'm gonna be using that, but before that let's just test out our endpoint. So on tie cloud, you saw here we've got an ingress for the edge gateway, it's essentially a URL. And I'm just gonna copy this, open up a new. Okay, I know what was wrong here. I think I need to add in my user, the endpoint, which for us was user to do. So I just need to add that in. So I think, okay, the request that I provide is empty. Okay, that is fair. I think that is what was sort of expected at the moment. So what I'm gonna do is my request is going through, but I need to have a playground, so let me get the playground ready. So let's go back here and I'm gonna enable my playground. Update. And I'm gonna hit update. I'm gonna do is now, yeah, this. What I should see is that I've got a playground now available to interact with my GraphQL schema. Now, obviously you might think, I've just replaced one URL with another, so what is the big difference and what is the big thing here? But what's happening right now is that the URL, the GraphQL API is now being rooted through my tag gateway, which means that now I can start adding my API management capabilities on top of this API, which I've created, which we'll see in a moment. Let's just do a quick check of the playground. And you can see here, you can see our entire schema, neatly available for us. We can download this as well if we want and use it somewhere else. Docs also available, very similar to what we had seen previously, slightly better looking perhaps. So let's try it out first query.

I'm gonna use the very first query that we had written, which was just the hello and get back our hello world just to make sure that we are doing things correctly. This seems to be a bit of challenge here. Ah, there we go, okay, fine. Well, can't have a technical workshop or demonstration without something going wrong. But okay, we've got this working so far. So this is essentially being routed through our Edge gateway. So now, let's move back into the more fun stuff we're gonna be doing. Perhaps we look at next, enabling our authentication tokens. So let's add a layer of security. This is an open API at the moment, let's add a layer of security on top of it. So I'm gonna change my authentication mode to authentication token, to start off with. Now, in order to do this, I need to generate a particular key for access essentially. Because if I were to go back into my playground now, it's gonna tell me that authorization field is missing. So I'm not authorized to actually make this request at the moment. So let's make that possible. So this is a two-step process. Now, you can do it in one. Now, what you can do is you can just go ahead and create a key for this particular API, and that'll be it. However, the challenge with that comes when you are dealing with a lot, large number of API endpoints. Managing keys for every single one of those APIs, and imagine if you have 100 or maybe 1,000 of them, then you'd have to organize keys and manage them, which can be very, very cumbersome. So what we've done is, we've created the concept of policies. Now, policies essentially define the rules of engagement of how the key and the APIs essentially interact and how those APIs then being made available and what rules need to be applied to that. So in this case, for instance, it's that it's gonna be using an authentication token to gain access. It needs an authentication token. So let's do that. Let's go into policies now. So under policies, I'm gonna add a new policy. I can already see that there is an API and I can add more as the time progresses or I can remove ones which I do not want. I'm gonna select this. I'm happy with all of this for now. We will go into the details shortly. Under configuration, I need to give this a name. I'm gonna call it userToDoPolicy. And here, I'm gonna just give it one hour expiration. I think that's probably all we need, maybe a little bit longer. Let's see, maybe a little bit longer. Okay, Create Policy, and I have done this. Okay, so my policy has now been created. Step number two is now creating a key based on this policy. Now, this policy essentially is, the key that we're gonna be creating is gonna inherit any rules that we might have set up at the policy level, which we'll see in the next step, but for now, I'm gonna just create a quick key. Here we go, I've got my key here. Now, let's head back over to our playground and we still have an authorization field missing. I'm gonna go up and add in my header. Here is gonna be authorization, and hopefully I'm gonna get the spelling correct, and I'm gonna dump in my key right here. So, I think with everything, I think I've closed my bracket, hopefully. Yes, I have, okay, everything goes well. I should get back my hello world. Cool, let's make a slightly more complicated query just to make sure we're getting everything right. So let's say we want get users. I want my ID, I want my name, my email, I want my tools. I just need the task and I need the steps. Okay, there you go. Okay, so all good, all good. We have now made it secure, we have now made it possible that people with, or callers or consumers with this authentication token are the only ones who can actually have gain access to this endpoint. Now, let's do one other thing, let's move on to, as you can see, there are a couple of things that are happening here. Now you could, you see here there's a nested query that's essentially happening, there's a nested field which is todos. And it doesn't seem a lot because we're only going from user to todos, but if you were to take another example, and maybe I can show you that, you could go much deeper than this. So if, if I were to take an example here, let's say as an example called Trevor Blades, remember, Trevor blades, countries API, naturally I'll get it. There we go, that's the payout. So within here, just to demonstrate the challenge that might come, you've got countries, you've got continents, and continents have countries. So let's see if you can spot the problem. You've got country, I can give it a code. So maybe I call it it's US. I don't know if I need a bracket there, but okay. Okay, now my country, you can have a name. Maybe it is gonna have a languages, okay, languages too much, capital. Maybe it has a flag, which is an emoji, apparently. Maybe it has, maybe it has continent. It belongs to a particular continent. So, and that continent will have a name as well.

Okay, so maybe, I think I can get this. Okay, I think the IDE, it's wrong. Okay, there we go. So we've got the United States here, with the emoji, with the capital, with the continent and the name. Now, if you think logically, continents can also have countries. So what I can do is, I can go into countries and I can make the same call again, I can go with name, I can go with capital, and I can again go, each of those countries will also have continents. So I can again go with this, and so on and so forth, I can again go with countries here.

So as you can see, if I were to now let run, there is a lot more information that is coming in, there's a lot more information that needs to be processed. Now, right now it is not as problematic because you're only going a few levels deep, but you can keep doing that and you can see the problem there. In some cases this might be necessary, but in some cases this might be a malicious attack. So if you want to prevent something like this from happening if we go back, what we need to look at is the query depth of this particular query, or depth of this query. The way you look at it is, well, for me, it's essentially the number of nodes that you're working with. So in this case, you've got one, two, three different nodes that you're working with. There are three. This is at a depth of three. This is a query at a depth of three. So if I wanted to prevent a third query, and I only want you to go up to my get users and not to this next level, this is how it would go about doing it.

So let's go back. Let me go back to my policies. Remember, policies are going to be defining the rules of engagement. So all these security-related updates are going to happen at the policy level. I'm going to go in my global limits. And in here you see here there is query depth. So right now it's unlimited. So I can go as deep as I want to go till perhaps my server crashes. But here I'm going to handle this. So right now it's at three. But remember I am going to pick it to see what happens there. Okay, that's been updated. Let's go back. And what it should do is it should give me a depth limit exceeded error. Now I'm gonna get rid of this really quickly. And now it should give me back my response because it is now restricted to just this level of information. No further, no deeper. So this is one of those security mechanisms that we have introduced. As you saw, you don't have to write your own security protocols. In order to do this, you're essentially doing that through the interface itself with minimal fuss hopefully. So, next on beyond the query depth. I'm just gonna get rid of this for now. Just leave that back to unlimited. The next thing that I want to show is essentially what you would call field-based permissions. Now imagine that this particular API, let's bring back our to-do's as well. Now, this particular API has a, sorry I have not updated it. This particular API has all of these different fields exposed now maybe in certain use cases you might want this to be exposed, but in other use cases, perhaps you do not wish that to be. Maybe you do not want to expose the email ID field for all kinds of users because it opens up to potential attacks, potential spam. You don't want that to happen. How would you go about doing that? So let's go back.

Now this is happening at the API level. So I'm gonna go to my API access level under user to do, and here I can see there is something called field based permissions. That's what I'm gonna be working with. So if you look here, have all the different types that are available, what I need to do is I'm gonna check the ones that I don't want now. I wanted to get rid of email. So I don't want email to be accessible. So I'm just gonna check that and update this. And what it should do now, is it should tell me that my field email is restricted. It's preventing me from accessing that information because well, I'm not authorized to do so. Now, under a different policy, you may have access to do so because you are authenticated in a different way, but for this particular authentication, this particular authentication token, if you are accessing this API based on that, then you need to, well, you don't have access to email. So now that I've removed it, I should get back my response right away. So, that is a second security mechanism that we have put in place specifically for GraphQL APIs, where you can restrict people on field-based permissions. You can obviously go even further, depending on the form of information, depending on form of access perhaps, maybe a degree of monetization there as well, maybe in that case where, you know, you want to have paid users gain access to specific information only, that could be another thing as well. But the mechanism is available to you to actually make use of. So, you have that. I think we've got about, well, we are two hours in now. I think as far as I know, I think about 30 minutes left for this. So I'm just going to move along. I think these are the two main features that I wanted to show at the moment. Time permitting, we might look at a couple more if needed. But for now, I think these sort of convey what specifically around GraphQL, what we have in place. Now, the other thing that we have as well is rate-limiting. I think maybe I'll check that up as well.

Let me see if my polling is enabled. I'm just going to disable polling here, and I end it with my rate-limiting perhaps, or maybe not. I think I'm going to skip rate-limiting for now, just because I think I'm just a bit conscious of time, and we'll get back to this if we have time towards the end. We can do that with the next segment as well.

Okay, cool. So hopefully this was clear enough in terms of API management and securing your existing GraphQL endpoint. Now that you've got these mechanisms in place, of course, it's not limited to what I've shown. The API authentication is not just limited to the authentication token. You have a lot of other options to look at. I'm going to remove my field-based permission for now, just so that you don't get caught up with anything. If you look back at our API, there are a lot of options that are available to you here under the authentication mode. You have got HMACs, you've got JWTs, Mutual TLS or OAuth 2.0, whichever version, even custom authentication through plugins, they're all available to you if you want to make use of that. And this is the power of an API management platform. This is the power of Tyke, essentially, you don't have to do all of these things. You don't have to a, bake this into your own code, and b, you don't have to. You take care of this for every single service that you might be creating. You have this abstracted layer, which will take care of your authentication to then apply to all the different services that are going to be hosted or tagged to it. So that's the beauty of it, that's the power of it. Hopefully this has illustrated that point sufficiently by now.

Okay, let's move on. Let's move on to something a little bit more exciting as well. I've been saying that for awhile, this is probably the final part of our demonstration, so I thought we would end this with something a little bit more exciting, even more exciting. So one of the challenges to GraphQL adoption is, has always been, well one, is obviously the knowledge that you need to have a degree of expertise in terms of creating your GraphQL endpoints and managing and building. Hopefully I've addressed that issue a little bit here where you've seen how you can actually go ahead and build your GraphQL API. Hopefully it wasn't too difficult. Within NAR we've created a couple of different things there. Obviously you feel free to check out the code at the end of the session after the Galaxy conference is over. But the other one is that people need to migrate out of existing infrastructure. That has been one of the biggest challenges to adoption where they might already be on Soap or REST API architecture. They might be already using REST based APIs. And now to move to GraphQL might mean having to migrate out into a total new infrastructure and managing that and ongoing basis. That can be a huge overhead. It can take a lot of time to actually make that possible. So we wanted to address that specific issue as well. So that's what I'm gonna be demonstrating here. We are gonna be using Teich's universal data graph. That's what we built. We created a universal data graph that enables you to use our existing infrastructure, REST or GraphQL existing infrastructure and create a GraphQL endpoint, a GraphQL data graph, without having to write a single line of code. Yes, it's a No-Code solution for you or a local solution for you. Where you can use your existing REST endpoints and transform that into GraphQL APIs and expose that out depending on however you want it to be. So let's see that in action. Before we begin, I'm gonna be using a different kind of APIs here. We're gonna be using REST endpoints because obviously we don't want, we've already utilized GraphQL one. So we're gonna be using REST endpoints to demonstrate the transformation. So let's do that. What I'm gonna be using for this demonstration is some of you might have seen this. This is called jasonplaceholder.typeico.com. This gives you free fake APIs or REST APIs that you can use to well do demonstrations and workshops. It's gonna follow a very similar pattern as our users and to-do's that we saw previously. I'll give you the link in the chat so that you can quickly check this out. And, okay, we are going to handle this, okay. Okay, there we go. So anyway, we're gonna be using two of them. We've got our slash users, which we're gonna be using, and we've got a slash to-do. Similar pattern to what we had previously. So let's go into users first. And what it does, is it gives you a list of 10 users with some information. Now, you are free to use all of this information in your schema, but we are just gonna be using the three that we've been using so far, which is gonna be id, name, and email. So, let's see how we can transform this into GraphQL. Let's go back to Tych. I'm gonna go into my APIs, and I'm gonna create a new API. And I'm gonna call this UDG, or Universal Data Graph User To-do. Now, this is gonna be GraphQL, and instead of proxying to an existing GraphQL service, gonna be using Universal Data Graph to compose a new GraphQL service. That's what we're gonna be doing here. So, let's go into configuration. So, as you've seen, you've got pretty much similar way as we saw previously. I'm just gonna remove authentication once more, just for the sake of this segment of demonstration. I'll save that, my API is already. Now, let's go into our schema. We are gonna be defining our schema here, right.

I don't need mutations here at the moment. I'm just gonna skip that over. I'm gonna create a new type. This is sort of the second version, the way you can go ahead and build out your GraphQL APIs as well. So, let's do that with types this time. So, I'm gonna call it UserType. And if you remember, UserType had an ID, as of type int and this is non-nullable. This is important. This needs to be there. And that is denoted by this exclamation mark. Then we go into name. There's gonna be a string. And we're gonna be having an email, also gonna be a string.

Now, in the query if you remember, we had get users, so I'm just gonna do that first. And that would have a list of users. Okay? Now let me zoom out.

Next, we're gonna go and describe our data source. As you can see, I've got my data sources here. What I need to do is this particular field, this get users, need to be linked to my REST API. So how do we go ahead and do that? Click here, define data source. I'm gonna go with the REST, and this is the URL that we need, so let's go and check out our URL. It says, slash users. I'm gonna go back out. There you go, that is my slash users. The data source needs a name. I'm just gonna call it users. Method is get, and I'm gonna hit update field and data source. And immediately you can see that the field has been updated, here is no more a warning or an exclamation sign. It's all good, hopefully, hitting update. I'm gonna hit that update here now. And remember, one more thing that needs to happen here is in our advanced options, we do need to go and get our node segmentation right, because we've created a new API, which we want to be processed at the edge as well. Using that gateway, so I'm gonna update this one more time. Let's enable a new playground.

And now, if I go to go back out here on to this particular playground that we've been working with, I can just copy this as well. Because the edge gateway stays the same, it's just the URL that's gonna change. So I'm gonna take my URL endpoint from here at the top, see this user, udguser2d, that is what I want here. That will do it for me. Should open up a new playground for me. Which now if I look at the schema, it has my user, it has my query. So what we should be able to do now is get users. ID, name, and the email. If everything is fine, it will query my information. So if you see Leanne Graham, Irvin Hall, these are all the names from the REST endpoint that we just saw. So we've effectively transformed our REST endpoint into GraphQL with no code, within, well, about five minutes, essentially. So it's just that simple. But let's not stop there. Let's keep exploring this a little bit further. Let's move on to our schema.

Now, let's get the second query in, which is, what if we were to request a user based on the ID? Once again, my ID needs to be available. So I return my user. Now, the type doesn't need to change. I need to define my data source though. So I'm gonna go back into my data source. You can see there's a get user here. I wanna define the data source. I can just copy this, essentially. It's not exactly the same. So what we need to do now is, if you look at this endpoint, after the slash users, if I go slash one, which is a user ID, it'll give me specific information of that particular user. So slash one is LeeAnne, slash two is Urban. So I'm gonna try and map exactly that. So I'm gonna go back here. And sort of just having slash users, I need the user ID. So now I can just put one or two because that'll be hardcoding it. I need this to be dynamic. Otherwise, I'm always just gonna be getting that particular one. So how do we do that? We're gonna be using, if you just hit the curly braces, open, you will see a whole list of things that you, a whole list of arguments that are available. So for us, under the user type, we have ID, which is what we need. So we're gonna be querying based on that ID. Or rather, in this case, sorry, this is the argument that we have set up in our editor. The argument that is gonna come in with the query. So I'm gonna add that. This is just a single user. Update my field. And as you can see, this is done. Update here. So what it should do now is, once again, if everything is fine, I can just move this into user. Go ID, we'll just call one ID. That gives me my first information. So that is just that, that's how simple this is. You've got your second user. I think you've got user 10. So let's try out user 10 as well. And let's say user 10 users, all available, all queried, with a REST endpoint essentially being the backend of this GraphQL front end, it's phenomenal.

But let's not stop there. We can, what we could do is, we need to combine it with our Todo. So what if we have two separate APIs, two separate REST endpoints. We wanted to combine that. We're gonna do that with Todo as well. So let's see how we can do that.

So if you go back into our user REST endpoint, beyond the REST, the user ID, if I were to hit slash and go to dos, it actually gives me the to-do list of an individual user. So that is essentially what I'm after. I will be querying the user based on a particular ID, and it should ideally give me back my user information, right? So let's go ahead, sorry, the to-do information. So let's go back.

I'm gonna be defining a new type, yeah? Just gonna be, if you remember, we did this of to-do. To-do has ID of type int, which is important, user ID of type int. We have, oh, my bad. There we go, needs to be capitalized. We need to have, I think if I see correctly here, the field is called title and completed. So it's not task, it's title, so let's go with title. It needs to be mapped exactly, so I think that's one caveat there, but it needs to map exactly for now. Completed, and this was moved in. Okay, so that is that.

What we need to do now is, obviously, I'm gonna be calling it together with a user. So I want my user to have its to-dos. There's gonna be a list of to-do. So with that, I'm gonna head on over to my data source, and you can see there is a to-dos field here. Now I need to define data source for this. Let's go with an existing, maybe an existing data source, let's do that. I've got my user here, but I can't quite use this at the moment because we're not looking at arguments. So arguments are only, so if you look here, argument is this particular field on top. This is an argument. These are object fields, essentially. So what we need from the to-dos aspect is that we need the object field of the user ID. So how do you go about doing that? So what we need, essentially, is this particular ID, not the ID associated on top. So let's do this. I'm gonna hit this again, and as you can see, there is an object ID here instead of arguments ID that comes up. I'm gonna do slash to-dos. Okay, I'm gonna give this data source a name. It's to-dos. Update, hopefully, I've got this all correct. If I were to now head out back into my Playground and hit my to-dos, and we'll see my title. Perhaps completed. There you go. There you go, we've now combined two REST endpoints into a GraphQL API. It's pretty much similar to what we had done previously. It's now been accomplished using two REST endpoints as the back-end. Which is I'm gonna use, well, hopefully, that is a bit amazing for you as well. This is something that is very, very powerful for anyone who's looking or has been having thoughts around how can I go about migrating my stack? How do I go about migrating it out? It's gonna be challenging, it's gonna be time-consuming. This is something that you can either use for just a quick test of whether this works for you or at the production level as well. You are available to do both of these things using Tige's universal data graph at any point if you want. So, I think that concludes our demonstration. I think that is all I have for today. We can, if we want, to actually include a third data source as well if you wanted to. Let's see if we can. Let's go ahead. So instead of going with Todo's, which is what we've been working with, we can actually look at social media posts. So, a user can also have posts that he or she might've posted, and we can do that. So, as a third URL, which we hadn't done previously, let's see if we can accomplish this, as well, in an easier manner. So, let's go ahead. So, as you can imagine, we're gonna be doing type post. Now, let's look at the structure of the post. What do we have here? We have UserID, ID, Title, and Body. So, let's see if we can map that. We have ID, which is of type int, important, UserID int. We had, I think it was Title, apologies. Yeah, Title and Body, okay. Okay, so I think we have this now. This is also gonna go into my User. It's gonna be Posts, right, similar to todos. This is gonna be Post. And by now hopefully, you can try it out yourself. If you go into our User once again, there's a few missing. Okay, my head update just to make it stick.

Hopefully that worked. Head out. There we go. I think that's did it. Okay, we've got posts here. I'm gonna define the data source. I'm gonna use the existing one, not to doos, because I want it exactly in the same structure. And to doos, I just use three posts. I'm gonna do posts, hit update. Update. Now, I've got everything done fine. Okay. I should hit posts. Should be a good title, should be a good body. Okay. I think we got it. I think it's too much information, perhaps. But okay, let's see. There you go, you've got your posts here. So maybe if I were to remove the todos for now, that's for demonstration, it might be a little bit more apparent. There you go, you've got your posts here. You've now combined three different data sources, three different REST data sources into GraphQL and expose that out. Now remember, this is now GraphQL Endpoint, which means that you can now apply all of the different API management security measures that we had previously. We can apply all of that to this endpoint as well. You can do that at that level as well. That, essentially, is a very, very powerful concept. It's a very, very powerful capability that we have brought to you with Universal Datagraph, solving the problem of infrastructure management, infrastructure migration, and getting up and running with GraphQL in a production environment as quickly as possible in a no-code way.