 Okay, so welcome everyone. Thanks for joining our second meetup for GraphQL Singapore meetup. I'm glad to have you here Please take a seat So today we are lucky to have Carlos from GraphQL Hong Kong. He's based in Hong Kong and Shenzhen He also helped a lot organizing this event. He's just talking here I believe we all met him and in two months here He will be like in GraphQL basically everywhere as you're at least in Thailand, India, Hong Kong, Shenzhen Right? In two months I saw you tweet. You can hear more from him by following his Twitter He will later have a talk here also We also lucky to have Tiu here. He's in remotely somewhere else. He will join the session later He's a manager of product and engineering in Hasura, which is our sponsor Welcome to the GraphQL decade. Because this 2020 is a new decade, so normally we say a happy new decade I don't know. My name is my name is Mark. I'm the organizer of GraphQL Singapore meetup And this is my Twitter. Normally, I don't use Twitter a lot But recently I find it very useful for finding information and knowing people. So I put mine here These are some quick links about our meetup So of course the meetup, I assume that's the way you find us We also have a website which you can find a link to submit your talk So if you are interested in talking here or sharing here Or just maybe doing some very simple workshop or sharing you can submit through this link Or you can just Twitter DM me or something like that. We also have a Twitter telegram channel Where you can simply join and ask questions if you want And so for when we create the meetup they say we you need to frame something about why you create this thing So I say like we are a community for Singapore engineers to share everything about GraphQL and exciting promising things around it. And that's really the meaning of creating a meetup But like I just said we need to boost positive cycle for more sharing and To improve more people to get awareness of this new technology and if you if you have questions Please feel free to ask in the meetup or in the telegram channel or just email or something everything I believe there are me or some of us we are always willing to share to answer if we can help We'd like to take this chance to shout out to our sponsors Hasura We really appreciate them to provide the pizza and drinks over there They so they are an open-source engine that connects to your databases and microservices and They provide a production ready GraphQL API if you're interested in related thing you can just go to their website and they have some tutorials here who can Get your hands dirty quickly We also thank Hacker Space SG for providing the space The boss is over there. Thank you Oh Yeah, round of applause. Thanks The website is Hacker Space SG. So if you are more interested in this space, just check their website. They have also membership, right? Yeah membership here can check the link Okay, so let's suppose if you already have some experience with GraphQL in your work or in your project Please come up and share something in the future meetup like following the link I just said or just to just send me a tweet or something else We have a list of possible topics. This is also our official website assume each of them are interesting everything of them are interesting and They're all enough for like at least 15 seconds 50 minutes to 30 minutes talk You can take a look at this for me personally I think if you recently just migrated to TypeScript React GraphQL stack in production You will definitely have something to share about the experience also about some best practice about safety issue about performance They're all very interesting topics and yet we don't have a lot of resource about them in community worldwide So if you have something to share, please just shout out because you are very likely to be the first person to share this kind of topics Okay, so We want to have a session about introducing to GraphQL. What is it? How to use it? Why do we want it in as like I just did a quick survey over 50% of people here At least they only maybe just heard of the name except anything else so we we'd like to do a quick one-on-one and We'd like after at least after this meetup you can know how to talk to your colleagues about this new idea Actually, it's not quite new because I just this page. I just added is it's put it in 2015 It's iPhone 6s now. It's already iPhone 11 and The physical just opens those GraphQL in production in 2016 I think and right now it's over past three years, but still many people haven't heard of it so we need to push things forward and And happy new year for this Twitter for year 2020 the The big front-end stack for 2020 will be past quick with GraphQL I just saw it and I screenshot it because I agree with it and if Somewhere has someone here who want to pick out some new stuff for front-end developing these three things are Definitely the right direction and this is the report. I just shared you share with you in the state of jazz report So GraphQL is definitely have growing awareness world-widely, but they are not enough. I mean It can have definitely more promising future in the future Okay So let's just just jump into the one-on-one section GraphQL itself. So like I just said, it's not a library. It's not a tool. It's it itself is a specification you treat you should treat it as a query language for your APIs and also treat it as a document and It also tells Including both front-end and the back-end about how to query data for front-end You if gives you a form to query data to how to send a graphical request to the back-end and to fetch data as much as you want For the back-end, you need to follow the schema follow the graphical schema You have a negotiate with your front-end about how to provide data for each field in in a schema You you may not know what is schema we will introduce later But this is a general idea itself is a documentation. It's a specification and it's not some it's not some language like Java or JavaScript You can learn it, but you can implement any any languages. It's not limited and Itself is not a it's not a new like it's not a new protocol GraphQL service is still a HTTP request. Mostly you send to your server This is what we normally like what I don't know why it's not so Why it's not so not clear, but you can still see it. So this is what we like in our normal daily work We have a lot of front-end apps including web apps iOS apps Android apps and these apps are like of the same product But we are sending requests to the back-ends that it makes it may be the same may be different maybe Maybe a lot of services which is curing from different end point different database different micro services It happens a lot. Maybe in everyone's company, right? This is what we normally see but what problems that this have is that you are Very likely no if it's not where I managed will be soon become a chaos because The product PM they always want to add features or remove features or just change features so likely many links in this picture will be legacy and will be outdated and With this procedure many legacy code will come here and for in the improved and make the back-end and front-end very better Very hard to negotiate because we have a lot of legacy stuff. We need to maintain GraphQL is acting like this in this role Like I just said we have front-end web app mobile app or other app But they are sending requests exactly to one endpoint to the graph for endpoint and they For their HTTP request or some other request. They are sending to this single endpoint which is providing GraphQL query data and This endpoint will be working with the back-end will be working with this endpoint and To response with data but not necessarily from one place So it can be from database. It can be from some legacy stuff. It can be from very old Projects. It can be also from directly from database that can also have they can all happen depends on the back-end When are how you want to implement but all you need to do is to Implement how to resolve each field of the query But yeah, what does the query look like as they are did introduce I will do it later But still a little bit history class. So like I said, it's in 2015 by open source by Facebook So if the if the history is true, then Facebook has Used graph in in turn internally in 20 from 2012 to improve the performance of its own iOS and Android Android apps So at that time they are using each arrest request a lot and their app has some performance issue They cannot deal with low in low speed internet very well And they are sending a lot of redundant requests to back-ends to for their own features So they want to solve it. They internally have pushed a project similar to GraphQL But then after 2015 they decided to open source it to make it to public and they did make it to production usage around 2016 and Then it soon become a worldwide worldwide community because because it really benefits a lot of projects and many more and more users are using it and in worldwide Like I said more users more open source projects more More more programs using these projects and providing feedbacks and the improvement. That's a Positive cycle you can implement in any language including Rust including Java including JavaScript any language. It's not limited This is the I get it from Apollo website. So from GraphQL website website So this is a list of language in server side that currently have at least community support by the community support I mean that these are They will have the support that is being used in production and the for this language You can just feel free to use GraphQL in your implementation in your future projects and These are the list of companies which are using GraphQL in the in the Products some say that Facebook is the only user that is not true But Facebook is definitely the largest user. That's incorrect because now in Facebook and in Instagram in the in their own products and as I recently read a report like over 30 APIs requests are Over GraphQL. I think that's very likely to be true and also there are other Companies are using it heavily and also this is happening in China in India in Europe and Also here in Singapore. Okay, so Until now I'm all saying just I'm just talking I didn't show you stuff. So Well GitHub has provided a very great place to for us to do some experiments by experience I mean that you don't need to write a single line of code You just need to send queries and this API is our production ready because GitHub itself is using these APIs So if you go to developer.github.com slash v4 slash explorer, you will see this you can also Google for GitHub GraphQL and you will see the page So let's do some simple click When we get into the page you will see this Explorer, this is the Explorer where we can send GraphQL request to the back end from front-end using Assume everyone use postman or tools like that, right postman to send requests to send rest requests to the back end Yeah, of course postman cannot also send a graphical request. Also, there are many like tools like GraphQL playground, GraphQL, IQL something like that And a lot of a lot of tools can do the same as that or this is graph graph IQL, okay Can do the same thing But if you want to use this API, you need to use some real data in production So you need to use your accounts data For me, I'm using the GraphQL of Singapore Account because I don't want to use my own color. I don't want to mess things up, but Yeah, just feel free because They're all production ready. You see they say make use of your real live production data. So after you log in you are Authenticated request. So if you're trying to send an unauthenticated request, we'll definitely have some error But there is a trick here So for rest requests if you send unauthenticated unauthenticated request, we will report you some unauthorized error, right by some HTTP code in response code But that is not the case in GraphQL because we don't have HTTP code We don't have the rest response code anymore. Every response code is 200 You need to do the error implementation by yourself. That's most cases. I mean, you're so Every request we expect a response from the server, but you need to get error by yourself. Of course many Many client-side libraries are already down the job for you. So you don't need to worry about that But for here, I'm sending once he says saying that is that I'm all sending Authenticated requests So this is a query for logging If I want to ask for something about Current logged in user, this is what I want to ask about. Want to ask for you can just Ask for it and if we are get your back, get your data back Which is exactly what you want The data object will look like the query object, but you can see here As a request, it's still HTTP request You get the response to 200 okay, and the the header is the same as your query body Response is a string. It's a JSON object That's how the request looks like so it's actually very similar to rest request, right? But you are doing it in a different way Okay So far any questions if you have just feel free to raise your hand Okay At least save some requests for for showcase so So here comes a Okay, okay suppose that I'm writing a I'm writing a client for github GitHub has only provided me this but this is actually all what I need because we have docs here The document explorer is a very fancy stuff about graph care Graph killer because it comes naturally with With a code when you deploy in your In your endpoint you will come together you can get normally for every graph killer endpoint You can get a similar document look like this which will provide all the types of query and mutation So first first introduction here curious what you get data and the mutations Normally you want to change data like you want to update you want to add or delete So one question, okay, how deep I can go in terms of the Okay, so that's actually a very funny question. So if you don't do any limitation you can do in Just endlessly let's suppose you have a we have a relation like this user friend So each friend is a user, right? So we can write a query like that user friend user friend user friend user friend You can just do it endlessly because it is a graph and In graph you can just traverse unlimited unlimited unlimited endlessly, right? Sorry But that is a safety issue and For the server side, we need to limit that because if you if you allow that we are soon exhausted your server resource So you need to limit the depth of your request Can we use some percussion schema for this? Next structure Next this one here is a lot. Yeah. Yeah, I mean can we use some percussion schema or we should like directly describe of a tree like friends or friends or friends and we should put everything in the square Yeah, you can you can build it dynamically if you want it But probably, you know, if you're gonna be like a huge like rough to create and you are gonna go through Solubitations and your queries not gonna be body for the back-end side. But if you want that Just in case I don't know which case you want to ask friend or friend a friend But if you want that you can create it, but maybe the server won't allow you to do that So this is normally what a request look like So the trick is that all the requests I've been sending are sending to the same endpoint. That's the first trick And the second trick that inside the schema we can ask everything if it is provided here So let's say if I want to ask something about a repository So I don't know what's inside the repository. I need to take a look at it I need to take a look at it. So I search for repository and I get into the type I can see that a repository contains the content for project and I can see the inside of Inside the repository object. We can have all these fields So for all these fields actually I can just get them from here and it should be able to Autofill see because Why why can we do that because the schema is fixed? It is there already when you're trying to send request to the server because this is the only endpoint you have Yeah, there will be a unique ID depends on the client implementation. So Like in the newest Apollo client version, we they have a cache So for cash, they have the ID for each request and they do the catch based on the ID a Cash cash. Yeah. So this particular strings the graph QL log in was for a particular Resource ID which was implied in the request. I'm guessing right say they are multiple viewer logins, right? Yeah, you're back in so They might be some way on your client site to specify which View log in you want to fetch right like right now. I'm guessing there's only one Yeah, because this is authentic request, right? So it's here as a sign in as blah, blah So from the server side, I have received several user service the same in the same request like you said, right? But several but each request have each authenticated. Okay. This is the The implied parameter was your login. Yeah, that's my login info actually and If you ask only if I like I said if there is a rest endpoint Who which provides the same information like this look exactly like this, but I'm developing another page Which I only wants to show the number of my start repositories. I don't want all these other stuff They are redundant to me. What I can do is I just simply remove them Okay, so this is the request I will be sending for this page for this particular For this particular feature It will just get a lot as much as you want Also, another case is that for implementation for search Maybe we have met a case that we want to implement a search feature But the search feature can be about users can be about posts can be about everything But different thing may have different endpoints because you are searching for different database objects in backend But here we can also we're sending to the same endpoint, but As long as they have the search Search method implemented here if I click here in the search query the search query will perform a search across resources but the search and This depends on a specific implementation, but here the search will just report report everything you want, but with different types So here if I perform it this search request if I search for type Repository I need to make it bigger So here the search search request is just performed I want to search for graph query Singapore in github, but I want to search for Repository and issues So normally if you write it in rest you need to perform at least two requests sending for different things, right? but here you only send one request and in this request you can ask exactly whatever you want and Because this response is repository So I can ask for anything that inside repository in this single request if I want That's basically what it looks like what the graph query looks like Okay, cool But as a Another show here. So right now I'm all doing get things. I'm not doing query things. I'm all fetching data from the server side What if I want to change things? So for graph query we have mutation here Mutation is something we are change The definition is that if you write in mutation you are doing changes on the things in the back end So like a for example, there is a create repository mutation I'm doing this and I'm sending I'm sending some I'm sending the Create repository did create create repository to the back end with input Yeah input is here So input this is some details where you may not need to need to know now This is some career variables, but so far you only need to know that I'm sending this object Here and equally as this variable in the query in the mutation and I'm sending a create repository mutation to the back end and I'm asking for this data if the If the creation is successful, that's what this mutation is doing. I don't know whether I can make it if I send it It Okay, it returns an error because it's unprocessable because name already exists on the account C Now this is an error report for GraphQL, but it's not an error code. It's a successful response But inside there it has the error message Okay, so because I already have this project I need to create some other one And it's created. So here as The request is successfully executed. I get the response as I want because I asked for this data, right? so I asked for the repository's description ID URL and If I go through this URL Let's go You'll be the successfully created project as I created So you can imagine that if you are writing writing these features You can get the get all the response in one single query So you can easily write a page that based on the response based on successful or not I show an error message or I show a successful message and we direct me to the newly created page That's a mutation Okay, I have created a lot of garbage here in my account Yeah, I'm mad So that's a little experiment that I just did and so far so good Cool Okay, so Actually for 101 that's basically everything because at least you now know what GraphQL requests look like But that's only a little fraction of the whole idea. So later I'm going to introduce something that's related to GraphQL that is necessary in your work around this idea But not I don't have a another workshop like this anymore so There is a going to I'm going to answer some questions that I suppose you may have in the Several next slides. So the first is that what is GraphQL basically? This is not the answer. This is not but this is something very likely that we will do in our work If you are using GraphQL project, we need to define a schema for your data on the server The schema is something like like we just see in the docs Everything in the schema is need to be accessible You if the client asked for this field in the schema, you need to be able to answer it You need to be able to give the data back But the front end does not care how you generate the data. They don't care That's the idea So the first thing you need to have a schema But we the schema there is a lot of work for the backend because you need to deal with the resolvers need to answer You need you need to know how to answer these queries, right? So you can imagine that there will be some code, but for my personal experience I think the code level the code The line of course will be the same as at least the same as you if you're writing the rest way So it should be acceptable for backend employee a backend engineers as they are most here for you to accept that And then the second thing is you need to write a query on the client to get the data you need So this is for the front-end engineers as long as the schema is set up You need to do the you need to do the queries need to send requests to the graph endpoint like exactly like the HTTP REST request but in a slightly Different and easier way and another question. Why does graph care only have one endpoint? so For graph care, you only have one endpoint when you ask for some data But if you want to different data, you need to write different queries if you want to do different things You write different mutations. That's basically the idea. So this is different from rest, right? So I assume that in most companies we need to maintain a long list of requests for rest To do in different things and many of them are not used anymore But you don't know because because I don't I don't have data. Maybe I just don't I just leave it there but The effort to maintain the doctors is a lot because imagine you just create a new endpoint simply for a small feature in Instead of just pushing the data on the onto the under the code base You need to go to the doc site and the change something in the docs. There'll be a There'll be spend some more effort but for graph care is actually declared and It's actually very automatic. So I'm not I'm not a salesman about graph care But this is real so if you are writing code for graph and point in the back end It will if you have enough type enough types Declared in the code if you have enough commands as the tool ask there many tools can help you to generate a docs Exactly the same as the end point is with types with the comments with what the end point is for exactly like the github GitHub docs, but with very small effort That's the that's why I think the backend engineers you consider using graph care for your future API You can save a lot of effort you may not find it at first But as long as the API is being used and being updated you can see the effort being very very useful I So it's any easier way to do API versioning with graph ql API version. Okay, so by API version You mean that if you update a API the front end need to do something, right? Let's say we have version one. Yeah, and with the major update we have to go to the version two So do we have to like copy the code and then? Okay, so as far as I can see In my experience there are many there are some practices some are good some are bad So the first is that they just declare the version number in the in the root Recurry that's of course one way and the second way is that the front and the back end they maintain one shared project the shared project is the schema itself So for the schema self, you know everyone knows that the react project may have a dependency with the project with the tools That is depends on so if the number is fixed then the thing it Downloads the depends on is fixed So if you update the schema like you said then if you're using the shared project then the front and the back end They need to both update their version number and update the dependency that's one way also one way and the third way is that the front end don't need to do anything but when the back end deploys the deploys the When you deploys the schema file you need to let them know yeah, because they just send the request but The schema is the only thing it's like a contract. Sorry. It's like a contract between front and back end So I want to build that up a bit and I think it's a really good question regarding GraphQL in REST APIs We do usually have road versions. So we're gonna have B1, B2, B3 and I think there is a Great problem about that. Let's say that I'm a front end developer If you are just switching from B1 to B2, you are doing a major change in my code base Let's say there are like thousand people that say in Facebook Consuming for that API and you're passing from B1 to B2 So now there are like gonna be like a thousand people like eight hours per day I don't know like Monday to Friday just in dummy graph migration So one of the constraints about GraphQL and one thing that I think it is useful is a use to them base a Your GraphQL API with root version. So basically basically what you are gonna do is a Mark has mentioned before GraphQL is a strongly type API, so you're gonna have type. So also there is something called directives So there is a native GraphQL directive called deprecated. So basically let's say that you have a getUserById and now you're gonna have a getUserByArticleId And you want to deprecate that one and you want to release them Not the new one. So basically you are gonna just start that query endpoint Let's say a get with that add deprecated and a message And then you are gonna just deploy and add a new query with that get a whatever by adding So basically the way we think about that is that when the client is trying to fetch the data from the old endpoint It's gonna get the data But also it's gonna get a message and that message is gonna tell man This is gonna be deprecated and it can contain some data whatever and it's gonna tell you like You should use this new field that is gonna be used by article ID in order to fetch that data It's gonna contain this new data and then you can monitorize like the activity of that all endpoint that it was deprecated one year ago And when you see that there is not call to the endpoint from three six eight one year Once one year you can say, okay now is safe to remove it because we don't know that really five months There were nobody just like calling to this But I think it's a really good question There the main pain point would be the mobile applications because some people just turn off the updates. Yeah Yeah, that's the case Cool But actually you still need to I have to say that you still need to spend this effort at least it's not a like some every problem Okay, and uh, so next question operation types Um, like I just demoed there are queries and mutations and there are third type of operation type Which is called subscriptions. This is newly introduced in 2017 only to do real-time update So you can imagine that the query I just sent it keeps updating Like there's a query about the list of messages and this updating So I just send the same format of queries of messages to the back end and it's a web socket It's web socket and it keeps updating and I keep getting the push of the newest events That's a substitution. But there's a demo video about uh, you can easily find it online. So I won't play it here Uh, next question about the what is the role of drug pillar in history? So this is a history of data transportation Throughout recent recent years. There is a remote procedural core RPC There is SOAP which I never used. I don't know. I don't know whether you have used Oh cool cool cool All right All right yeah, good to mention that up and uh Rest everyone have used and the GraphQL. So this is basically the history of data transport and for everyone We are definitely most familiar with rest which is defined in 2000 and they have the Very specific endpoints called get post put delete for different purposes And the back end are writing keep creating endpoints keep updating them and front end are sending requests That's the way we work now Okay So let's imagine a case for the newly created company Pied Piper Who is writing the iOS app and This app is very simple. It's a social app for Pied Piper and they have a detailed page with user So that's if if they click Richard you will show the Richard page with his recent recent posts and the list of Richard's followers and This is a case that will happen in the Pied Piper office, which is the small house and the front end developer Dinesh is trying to is developing the iOS page for this feature the user The user details page and the back end engineer is here for you. He needs to Taney to implement the back end. So Dinesh needs to ask Dear for you and the list leave for the for the endpoints for the endpoints because Without the endpoints. He can basically cannot work So give for you. This is the list of the endpoints. Here for you give to the next For rest He gives him three endpoints the first endpoints is the user It's the user endpoints, which Is users slash id so with different id can give different user detail for the user, but Dinesh is angry. He says you don't have you don't have followers in this page. You need to add them Careful, I just give him another endpoint called posts Which is users slash id slash posts, which are given a list of posts in JSON format And the third is the followers and with these three endpoints Dinesh can do his work, right because he has all the data he wants, but maybe more than he wants And at least imagine you you are the iOS developer You need to send three requests in a parallel and You need to keep the loading status keep loading until all three requests have the response and You may need to manage the cache for separate requests and if If the product manager he wants something else you need to have four fifth sixth endpoints for this page But now They're using GraphQL and this is the only This is the only endpoints they want As long as the so this thing will work as long as what Dinesh wants are included in the schema. You can take a seat Okay, okay So this is the only request Dinesh will need for the for the request Uh, it looks the same as what I just sent to the GitHub, right? So you guys should be familiar right now about how things will work And here comes the end the war between rest and GraphQL. I find war is interesting because Nearly everything has war react has war with view rest has view has war with GraphQL Java has war with everything else and Uh, so here comes the war with rest and GraphQL But first thing first I'm not a assessment for GraphQL. So I need to say first that uh, GraphQL doesn't work under all cases and Under some cases might be over here. You need to take a look at your user cases Take a look at your products. Take a look at your maybe even your engineers You need you need engineers to do that, right? So you need to consider a specific case For using whether to use GraphQL or not or simply use that for your work Uh, okay, let's let's say first now I say why GraphQL is a better rest First thing GraphQL doesn't have overfishing and underfishing Overfishing and underfishing is two words that appears many times when people talking about GraphQL and uh And rest they say that if you use GraphQL overfishing and underfishing will never happen So I need to explain what is that? Let's suppose still in the pipe pepper still a Dinesh and gear for you What if the What if the ios program manager he wants to she wants some more features about the page She wants to add some more things like uh the first post of each followers. That would be a pain Because if you're doing the rest you will first get the list of followers Then do a for each do into the followers list for each followers You need to get the post right using the endpoints That will definitely are overfishing. Imagine that the user is using using Cynthia He will pay more for for this page Because there will be more traffic than needed Underfishing is also same But normally underfishing you just need to select to the backend engineer to ask him to give more data to But using GraphQL normally this case will not happen And in the same reason we can save the network Um, and like I just explained we can stop managing the docs for rest endpoints Because as long as the schema is well maintained the doc is automatically generated and for the fourth The fourth is for startup. I don't know. Yeah quick question. How many people working start up? Okay, race Okay, okay So for startup the first thing you need you may need to be interested in is to rapid development Rapid interaction you need to do things fast. You need to I need to work fast with but including backend engineers, but Using using GraphQL is definitely good for this because you only need like I said, you only need one endpoint And with this endpoint with this schema confirm Front end and engineer and the backend can do things separately the front-end engineers. They can easily Moke test which is or not there but can easily moke and the test and Development things based only on the schema Whenever their development is ready like in the in the previous case for pipepaper for their RISF They can use data with mock data based on the schema And when the development is ready when they finish developing their page They can just switch the endpoint to the rear endpoint and the rear data comes in but things will work because they are of the same type They are of the same format That will be very good for startup because you can have Very You can have a lot less meetings between the engineers And it's very good for your rapid rapid rapid development And the last reason is schema and type system So Basically, these are several reasons why GraphQL is a better rest But I'm not talking very clearly if you you can go to the Google and search why GraphQL is better and the first result will be from Apollo and Telling you all the details, which is the same as listed here And the last thing is the schema and type system. So I'm sorry. So this morning. I cannot sleep. I slept on I'm on bed until 12 o'clock and I still cannot sleep. So I open my iPhone and The Twitter is in night mode and I saw Carlos Twitter about this And it's saying that The size of GraphQL says over rate is over fashion and under fashion underrated is Types and typed and introspectable contract between server and client This is a very good point as I mean So I told so I tell myself I need to I need to I need to say this in tomorrow's meetup So I keep a screenshot and pasty here and I forget his night mode. So it looks very dark But the idea is like this. So Over fashion and under fashion is things keep People keep talking about about why GraphQL is better. But actually types and Schema and the type system is also very good for development because on several aspects first, they have a schema definition language This is a this is a schema which serves as a contract between client and server the contract that Can eliminate eliminate the meetings and for both sides to develop better and faster You have better communications. We have types already They are declared in the contracts in your requests every request you send will be response with With data with the type you want to expect So you can easily adopt type script with some good practice You can you even just directly use the schema types as your type script type Third another survey how many people use type script? Okay, can be more in this year because type speed is It is very I mean It can improve your efficiency. It seems like you need to write more code but it can really reduce the error rate in your code in your JS code and It can really help with your working efficient But with the type system you can easily support types typescript And Easily more can test like I just mentioned because every every response is expected Another question is about schema first or code first, but that's an open question I don't need to I don't plan to talk about it today But I expect some of you if you have some ideas about you can share it later Yeah, I know I know so So I'm okay The the type thing is true for rpc as well as the type system and schema Yeah, you can have you can have in your pc or even like you can create a new like api Unication that you want to contain types and but graph graph could basically get it out of the house types And it's easy to implement All right, time is flying faster than I thought But still okay because I this yesterday I did more slides for introduction But I didn't expect the time to be so long. Yeah, that's because like Yeah, yeah, he's waiting. Sorry. Sorry Okay, so for For these links is something I prepare for for all you guys if you want to pick up graph gallery These are all very good links, which I actually used when I was learning I have pasted all them on the graph gallery meetup website. You can just go there and use them So that's all for one one. I I hope that it helps you to have a Very basic knowledge about graph kill and if that was there, it's fine. Okay So I prepared another section by it will be very quick. I want to go through what happens in last year There is a graph killer summit last year in us And they have they have opened all the recordings on youtube and many of them are very good talks I did I did take a look at some of them and there are some of them are very helpful And if you're interested in these topics, you can just go through the youtube list I will later put the slides on our website so you can just download and go through the link And if you are interested in adoption from rest to graph killer can take a look at this airbnb talk They just did it in last year and they have some very useful experience For like I just said for apollo kind the newest version they have provided the cat support which are Help you to improve your performance in your usage caching is actually in our first meetup caching is a problem because the Because at that time there is not very good solution about the caching problem, but now it's not anymore And this is the same thing I just talked And for api security like the very good question has asked If we don't do any limitation graph killer api can have some security issue If you don't limit the data user can fetch from you can fetch as much data from you as they want And they can easily ask for too much data and make your service go down So these are several ways to improve your api security you can add timeout You can limit the data you can limit the depth you can limit the complexity of them have tools This is the links to the corresponding apollo open source library to do these things And these are some back practice, but I just listed this here as a possible topics for the For some for some next talk And also some list for tools But the best place is to go through the awesome graph killer page But you need to pay attention to the quality of the tools because some of them are not maintained And if you want to ask for something you can go through the list and check whether there's something you want Thank you For QA I might just leave it later Thank you