 What do you mean? My name is Nat. I'm currently working in Shopify as a React Native team. But today's topic is not really about React or React Native at all. You talk about GraphQL. I just want to show you guys why I really love GraphQL and you guys should too. So let's start about, it started about three or four years ago that I started learning React. So I used the common practice, which is Redux. And by the time Facebook also introduced, and now the new open-source library is called Relay. And I was frustrated because I thought it's gonna be like replacement for Redux. Because you know, all the really thing that Redux environment, you know? Anyway, but it's turned out it doesn't. So it's kind of like a way, a gate to a new experience on the amazing technology called GraphQL. You can say GraphQL is like a replacement for Reds API, but actually it's have a growing con. But now I'm only gonna talk about GraphQL and the con of Reds API, of course. Yeah, so usually when you fetching the data from the server, we will use the HTTP because it's very simple. Every browser can perform HTTP requests. And the protocol is very simple as well. Like you just have a string with some rule as a URL and then they also have a bunch of HTTP method. So yeah, you can do everything there with the actual HTTP request. But the bad thing also, you can do everything there because it's really generic. You don't really like the new guy that you want to like request the data, you need to learn everything about your how server built in to able to perform a request. That why we kind of invent a common practice like a best practice or a guide for building your API server. So I think this one is a popular one, like Reds API, which is look like this. So I'm not really gonna talk about it because I'm also not sure what is really called Reds API but it's used like a full method of HTTP and then have some like semantic name in URL. But clearly as you see this, it's just a common practice which means there is no rule that you can apply to this. And you also, it's just a string so you don't know what is result when you requesting this. You need to try requesting this API or you may need to like lead to the server API document anyway. So that why GraphQL is introducing. So it's introducing as a query language. So it's a language which means there is a syntax. You have only limitation way that you can make a request but for server side, you need to serving a thing called schema. So this is like a extra work that you need to do and you also need to serve the data let's make by the schema. So the schema is also writing in GraphQL language and for every client that want to request from you, you need to, so this is how schema look like which have like a simple, look like a tie definition in typescape offer. Have a primitive tie, have an array, have a, you can do an array of another time as well. So this is very simple. And every client when you want to request data from the GraphQL server, you need to like a query which your query cannot just randomly write it. You need to let's make the schema that the server serving and server will return you the data that you request like in the same manner that you request. So this is how you work. Actually other than that, you will join her. But it's kind of, please look like a lot of work that need to be done but why is this good? So a lot of people might introducing you, GraphQL like to as an architecture that solve some technical issue of the less API like overfishing, underfishing, or you can do a batching the request. But for me, the most benefit is having a tie system in the API schema. So what can you do with the schema? So it's clear. The simple example is this one is like a GraphQL which is like a document for your GraphQL server but it's kind of go to the next level because it can serve as a simple IDE and you can really have a auto suggestion and you can pay a lot like keep typing and then try it right away. So this is a really simple example of it but actually the schema can enable you more than that. So I want you guys to think about the way that connect the server to the client and have a really strict type system between it. So the really first UK that I can think of is generating a type because type in schema is really lean, right? So it can possible that you can generate any like language, type system language like not only TypeScript for like a reason you can also generate like a server code like a C++ or GraphQL or Golang, like anything can be generated from this. And another thing is auto mocking. So you can do auto mocking your query or even your component level. So the mocking here is not for me it's not really just for unit test. You can also doing while you development and then you're working on your UI state, logic or something, right? And then you just don't really care about the business layer from the server. You're just mocking everything of that. And then it's like have more less dependency when you start developing it. And then when you really want to integrate it you're just changing the mock query into the real actual query and then everything works seamlessly because it have a type. And another thing that I want to introduce is Apollo Engine with its lean name to Graph Manager recently is performance enhancing. So the idea is you upload the schema into that server and also upload the performance enhancing of each field of every user that try to request that, right? So this one is, and it will keep track of the performance of each field and also how user really use your schema. And they also shift another amazing product which is IDE integration in VS Code. It's a Apollo VS Code. So all of that that I talking is also, you can see all the thing here in your, right away in your IDE. They have a syntax highlight and you have, when you hover it you can see the document inside your own IDE. You don't need to open the document API anymore. It's right here in IDE. And other than that it's also able to like prefetch your schema and verify that you do something wrong with your, when you type it or not. Like this case it have a deprecation flag and this flag is not really exist in the type and it verify in your IDE at that time. Okay, another thing is also what they can integrate back to the Apollo Engine that I say early and it can show the performance of each field right away when you, so I feel like this one is very easy to really optimize some performance because when you move some field right to another, like let's say another request, you can, the other information is kind of get inside your IDE already and refactoring is very easy. So actually this is just an example of like how we really use the schema but there is a lot of usage of it. Like the Gatsby also use it to like optimize at build time or some like helping P catch for your server side before the client view deploy. So yeah, so for me is having a strict type schema is kind of enable you to like have a better developer experience. So that's why I think I love Graphio. Thanks.