 Hey, hi folks, this is Abha Income here. I'm a software engineer at BigBinary and today I'm here to speak on Reward Back to Rest or Resume Graph Cure. So a bit of introduction about me. I love open source projects and I hope everyone here does love open source projects. I love to contribute to open source projects and on daily basis, like on regular basis, I try to contribute to Ruby on Rails recently, like just 5-10 minutes ago, my one P was moved to Rails. Also, I try to contribute to React, GraphQL and to Bookoff, which are also some open source packages, libraries, if you know. I write personal blogs on my website, which is abhaincom.me. You will find blogs which are mostly related to Rails, GraphQL and related subjects. Recently, I started learning TypeScript, so there's a fun story about it. I started learning TypeScript because I had some packages in my mind, which I wanted to build and I started this as a 100 days of coding challenge. So if you guys know, 100 days of coding challenge here, right? So basically what you do is you learn something on each day and you post the update on Twitter so that in this way, you're just publicly committing to people that, yeah, I'm learning something. Apart from the coding world, I love basketball. I love to play basketball and I'm a huge fan of Golden State Warriors, which is an NBA team. So there's a game coming up on Sunday where my best favorite player, Steph Curry, is going to be playing and he's been out for the entire whole year, I think. So let's get back to business, revert back to rest or resume GraphQL. The title of my presentation does not give the entire context, so let's get started from the beginning. So the presentation would be typically in format, like it has a movie. First, we'll start with the climax. Then what we'll do is we'll understand what happened previously and then we'll come to the present scenario. So I'm just going to reveal the climax for what we did. Did we revert it back to rest or not? And yeah, we did revert it back to rest. There's no gift here coming, but I think it's something related to the internet. Anyways, so there's an obvious question which comes to everyone's mind that why did we use GraphQL in the first place? And to understand that, we need to... So how many people here know GraphQL or been using GraphQL in their productions? I can see two, three hands, okay. So you guys are here in for a treat. So you'll be understanding a bit about GraphQL as well here and you'll be understanding how to look, whether to use GraphQL or not in your applications. So to understand the background scenario, why did we use GraphQL in first place? We need to have a bit of understanding about what application we were developing first. So I'll just introduce a bit about our application and that would help everyone have a bit of context about why GraphQL fits perfectly in it. So our application is called as Nitro Help, which is a contextual help management system in which we have three different applications. If you could see, we have a web application. We also have a widget, we have a chat application. So basically what happens here is, let's say you have e-commerce websites or there's some organizations who have e-commerce and all those things, they want to have end user or end customers to be able to interact with them if they face any issues. So if you face issues with your order, the placement or if you face issues with your payment and all those things, you want a way to interact with those. So that's where the web application comes into picture. Similarly, we have a widget application which can be loaded on your organization's website and people could easily interact with that widget and find out solutions easily. So if there are some FAQs and all those things, you could find it out. Also we have the chat application which helps the users to interact directly with the agents of the organization. So you could describe your problems and get the solution as soon as possible. So we have these two, three applications which work in parallel. And now we also have an Insights Engine and a lot of different applications and all these applications, when they work in parallel, you need to know how would these applications interact with each other, right? And so the very obvious answer for this question is using APIs and that's where GraphQL comes into picture. So basically what happens here is previously before GraphQL was born, REST was the de facto. We didn't have to worry about which tool or which framework to pick. So REST was default. Similarly now GraphQL comes into picture and now that's where we have to pick between whether to use GraphQL or whether to use REST. So before GraphQL and before REST, there was SOAP. So SOAP, REST replaced SOAP. Now people say GraphQL is going to be replacing REST. So there are a lot of articles or a lot of people who feel strongly about it and speak openly about it as well. So we'll look into it. Why GraphQL was a good thing for us and how could we be able to benefit using GraphQL in our application which is called Nitro Help. So I've listed down some of the advantages. So people who do not know GraphQL, these are the advantages plus there are many advantages which you get with GraphQL. So if you go out on the internet, you would be able to see them all. So the first advantage which we got was no overfetching of unwanted data. So I'll explain this with an example here. So what I mean to say here is in REST, what happens is let's imagine we have the user's details API endpoint which is API v1 users with the user's ID. And in that API endpoint, what we're doing is basically returning the user's first name, last name, email address, company, Twitter, Hunter, Lana, Avatar URL. So let's now imagine in the Nitro Help web application we're consuming this API. We're using this part of all the details from the server side which is coming. We're using all the things in a proper way. And that's a good thing, right? But now what happens is since Nitro Help uses the same, now the visit application also needs to use some details of users to be displayed on the visit. And it only needs the name of the user and the avatar. It does not need other details like what is the email address, what is the company name avatar URL on all the other things. And in that's why what happens is in the visit we are over fetching data. We are asking for unnecessary data which we are not going to use anyways. But GraphQL comes with the benefit of that. What GraphQL does is basically whatever data you ask for it only returns only those fields. It does not give you other details which you do not require. Like in case of visit we just wanted ID, name and avatar. We'll be asking for those things. We'll be getting those things. And similarly if you need same details on the web application you would be getting those things. So that's the first advantage you get using GraphQL. Second advantage which we get is you get many resource data in single request. So for this, this is a live screenshot which I've took it from our application. And here if you can see it, if you do not it's okay. There are four to five requests which are happening. So I'll just explain those requests. So first there is a request which is happening for default views. Second for agents and third for tickets. So basically what is happening is to load that page we're making multiple round trips to the server. So we're making multiple API requests to which the page load time may be slow and the user experience kind of maybe would be slow in a lot of cases. And we want to avoid those things in as much as possible. So if anybody of you are doing multiple round trips that's not a good thing. And you should try to avoid those things. But with GraphQL what you could do is you could make one API call and send all the query string for all the things you need. Like for tickets, agents and default views you could make one just one request and within that request everything would be resolved. At sometimes at different places you might have a requirement where you want tickets to be listed faster or agents to be listed faster and then the rest of the things to be coming up. So GraphQL comes with an advantage of directives and all those things where lazy loading happens. But it always updates your views but that's a different advantage. So this was the second advantage we were getting in NitroHEL if we were going to use GraphQL. The third thing is GraphQL is declarative. So let me just explain this with a scenario. So a lot of here are front-end engineers I think, right? I'm assuming a lot of people work on front-end side. So what happens is sometimes when you have big teams where front-end and back-end engineers work in different silos you, the back-end engineers are still developing the APIs and they could not communicate what the API endpoint is, what details would be returning and what is the verb and all those things. So in those cases if you're using GraphQL you could assume that in the user's endpoint you would be getting details in such a way. So if you see, if you're asking for these things you would be getting that in similar way in just the in the data namespace which is a plus point for you because you could start building your components as soon as possible and also it's coming in a declarative format so you don't have to worry about if somebody does any changes to the attributes which an API endpoint is supposed to return. So that was the third thing. Fourth, GraphQL is strongly typed and I think a lot of people should agree that strongly typed is a great advantage because you'll be able to catch a lot of bugs and a lot of issues at the development side which could happen mostly due to the data being ambiguous. So in large applications you do not have a local system being configured for to have large amount of data, right? So when it goes to production it starts to break and since if your language is strongly typed what happens is you are able to catch those kind of issues earlier and being able to work on those faster so your Friday night is saved. All right, also the last advantage which we could see in Nitroil is using the powerful developer tools like GraphQL and GraphQL Playground which these are some introspection tools what happens is with these tools we get couple of benefits. First is you do not need to you get all the documentations on the tools directly whereas in REST if you want to do documentation you have to either use the Agri API docs or some people maintain it in the Excel sheets or something but with GraphQL you are able to see all the documentations. Also, both front-end engines and back-end engines could play on the playgrounds easily because they would be able to know what is the input is expected by the API and what output JSON it would be returning. So these were a couple of advantages we could see right now due to which we thought GraphQL is going to be a very, very powerful tool to be used in Nitroil because we had four different applications and in four different applications we assume that when team sizes grow you would be able to see a lot of people being in trouble if you start using REST. And also, okay, yeah. So these were some of the advantages due to which we chose to use GraphQL and I think if people do not know GraphQL you should look for these advantages in your applications as well. So yeah, wow, amazing decision, isn't it? So what happened was after taking this decision and using GraphQL for a long time in our application our team was very small at that moment. We were doing this as an internal product for our company and not as a business. So since we are a service-based company we have to have a billable hours to have everybody a good salary, right? So our team started to grow, a lot of people started to be onboarded on this project and it started to increase from three to four engineers to like 10 to 15 engineers who were working on daily basis on this project. And that's when we started to see a lot of problem and that's when we were like, we were solving one problem but also we were burning at other places and what were the things which we were burning? And that's where we had to stop, we had to think whether, okay, are we doing the right thing or not? Are we using GraphQL in a proper way or should we stop it? And so that's where we retrospected our things and we had to understand, okay, that's funny, okay. So we did some analysis and based on that analysis, we came to our current situation, that is the climax which I talked about, we reverted back to rest. And the couple of reasons which we listed out which led us to take that decision, I'll just speak about those and try to get everyone have a good perspective about it. So first thing, learning new technologies costly. So I think everybody here should agree. So here, I think more than only two, three people have no GraphQL and you guys, if you want to implement GraphQL, you all would have to learn GraphQL and then start working on it. So like I said, in our case, the team size grew from three to four engineers to like 10, 15 engineers working on daily basis and all these engineers come with, so these engineers may be of different type. Some may be freshers, some may be experienced steps. For freshers, the company has to invest in learning, react, rails, GraphQL and all those things. Now, it becomes very costly and for experienced steps also, some might know GraphQL, some might not. And for those who do not, they have to invest in learning GraphQL. So which is not a good thing. And after learning the technology, there comes another set of challenges. You do not have the hands on experience on it, right? You know the syntax, you know how it works. You know where to debug the code and all those things. But what happens when the real life situation or where a problem statement comes to you in form of issues and those issues when you have to solve, the people who are newly learned have to invest in understanding what is the problem, have to do a bit of research, investigate and come up with a solution. And maybe that solution is not correct, maybe that solution is not trustworthy. So we saw this problem and we were able to see that. Another problem which we see and it's since we are a service-based company and I think a lot of people could relate to it. In service-based companies, you have a lot of different client projects. So what happens is not all the client projects would have GraphQL, right? And when a new fresher who has learned GraphQL has worked for like six to seven months on this project and they have a good amount of hands-on experience that they should be shifted to a client project, that's when they say, I do not know REST. How do I do REST? So that's a problem. Now people have to invest in learning REST as well. So we didn't want people to learn new technologies just because it's trending and it's very good. We also need to think about our company's motto. The second problem which we saw was maturity of server-side and client-side GraphQL technologies. So let me explain. For people who do not know, GraphQL is just an enabler. What happens in GraphQL is you're just sending a query string on the internet and expecting a JSON to be returned, right? But on the client-side or on the server-side, how GraphQL passes those queries and how does it return the JSON is completely up to the technology stack you're using. So in our case, if I'm using Rails, I have to use GraphQL Ruby on server-side. And on the front end, if you're using React, you could use Apollo, you could use Relay, which has been developed by Facebook. So in those cases, you have to figure out the solutions for those things. So I recently was at GraphQL Asia in Bangalore last week and I saw a lot of people having different opinions about this thing. A lot of people were saying GraphQL on client-side is very easy because you just have to consume the API, right? You do not have to do a lot of things and build the components. But a lot of people said GraphQL on server-side was difficult and some people had an opinion. It makes their code structured and all those things. But we look into it, why GraphQL on server-side and client-side both were difficult for us. Firstly, we started using Elm with GraphQL and Rails. And with Elm, we saw a lot of difficulties. We were not able to do very small, small and trivial things, which we could do easily with other technology stack on the front end, like if you have JavaScript or React. So that's why we had to eliminate Elm from our code and we had to migrate it to React first. And then we used React, GraphQL and Rails and then we moved, removed GraphQL as well. So that was the first part and we saw a lot of difficulties in using GraphQL with Elm and that was because Elm was not that mature when we were using it. And I hope a lot of people who are working on Elm with GraphQL are trying to make it better. The second thing was, yeah, GraphQL on server-side is difficult. So I can assure you that it is difficult because I've faced a lot of difficulties working in it. I've been working on it for more than two years now and I could see a lot of problems in it. So let me just explain this with one of the examples. So this is a live screenshot I took of our application where we're building themes, basically. So what happens is for different clients, we want them to have the ability to build a theme so that they could go and edit that template page. They could change whatever the way the page looks. Like if they want the header to be changed or the header footers to be changed, the page contents to be changed, that could be done. So in that, we wanted to have a file upload feature. So what file upload is doing is basically, it's updating the background image. The blue area you could see, that blue area would be updated. And to have file upload in REST is very easy, right? To do file upload in REST, you just have two methods. Either you do it via multi-part form request or you do it via base64 encoding. But doing multi-part form request using GraphQL is not that easy because like I said, GraphQL just sends the query string over the internet and expects the decent response. But in our case, we were not able to make multi-part request. So I did a lot of work, I did a lot of research on it. I tried to build something out of it. And I was able to make a multi-part request, but the problem arises on the server side. Like how would GraphQL pass a multi-part form request query string which has been coming? So you have to write a monkey patch on the server side to make it pass. And once you do that, all the things, and you expect, okay, now it should work. Now the image has been stored in your database as well as on your cloud. And we saw that the images are getting broken and it's not working. So all the work which I did for three weeks, all in vain. So we came up with a solution called as Direct Upload to Cloud, which is a well-known solution. What we are doing here is basically, we are just uploading, we're bringing the signed S3 URL first and uploading the image to the server associating it in the database. And when user clicks on save, we're just referencing the image back in the database. But to find out this solution, it took a lot of time. And maybe this solution might be a good thing, maybe not because your server already, or your cloud already has the image. What if the user does not click on save? The internet goes off or they click on cancel. Now you have to worry about removing those things from your clouds as well. And this is just one example, but you face a lot of difficulties in a lot of different ways when you start to use GraphQL on the server side as well. So that was the second thing. The third thing we noticed was performance. So why we were able to see a performance issue in GraphQL is because GraphQL does not over fetch data. And yeah, one of the advantages which is of GraphQL is not over fetching of data was leading to a performance issue on server side. So I'll explain that with an example. We have seen this n plus one queries here. So here what we are doing is we are making a query for post with a limit five. So we are just pulling five posts with title, author details, authors, post name and all. So here what happens is when the request comes for post, you will be able to see a select query being fired for fetching all the five posts with limit and all offset being set. But since GraphQL does not over fetch data, the title would be resolved easily because it's just the property of post but author is an association. So it could not preload those things because we do not know whether GraphQL is going to ask for author details or it is not going to ask. So due to which we saw that all the five posts, it made five requests due to which we saw this n plus one queries issue. To be honest, there are solutions to avoid this n plus one queries problem. There are some batching techniques which have been written by Facebook or data loaders which they have written. You could see that, you could use that as well. Query depth, I'll explain this later. Okay, processing error in GraphQL is very difficult. I've struggled a lot here as well. So what happens is in GraphQL, you have three different types of error. One is first is error while passing a GraphQL query. So let's say if you have not defined a query in your schema, in your GraphQL schema, it starts to throw an error and the error message looks something like this, message, line, column, theme. Now nobody understands anything from this and there's no way to make it in a human readable format or in a better way. The second error which we get is while type checking, so since GraphQL is strongly typed, if you're missing some types or if you're instead of passing in a string value where GraphQL is expecting an integer, you, oh, sorry, I said wrong. If you're expecting a string value and if you're passing an integer, it starts to fail and this is how the error looks. So you need to handle these kind of errors. Apart from that, you have execution errors to be handled which is the real-time scenarios which we face every day. You have authentication errors to be processed. You have validation errors on your database which are returned to make sure that user do not make ambiguous, or do not send ambiguous data and you want to avoid such kind of things. And this is just one validation I added for Titan which says, title can't be blank. But if there are multiple validation errors due to which the query is failing, processing that becomes a bit of difficult and there are a bit, that was not a good thing for us. So best practices, I think it's clear on the server side, client side, there are no best practices been defined. Like I said, even if you design a file upload solution in GraphQL, if it has been done using best practices or not, or if it is the correct or trustworthy solution or not, it's not known. And also we saw a lot of issues, like just skip this, but let's say if you're doing a user update in that user update query, you're expecting a user input where name is mandatory and immediate manager is. But you want to reuse this user input because for create also, create user, you also need the same thing. But what happens is in the visit app, you just want to update the name of the user. So in that case, the user input could not be used. So you need to have best practices to say that, okay, for update, you need to define another user input. Frequent updates, so the packages where, since GraphQL is still developing, if there are frequent updates on your packages or tools you are using on the server side, you have to keep on maintaining your code a lot. So which is not a good thing. So that's why we reverted back, I had to rest and are happy with what we have right now. So what are the key, some of the key takeaways from this entire session. So we saw what are the advantages of GraphQL or REST, we saw what are the disadvantages of GraphQL on client and server side. And now we know, there comes the question again, do we, what should we use? Should we use GraphQL or should we use REST? So we have some, I think this should, I think everybody should be able to relate to this. So if you're using, if you want to use GraphQL, you need to see if you are using it, you're working in big teams where your front end, back end team is working different. You have a lot of people working on the application and there are a lot of different applications to be built. And also you're handling a huge amount of data. So if you're handling huge amount of data and a lot of people are working on this application, also make sure if these APIs are not been exposed to external users like GitHub exposes their APIs or a lot of people have to make, like PayPal has, PayPal or Stripe has their APIs been exposed so that we could integrate Stripe, right? So if you are building applications, something like that where you do not know who is the external user and who would be consuming those APIs, in those cases GraphQL plays a very, very important role. And I think that's where you would love using GraphQL. Use REST when you're working in small teams and in a very controlled environment. So just summarize it. So use REST when you're working in small teams. If even if the data is large, it does not matter because REST has been very mature enough on a brief front. And see that if you're working in a controlled environment where you do not want to expose these APIs, it's better to go with REST than GraphQL. So I rest my case here. So thank you guys and thank you for your time. Thank you.