 All right. Wow, huge crowd today. And I'm a bit nervous because I have only rehearsed this talk a few minutes ago. I don't know if it works. So I might embarrass myself here. But I want to show you some cool stuff that I basically just figured out two or three weeks ago. And we are already having this in production. And we are currently doing a huge migration, basically killing off our entire REST API and switching it over to GraphQL. So I really want to share my enthusiasm and hopefully someone else can see the positive things about this and use it in your own projects as well. Short introduction. My name is Martin. I'm the CTO of a small startup in Singapore called The Outlink. We are an online art gallery. We also have an app that's called LuxGlof. It's a little bit like a marketplace for people to sell expensive items. I am also the founder of BitLab Studio, which is a web agency here in Singapore. By the way, both companies are hiring. And both companies are looking for people who would love to work with React.js and GraphQL. So if you are interested, try to find me on Twitter or on LinkedIn, same token, or just shoot me an email. So I will share the slides on Speaker Deck. You will put them on the GitHub repository, I guess. And so you will be able to stalk me if you want to contact me. I already have to apologize. After the talk, I have to rush off. I have some stuff waiting for me at home, so I unfortunately cannot see the other talk. And I won't be here at the end of the meetup if you have some questions. So I, of course, answer some questions after the last slide, but after that, I have to rush off, unfortunately. So sorry about that. I know it's a bit rude. So I want to show two technologies today. One is GraphQL. The other one is Apollo. GraphQL is kind of one piece of the puzzlers on the back end. Apollo is the other piece of the puzzle. If you use some JavaScript front end, like Angular or ReactJS or React Native or just vanilla JavaScript, you can use Apollo as your client-side piece of the puzzle. So Apollo will talk to GraphQL, and GraphQL will answer with data, and Apollo will make sure that the data is distributed to all your components. If you want to get an introduction to these two technologies, best starting point is, obviously, the official website. And actually, the GraphQL website is so cool. I don't really need to create any slides because they've already done it. So essentially, like, OK, what's GraphQL? And you look at it, and it's like, OK, it's a query language for your API. Query language sounds like SQL and stuff like that. So how does the query language look like? And you see it here. It looks a little bit like a JavaScript object. So you basically say, OK, I want to query a hero, and I'm only interested in the fields name and height and whatever. And the response that you will get looks like this. So it's essentially a JSON string that has the same structure as the query that you were requesting. And you can have nested queries. Maybe the hero has a parent. And that is also of a type human. So using the brackets, you can go deeper and deeper and deeper. And the response will look the same as well, also going deeper in the same way, OK? So I mean, writing queries like this is really easy. You don't need to know anything about database design, SQL, joints, foreign keys, all that stuff. Anybody can understand these kind of queries, right? Another thing is you have only one endpoint. When you think about classic REST APIs, you have hundreds of endpoints, probably. And the developer, every day when they start working, and they're like, OK, I need to fix something on that. Shop grids, OK, what was the shop grid endpoint again? Is it all products, own products, product slash something? So you have to go into your source code or look at your API documentation, find the correct endpoint, and then learn about what get parameters are possible and what response will I get back, right? And this is really painful. Slows me down as hell every day at work. So with GraphQL, you only have one endpoint, slash API, or slash GQL, or slash GraphQL, whatever you want. And your application, basically, these days, if you use something like ReactJS or React Native, it's basically a composition of hundreds of small components, right? In React, you build tons of components. And each of these components, they will have small queries of these kinds of queries here of the data that they want to consume. Like, imagine you have a website on the top right corner, there's an avatar icon. And the avatar needs like the URL of the picture and maybe first name, last name, to render that at the top of the website. So you would write a query like user, first name, last name, avatar, thumbnail, or something like that, right? And you have tons of components. And they all have these queries. With normal REST APIs, when I opened my LuxGlof mobile app, it sends 15 HTTP requests to my API. I mean, I should probably optimize that somehow. But most people who just start goofing around with mobile apps, they will do it like this, right? With GraphQL, I only have one request, because Apollo, the client, will batch all the requests in a queue. And every 10 milliseconds, it will take all of them and merge them into one huge thing that looks like this. So I will have tons of small components. They all have small queries like this. This can be combined into one big string that contains everything. And it will be like one request that is sent to your GraphQL backend and one response coming back with all the data that you have requested. Also, with classic REST API endpoints, when I go to slash products and I get a list of all my products, usually I get like 70 fields. Our database is pretty big these days. And we have lots and lots of potential kinds of information that we store for each product. And my REST endpoint, it returns just everything about that product. Even though, when you have to shop grid, what do I see? Picture, price, title, that's it. And then you click into the product, and then you want to see all these other 50 things, right? And here, you just define exactly what you want. And what's being sent back over the wire is exactly what you have requested and nothing more. So you not only save requests, which is like HTTP requests have to be built up. It's overhead all the time. You also save bandwidth, and you save space on the device because it's lesser data that you have to save in memory, right? So this is pretty awesome. Basically, the people on the backend that I won't talk about this today, their task is to create the schema to describe how your data looks like. And it doesn't matter what database you are using. It could be Postgres, it could be MySQL, it could be MongoDB, it could be, there could be even some endpoints here with fields that you are taking from the Twitter API. So, you know, your API could talk to another API and you can still query it in the same way like here, right? Because under the hood, on the backend, what people will write in whatever language they use, these things resolve by using normal programming functions. And you can do in those functions whatever you want. You can do an SQL query, or you can do a request to some other endpoint, okay? So basic, oh, okay, and because we have this schema here, GraphQL understands what data you have and there is a small web tool, it's like an IDE, that allows you to try out these queries and while you type, it gives you code completion. And because it understands that there's something like all films in your schema and it has name and climate and whatever, okay, here, this is a planet, it will, when you say give me all films and then for each film, give me title and opening crawl, whatever this means here. So, while you're typing this, it already shows you what fields are available. You don't ever have to look at any documentation. You could throw a new developer at your project, don't tell them anything, just give them this and they type the first opening bracket and they see whatever endpoints are available, right? They choose an endpoint, they type the next bracket, they see what type is in there, they type a bracket again, they see what fields are available, so to speak what columns are available in your database, right? You could just press the docs button here, okay, now it's here, and you can see what are my endpoints in each endpoint, what is the return value, what data types are each field in those return values. So, and you don't have to write a single line of code to get this kind of documentation. So, believe me, when you use this, you're like efficiency will skyrocket immediately, right? Okay, I hope I could, I have sold you on this. So, the other piece of the puzzle is, that's a backend, right? And we are not here today for backend stuff, we are here for frontend stuff and JavaScript stuff. So, Facebook invented all this and they released something called Relay. I tried Relay like two months ago when I already understood that this will be good for me but I totally failed and like after four hours I still couldn't get my React components to render anything from my database, so I gave up. I run it on Twitter and then everybody on Twitter said, hey, bro, why don't you just use Apollo? It's like Relay, but easier. So, I tried that two weeks ago and it was easier indeed, right? After like 20 minutes I could see something and then I went down the rabbit hole and now I'm sitting here. So, the Apollo documentation is quite okay, you basically choose what frontend framework you're using and then just follow the initial steps, how to install, usually these things here, usage examples, these are the ones in the documentation that you wanna read about. And then you might need to dig deeper every now and then you will go here into the API reference and learn how it works internally more under the hood to do some more magic stuff like pagination and so on. Okay, so much about the introduction. So, basically in this talk I will mostly copy and paste code from my slides into my editor because I'm too slow at typing to get this done in half an hour and basically if you wanna try this at home you can just get these slides and you basically do the same that I'm doing right now here. So, I basically wanna show you it's possible, you can try this, you know? First of all, if you clone this repository you will have to install a virtual environment with Python. So, you need to understand a little bit about Python so just Google that, install all the requirements and then you should be able to run a local Python server. That should look something like this. So, managepy run server and you should be able to go to this URL and you should be able to go to graphical and then you're like, hmm, what endpoints are there, right? So, okay, there's some endpoint that gives me all messages and one endpoint that gives me one message. So, when I go to all messages, that's pretty funny. All right, what else do I need to do? Okay, there's something like edges and something like node. I don't really know what it means. Aha, this is what I need, ID, creation date. So, these are the database columns that my message table provides, right? When I execute this, I'm getting a JSON string with all my messages in my database, all right? So, and this is how I would start working essentially. I decide what kind of component I wanna work on today and I figure out what query do I need so that this component can render its data, figure out the query here and when I'm done I'm copy and paste that query into my actual code so we will see that later. So, basically this Django server that I provide in the repository is just so that you have a GraphQL API backend available for you to play around with and it only has these three endpoints, like all messages, one message and create new message. We will see that at the end. So, if you wanted to now start using React.js and Apollo, first thing you need to do is create a React.js application and these days this is pretty easy. You can do npm install global create react app and then you execute create react app and you give it a name. So, you would do that when you clone my repository, right? There's already a frontend folder. You can delete that folder and then start from scratch again doing this, right? I don't wanna do this now because it don't want a lot of stuff from npm. So, I just imagine I've already, I've just done create react app frontend, okay? And it creates the frontend folder. That's all it does, okay? So, let's go into that folder. And if it has worked, you should be able, sorry, you should be able to do yarn start and this will open your browser and there's your React.js application that doesn't do anything right now, okay? So, this is how you can start a new React project. But we wanna use Apollo and I wanna show a list of items and then you click into one item, you see the detail view and I wanna have another page in my app where you can create a new message. So, we need three pages and for that something like react router is commonly used. So, we also need to install react router. So, while you are here in your frontend folder, we are in frontend, you would do yarn at react router DOM and react Apollo. I've already done that so I want to do that again. Did I actually do that? Yarn at react router DOM. Okay, maybe not, I'm not sure. Okay, so we are still in the setup phase of our project, right? We are still not really doing anything related to Apollo and GraphQL, but we should have installed all the necessary prerequisites at this point in time and now we need to make sure that this default React application that we can see here shows something that we actually built ourselves. So, I will basically remove these imports here and I will remove whatever is in here and now the beauty of this create react app is, did I stop the server? Yeah, I did. The beauty would have been that it automatically refreshes whenever you save your file. All right, so now it's empty and the first thing that we need to do when we want to start using this awesome Apollo and GraphQL stack and react router, we need to add a bunch of imports at the top of our file. So, we always have in every React.js application we have the react import at the very top and then here we have to import three things that are related to Apollo. Here we have to import three things that are related to react router and here is our three views that we wanna build today. These files don't exist right now, okay? So, we have these imports, then we have to do some boilerplate code that I don't even know what it does. This is what you find on the Apollo tutorial on the official website. So, essentially we have to use this create batching network interface function to create a network interface and we have to tell it and this is the important part. What is the URL of our GraphQL endpoint? So, of your backend server, right? This is the batching that I mentioned. When you have a lot of components with lots of queries that will be put into a queue and you can define how many milliseconds Apollo should wait before it grabs all the queries, merges them into one big one and sends them to the server. So, if you have some kind of app like a game or whatever that generates like requests on a per millisecond basis but you don't really need to send all these requests in real time, you could set the batch value to some milliseconds value here. And this allows you to send additional HTTP headers to your server. Let's ignore that for today. And then you just create an instance of Apollo client and then this is on the next slide. We will replace our render function with this fancy code. Okay, I have some syntax errors. Oh yeah, this is because of my slides. What's the problem here? Render, return, actually fine. Okay, there's one bracket missing. All right, so we have told Apollo where our API endpoint is and we have this Apollo client instantiated. And now we essentially wrap our entire React application in between this Apollo provider component. And we pass in the client that we have instantiated into that component. Who cares what this does below the hood, right? It works and it looks beautiful. So just do it. Same for React Router. You basically have to wrap your entire app in between React Router component. Unfortunately, the React Router component can only have one child component. So I cannot do this. This would mean we have one, two childs, like route and switch, right? We have to put one diff around everything. And then here, basically React Router with version four with the new API works like this. If the current URL is slash, then at this space, at this position in our HTML code, like right behind this diff, render the home view component, okay? But if the URL is messages create, then we will render that component. So it kind of switches on and off which component is currently rendered, okay? And this switch thing, let's ignore it for today. It's basically because these two routes here, they could be the same. If you go to messages slash create, messages slash ID is also a match because this is a variable part in my URL, right? And maybe slash create is the variable part in my URL. So, and then I was like, hey, why is this displaying both components at the same time? And then I looked into the React Router documentation I figured out if you use switch, it goes down the list one by one and if it finds a match, it stops and it only renders the component that it has found. So this way you can make sure if you have ambiguous routes that could be like overlapping that it only renders the one that it finds first, okay? So this is like a typical, like all my React applications and also my React native applications, the outermost entry point of your app looks always something like this. All these kinds of wrapper components that add magic to your application, okay? Okay, so this will still not work because we have been importing three files that don't exist right now. So I create a folder, views, and I create three files, home view, JS, and detail view and create view. All right, and I mean these views are supposed to be React components. So we need to put a little bit of code inside so that they just do anything at all. So I just changed the name of the class and I put some title here so that I can distinguish them when we test them. So we will have home view and finally, hey, where's my detail view? And while I was doing all of this, it kept refreshing in the background. But just now there was an error message, right? And now suddenly it's working again. I love this. So I could go to messages one and it's the detail view rendering now. I could go to messages create and it's the create view rendering, right? And I can just go to the home page and it's the home view rendering. So like our app skeleton is up and running. So this is kind of the painful stuff that took us 10 minutes that you need to do every time you start a new React project, right? You know, it's not that hard, right? Okay, so now we can do the exciting things. So we wanna learn about Apollo, right? And GraphQL. First thing we wanna do is how do I query some data? I wanna see some data, all of my database on my website, right? So let's start with the home view. First thing you do is you import GQL and GraphQL from React Apollo. And GQL is basically, I don't know, it's just like a function that requires this kind of JavaScript string literal. And this is exactly the query that in the morning when I started working, I figured out in the GraphQL editor, right? You can copy and paste this exact query into here, all right? So, and then we need to change our render function to actually use the data that we now have accessible in our component. So let me paste in this new render function. So, all right. So who has used React.js? Let's quick show of hands. Oh, wow, that's good. That's like maybe 60%. So most people will be familiar with this kind of syntax. Each React component, right, has this properties. Inside of this class, I can always use this.props. So these are things that have been passed into the component by some outside component, okay? So basically, like if I would do something like this, diff info equals hello, and let's say this was my own diff component, then I could do this.props.info inside of my own diff component, right? So this is how you have to imagine how properties work. And because of GraphQL, we will have a field called data. Like we will have this.props.data available in our component because we enhanced our component with Apollo, okay? And the cool thing is data is another JavaScript object that has lots and lots of information in it, and one part is loading. So while your request is still in flight, loading is gonna be false, and when the request came back, loading is gonna be true, and when the request came back, loading will turn to false, right? And every time a property changes, the render function will be called again. This is how React works. So in the beginning, when you first load your page, there is no data, so the query will be sent, loading will be true, and we will just return some loading stuff. This is kind of like when you go to the Facebook homepage, you can see in the timeline that there are these gray boxes, like these fake posts while it's still loading. And this is the kind of stuff that you would return here, right? You would return some kind of fake representation of the data that you will show soon, but it's not there yet, okay? So once loading is done, we instead of rendering this, we will render this, right? And so, and we will have now access to this.props.data dot all messages, which is the name of the endpoint that we have queried here, okay? And then we know that we have to do dot edges dot node to get to the actual item. And edges is a list of items, so we can map over that list. And for each item in that list, we will render a paragraph and put a link inside so that we can click into that item. So in this case, item is one edge, right? And we know that inside an edge, there is node. So I will have to do item dot node dot ID. So this ID is basically the data that I have requested, right? And this message down here is also the data that I have requested in my query, all right? So hopefully, huh, oh yeah, yeah. That happened when I tried this earlier. So I'm prepared for this. Ha, I'm not prepared for this. Oh yeah, of course, yeah. We need to go to the next slide first. Or actually we need to paste everything in this slide. So the last part of the puzzle is this component currently doesn't know anything about this query, right? This is just a stupid React component. Doesn't know anything about Apollo or whatever. So, and this is why we imported GraphQL. We used GQL to create our query. GraphQL is kind of a function wrapper or decorator or whatever you wanna call it. And unfortunately, you could use this GraphQL query if you are like bleeding edge, super modern ES, whatever syntax. But when you use create react app on the command line, the bubble config or the ESLint config is configured in such a way that you cannot use the decorator syntax yet. So unfortunately, this would be like super beautiful. We have to do it in the manual way. So we call the GraphQL function, we put in our query variable, right? And we wrap our React component into that. So now this GraphQL magic is wrapped around our component and this makes sure that this prompts the data and all this magic is available. And hopefully, bam, we can see data, okay? So now the next thing you will ask yourself, how do I create queries where certain parts are variable? Like if we go to this URL, this part of the URL is dynamic, right? This dictates what kind of data I have to query from my database. This is like the ID of the object, okay? And we can do that pretty simply. So this is gonna be our detail view. And once again, first thing we do is we put the query in here and now it looks a bit different. We have to write the keyword query and we have to say this is a query for my detail view and actually you can come up with any name. You could also call this product detail or anything, right? I haven't really come up with a good best practice yet how to name these things. So I like to name them in the same name like the component is. Like this is the query for this component, right? So, so far this has worked for me pretty well. And I'm saying that this query has variables, okay? And it means there's one variable that's called ID. And the type is this special kind of GraphQL ID. So you see these weird strings here. Those are GraphQL IDs. You could have more things, right? You could say this thing also has, I don't know, limits and it's an int and it's a mandatory field. So this is how you define your variables and then there comes the bracket and then there's the normal way how you would query things from your endpoints, right? So you would usually go in, you can basically exactly the same thing that you just saw there. We can also write it down here. So we can say a query, any name, oh wait, sorry. Query, any name needs a variable ID of type ID is mandatory. And when I execute this query, I wanna call my message endpoint and I wanna query filter by ID using my ID variable, okay? And whatever I get back, I want to have the ID, the creation date and the message. So I can't run that yet because there is no variable, okay? So when you have queries with variables, you need to define them down here in the variable window. And once again, it's super smart. It already detects what variables I defined up here and suggest them for me and then you just fill in the variable and you run your query and voila, you get your data. And then you copy and paste this whole thing into your React code and it will work just like that. So the other way around is usually the case. You try typing it here and it doesn't work and then you're like, where does it work? And then you go to graphical, you paste it in here and you get some nice error messages here, okay? So that's the first step. We define our query. Second step again is to use the new data in our render function, all right? So same thing, right? While my query is still in flight, I'm rendering some loading stuff. Once I got my data, I have access to data. So this.probs.data and .message because that is the endpoint, the graphical endpoint that I've queried, right? And then .id creation date message because those are the fields that I have requested. So I have exactly that data available in my HTML markup, in my render function, okay? And then I probably still, oh yeah, yeah. So the decorator part is a bit more tricky now. All right. So we have to read this from the bottom up. Just like before, we are using the GraphQL decorator, right? We are passing in our query and in this case we are passing in another JavaScript object with some extra data, some options for my query. And then we wrap our component in that wrapper function, okay? So far so good. So how does this other extra options object look like? So it's a JavaScript object and it has a key options and this can be an anonymous function. So this syntax here might confuse a few people. This basically means options isn't just a string or whatever. This is actually an anonymous function and the first parameter of that function is the properties of my component, okay? And so this function returns another JavaScript object where the first key is variables and then I have one variable called id and I'm now using props.match.params.id. So this is because of React Router, okay? Because we've wrapped our entire application in between React Router. React Router does some cool magic and makes sure that all my components have this props.match available and if my URL had any variable parts, so like if you use this colon something, right? This is one of the params. So I have .match.params.id, all right? So that means this is how I can access this outside information from the URL. I'm getting it into my React component and now I'm passing it into my query variables for GraphQL to consume, okay? So let's see. Oh wow, it already updated itself. So we can now go into each of our things here and it will display the value from the database, okay? And now this is something that I wanna show you. So I refreshed, no, no, let me go to the homepage first. So I refreshed the page. I get one request for GraphQL, okay? And I get back the result. I go into the first object. It's another request against my web server. I go back to this page, no more request. Because Apollo remembers what kind of data types do I have? So in our case, it's the message object and what IDs do they have? And it keeps a cache of all of them, okay? So if I go into the second one, we have never seen that one yet. So it's another request. If I go back to the homepage, no more request. If I go into the third one, it's another request. And now, no matter what I do, I click around in my app, no more requests, right? Everything's in cache. So that you get all this magic for free and it's really helpful for mobile applications where if the person is on the train, for example, the network is suddenly gone, it doesn't matter. You can still move around in his user profile and on the latest tweets or whatever and can still see stuff. All right, so the final thing that I wanna show today is how do you write data? We have understand, we can understand now how to query data even with variables. So how do we write data? In the GraphQL world, this is not called a query. This is called a mutation. And so that's why you have to write mutation and then as before, I give it a name. So this is the mutation for the create view, right? And if you wanna create a new message, there's one field, a text field where you type in your message. So this is kind of like the form data that we are about to send to our GraphQL endpoint. And we say like the variable is called messages type string. And this is the endpoint of our GraphQL schema. So we would do like mutation, like new developer, no clue what's in the system, press control space. I only have one mutation, so it already completes so that one mutation that's available. I press records, it already tells me you need to provide a message, right? Let's say test. And when you send a request to your mutation endpoint, it comes back with a result as well. So what is the result? It has two fields actually, form errors and a message. And we know that a message is also part of our schema. So we might only want to have the ID because I wanna save the message, get back the new ID and then you could like refresh the page and go to the newly created detail view of that ID, okay? Or actually in our case, I would just go back to the homepage. So you can try that, won't, oh, even, hey, wait. This should work. Oh, no, of course it works, yeah, because I provided my variable here already. Okay, so, and I know this is pretty hard to digest now. It's already a lot of code and you're all tired. But we are almost done, only like two more slides with code and then we are done. In my component, I will define submit handler. So when the form is submitted, I need to do some magic, right? And first of all, I will prevent whatever the normal HTML form would do. I will just stop that event. Then I just use the HTML form data API to fetch all the data from my input fields. There's only one field that's called message, right? And now because of Apollo and because of the decorator that we will use at the end, we have this.probs.mutate available, okay? Because this is a mutation. And we provide the variables that are necessary, you know? We have defined that our mutation requires a variable. So we pass in that variable by using that form data thing again. And this is a promise. So when you call mutate, it's a promise. When the promise resolves, so you say dot then in the end, oh, sorry, what have I done? Okay, when the promise resolves, you get access to the return query here, right? So you get access to res.data.createMessage. And then there might be something in form errors or maybe not if there are no form errors. And there might be something in message if you have successfully created a message. I think if I don't provide any text here, there is something in form errors. Please provide a message, okay? I designed the GraphQL backend that way. So I will basically just check if there are no form errors, I will redirect to the homepage if there are form errors. You would usually use something like this.setStateErrors and then you put the form errors in here. So when you set the state, your component re-renders, right? Then you would put some kind of form errors component down here so when the component re-renders, the form error appears, okay? So this is really up to you how you actually display the form errors in your application. Okay, so that was the submit handler. And then like in the other examples, I will replace the render function with something more meaningful. So I'm essentially just displaying a simple form, like this, just one form and one button, right? So this is a very normal HTML form. It has two HTML input elements inside and it has this onSubmit handler here, which is the function that we have created up here, okay? Yeah, so, oh yeah, and before this works, we have to wrap our component in the Apollo decorator and we have to remove the export default here. So this is the same thing as before, right? We use the GraphQL decorator with this query, in this case, with this mutation that we have created and we wrap our component inside. So now, hopefully, there it is. It works. Okay, any questions? Yeah. Yeah. What happens to the data? Yeah, everybody asked that. First of all, I don't know, I have never tried. You know, I just started with this two weeks ago and I haven't gone that far into my own apps where I need to invalidate cache, but essentially, I think you would do something like, if I click into this, right, this component mounts and you have the component will mount lifecycle function in your React component and there you can decide, is this a component that needs to be up to date all the time? Then you can tell GraphQL that even if you have the data, please refetch. There are some ways. Yeah, you can like this.props.refetch and then it will just run the query again even though it's already in the cache. Yeah, I'm not sure if there are ways to find out the age of the data because that will be optimal. Then you can ask, and you know, this item, when did I fetch this? Is it one then longer than one minute ago? Then when this component mounts, I will do a refetch. There are pretty simple ways that when you read the Apollo documentation to fix this. I wonder whether some data that's mine and you know that I have. Yeah. But you don't really want to talk to the backend, right? You want to keep your requests as few as possible. I mean, if you have to send a request to the backend, is this up to date or not? You might just as well request the whole thing already. It's just a few kilobytes of data anyways, right? I mean, it depends on the use case, of course, yeah. Yeah. So, what about authorization and guarding? That's the second question that everybody asked. Yeah, so you would have to, in your app, implement some way to, for example, get a JSON web token. So you will have to have another API endpoint to retrieve the token. You will have to implement something in your app when the app starts to get the token, okay? If not show the user some kind of log inbox key and username and password. Hopefully get the token this time. And then here where you say credentials. So if you have cookie-based authentication and you say credentials include or credentials same origin, it already sends the cookie. So your backend will be able to identify that user. And if you use something like JSON web token, you will probably, I don't really know, I haven't done it yet. I mean, the stupid brute force would probably be that all my endpoints need a variable and you just send the token. Oh, wait, no, no, no. You can also create, send your token here as a HTTP request header. So you would like token, you know, you probably pull this out of local storage. Yeah, so there are ways to do it. What if like, I have like different, like so-called data, like let's say some data should be readable by gas. Data should only be readable by gas. I mean, once you have the token, you send that token with every single request. And on the backend, these guys who implement the backend for you, they have to make sure that on every resolver function, they check first what user is this and then what data do I query. So this is completely up to you how you implement your backend. So like, gas, they don't have any, they also must have a token inside in the network interface or can I change the network interface? You would do something like token and then I don't know how, like, is it local storage, right? Local storage.gat, I think, and then token. And it's either undefined or something. And you send that with every request. And on the backend, you are able to either use the token or not, and then it's an anonymous user. So another question I have is like, how does this, like GraphQL compares to like, socket-based APIs and like, hate, hate, OES, things like that. Yeah, I've never used hate to us or ever you've pronounced that. I've only worked with REST APIs in the past. So, and I think Apollo has something built in to do polling just by stupidly poll or even with sockets, but that seems to be a feature that's still in development. And if you really wanna go that way, you should probably use relay and not Apollo, the stuff that Facebook built. I think that one has polling with sockets already built in. Yeah. Thank you. So with Redux, they recommend to not use hate to stay in the component. Could you still work with Redux? Yeah, and this is also pretty awesome. So, actually, Apollo uses Redux under the hood. So, if we look at our app here, let me go to the Redux console. You can see what it's doing, but it has its own store. You could write a middleware to integrate the Apollo store into your own app store even, but I don't know why you would wanna do that. So, but if you have your own Redux store wrapped around your entire application, that is separate from the Apollo Redux store. So, you can still use Redux in the exact same way like you've been using it before. Yeah. So, this technology is super uninvasive. You can start using that today. Like on my GraphQL backend server, I'm writing and like, for example, am I online? Yeah. So, anybody got $100,000? So, I was like, okay, let's try this GraphQL thing, right? And I built this modal component and this whole make, offer, flow, this is like completely GraphQL. I had no endpoints for this, so I just built them. I had no components for this, so I just built them and then I just dumped this into my website. So, maybe I wanna, I'm okay with paying $100. No, I'm not gonna send that. Okay, so, you know, and this doesn't touch anything else of the application. So, you can start building this step by step, like only the new fancy stuff uses this and then whenever you have to do a bug fix on one of your legacy components, you just migrate it over as well. So, it doesn't have to be a huge migration that is gonna take us half a year and we will never do it. You know, you can start doing it right now. All right. Thanks. Oh, there's one more question. Yeah, so that would be like, you have to have a socket, right? And you have to use socket IOs for having a permanent channel somehow. So, it's somehow possible, but it's with Apollo, it seems like not really production ready right now. With Relay, it works, but I'm too stupid to use Relay. I tried that and failed. So, yeah, there are ways to do it, but I don't know. I think Meteor, right? Meteor is using this under the hood somehow and they are doing real time polling all the time, yeah. So, it's somehow possible. I don't know how. Yeah, so regarding these questions, authentication and what was your question? Cache and validation and these kinds of things. At the end of this month, at the 29th, I'll do the Singapore Django Nows Meetup. You can find it on meetup.com as well at the Zendesk office and I'll give like 90 minutes to two hours workshop where I will put everything together and do one real application that tries to solve all these problems that everybody asks immediately anyway. So, I'll try to give all the code snippets that you need to get flying and then you should really say, now we go and reuse this. No more excuses. Okay, all right, thanks. I guess that's it for myself.