 All right. Hi, everyone. First of all, sorry for this. This is like, I'm feeling pretty cold, so I just wore this. I'll be talking today about GraphQL. We are short on time, and I want to cover like give a brief idea about what GraphQL is, and then try to compare it with how you basically today build or use REST API in your real applications. So I'll try to cover a bit of ground on those particular places. My name is Vipul. I go on Twitter as Vipul and Sward. I run this consulting company called a Saloon, which is like a new one. We are still growing. We tend to blog a lot on various things, from Ruby to Rails, as well as whatever new things that we are working on. You can catch us on our blog over here. I, apart from that, most of them I try to travel and work in different places. And if you are on, I don't know if you have heard of Nomad List, if you are on Nomad List, we should definitely chat. I think this specifically also is a good area where a lot of people come and work out of. What this also means is that since I'm traveling, I end up in weird places or get stuck in weird situations. One of them is last year I was stuck in this typhoon, which was in Kyoto. I survived this. I don't know how. I was on the ninth floor when there was a 7.2 earthquake. Or smaller things like there was a blackout in Manhattan after 40 years, and I got to see that. Or a couple of weeks back, I saw a, I don't know how that happened in Singapore, but that didn't come in new. So we don't know. Things happen. And this makes me sometimes feel like, oh, am I living this kind of a life? But I'm happy to be here and hopefully meet you all and have a time where it's not these kind of eventful situations. Today, we'll talk a bit about what GraphQL is, and then how you can actually use it today in your Rails applications. GraphQL came around 2012. It was built around that time. And then later, it was released in 2015. During that time, we were facing, at least for our team, we're facing a lot of issues around having to maintain REST APIs or having to deal with versioning in various applications. Specifically, these were some of the concerns. Let's say you have an API where you have a resource, and then that resource has many other objects. So what you do is you end up accessing post, and then you have different other API calls, which lead to n plus one kind of queries to fetch other data. And in general, you have this kind of under or over querying of data, where you keep on fetching more information from REST. Because these endpoints are absolute, so you either fetch more data or you fetch less data, and then you have to go around and make another trip to fetch other data. While working on big, large applications, I've faced this huge issue where maintaining APIs ends up becoming a headache wherein, let's say you have multiple API endpoints in Rails, which might internally themselves use from your models, they might use the same methods. What ends up happening is changing something on one part of one API ends up messing up with the different APIs from mobile, or also incrementing various versions and having backward compatibility. That makes a little bit of mess in terms of maintaining APIs for different applications. And that specifically led us to use GraphQL, and why GraphQL at that time got caught up and is still being used by many different companies like GitHub or Shopify now. A quick tour of what GraphQL is, or what it basically means. So to begin with what you do is you define your schema of how you would access information, and then you would use what is called as this GraphQL query language, and then what it allows you to do is provide these kind of queries wherein you say, hey, give me this information about this hero and specify the attributes that you want to actually and then GraphQL will only provide you with that information instead of giving it hundreds of different fields from one object. You could also do things like this wherein you can specify relationships on an object. So let's say you have a model post which has comments, so you can specify that, hey, along with this post, I also want comments and I want these five different fields, only these fields from that particular nested object. GraphQL comes out with a specific type casting, sorry, typing, like type mechanism, which allows us to have this kind of way of defining your schema and provides us with type checking on the client side as well as on the back end. Finally, yeah, finally it also allows us to have, like that's one of the major reasons why it was, like that's one of the reasons why it attracted us is of having better way of managing versions or deprecations in your APIs wherein you can keep on exposing new fields or you can end up saying that, hey, now this field is deprecated and market is deprecated and then the clients can know or inspect those things and then handle those on their side. Instead of us having to convey every single time, hey, this API is now this and then now you have to make some changes based on that. Before we move on, I'll give a brief demo of an application that we'll be referring. So this is an application that we internally use. It's called as change log and what it basically does is that you can connect a repository over here, it's like you can just connect a GitHub repository and after you connect a repository, what it does is basically pulls down all the commits from that repository, like here I've connected the Rails repository and it pulls all the commits from it and it's a very basic application for indie developers wherein you can publish the commits and create blog posts and keep your audiences like, oh, this is a new feature that we have introduced, pull this information from the commit messages. So to note over here, like this, the model over here is that you have your project, you have your commits on the project and then those commits become posts. All of this is powered behind the scenes by GraphQL and if you see over here when I load this page, when I load this page, it ends up calling GraphQL endpoints to actually fetch the data and we can inspect what kind of information it is trying to access and so what it does is when it loads from on the client side, it uses client library called as, which is called as Apollo and it creates or sends queries on the backend which are formatted in this fashion and which help you to fetch what kind of information that you would like to have and so here we can check that, we can edit what kind of information we want so it's hard to see over there and then basically fetch information from the backend. We'll come back to this after. On the, so that's about like, basic introduction of GraphQL. On your Rails application side, what you will end up implementing is making use of GraphQL Ruby for this implementation. Some of the important things that we need to look at or note about this in comparison to your REST APIs are these four concepts which is schema, your queries, your mutations and subscriptions. We'll go through each of them like a little bit and then towards the end compare of how they work with your general usage of REST. So basically you would end up adding GraphQL Ruby Jam and then you use, install, it will set up basic bare bones application for usage of GraphQL and then you can use the generators for actually creating types which are kind of typed onto your models, active record models and they expose this data from your models to your GraphQL API. And so basically after you have set this, what you do is you start by defining types. So you can think of this in terms of your schema migrations like tables. So every table, like a post table will be defined like a type over here and the type will have different fields that you might have on that you want to expose to your client. So here we are saying that, hey, this post will have an ID which is of type ID, title which will be string, truncated preview and comments which is defining like a relationship that the post will have many comments which can return like an array over here. After you have this type, you would define query. That is you define how we will be querying or getting information from this type by making use of queries. And so what you do is we define what is the object that you want to resolve or return from a query. So here we are saying that, hey, in this query I want to return a post, a single instance of a post and the type that is how it will be displayed is post type that we defined before and from the record that we actually fetch from the post method that we resolve, what we'll do is it will fetch from active record and then it will map the data that it has fetched onto the previous type that we have defined and return it as a JSON response to our clients. After you have defined this query, what you do is basically tie it with your schema and then you can think of this like your active record-based connections and then finally to actually use it in your controllers what you will use is this schema and the query that you're getting from your front end you will pass it through your schema over here to execute. You can think of this again in terms of active record in terms of this being like a SQL statement, your query that is defined over here which is basically a GraphQL query statement that you're getting from your client side which you just pass over here to schema execution and then it returns this kind of hash results based on the typing that it has done after fetching that data. We'll go a little bit of deep into types and schema and then come back to queries and mutations. So GraphQL has this language called a schema definition language and what it does is it defines how I would map it to like how you would define your tables. Here we define objects that you would end up returning to your front end. So here is a basic example of how you define a user wherein it says that, hey, this is a type of object called user which has these different fields. Exclamation mark over here means that this is a required field and it can have like arrays of fields which is friends over here. This basically maps on in Ruby like so wherein you have this field, email, your handle, your friends and then you can say that, hey, this friends has many and it can return many users. This is a basic type of, basic type that you can define. This shows like a brief introduction of how these many different types or relationship between the types can be and you can think of this again in terms of in your active record models wherein you have simple fields like single fields of strings like name is completed or so and so forth or you can specify relationships. Like you're saying over here that the owner is related with the to-do list. We can have lists where is like that will map to has many or you can have complex scopes of these objects which are defined over here based on like we accept parameters as arguments and then return scoped objects based on the relationships that we have on that particular object. The queries and the mutations, queries for fetching data and mutations for actually changing the data themselves are special type of types which again go under your main schema. And these definitions that we saw in our types which map to like the fields can be from like, from within the out of the box they support various types of information that you can support like we can support strings, integers, floats, Boolean, dead types, JSON types or like in terms of active model you can also create your own types like money type wherein you can perform typecasting and provide that as a scalar type of hey this field is a money field parse this and return this in this way in your graphical responses. It also supports enums and finally it also supports lists. So we have already seen like what you would use lists for specifying that in your particular type which might have association of has many you would specify this as lists which is like an array and then it in itself you specify what kind of a list it is. This can be used at various level wherein arguments are like when you have your parameters so you can specify that hey these parameters are a list of this kind of posts or you can accept that on your types as well where you say hey this is these are all the previous employees which are of this type employers of type employer and these might or might not be nullable. We also have these other types of input objects, interfaces input objects are like fill your parameters action control parameters are providing types for that interfaces are like you can provide interfaces and concrete examples of implementation for types unions can be thought of like polymorphic objects polymorphic associations or you can use polymorphic types in your GraphQL queries and then directives for excluding or including more information from the client side on your applications. Finally after you have this schema defined you would end up querying or getting information from the schema after your defined types based on that you may be making use of queries and we have already seen an example of that from front end what you do is you get a query using GraphQL query language and what you do is you just pass it to your schema to execute which returns a JSON response. You can use single querying or you can basically use multiplex wherein you can execute multiple queries that you receive from your back like from a client side and return in one single glow. Queries also take in context so you can think of this in terms of if you have a controller and your controller will have like the current user or it wants to use like routes and so on and so forth so you can pass this as a context to your schema and then take action that hey I'm trying to query this data but I want to get the data only which is accessible to current user so you can pass this as context and use that in your query. This was an example of variables so variables are parameters that you will receive from your front end and which will be used for filtering that data. It has other information like route value that is the inherent object on which you want to perform the query, the special operation name, the max depth since you're exposing your queries and in GraphQL we are saying that hey you can query within a post, within a query and then within that post itself it can have other relationships so you want to limit how many levels of nestings you want you can use max depth as well as max complexity of how much complex the clients can because that could end up to like DDoS or other things so limiting how much access you want to give to your clients. Here is a fuller example of how the query might look previously it was a generic query year what we are doing is called as resolutions so what we do is we define year we are saying that hey I want information about the commit like we already saw the commit and what it says is the information that I'm going to provide is of type commit so it says that the commit has ID or message of those fields it says it will accept an argument which is a parameter input parameter ID and that is passed finally to resolve wherein you use that arguments to actually find the record and you can also use context to find like in user information and other things and then finally the resolution the object which is returned it is type casted in the type that you're saying specified by the type and then finally it is returned as a response. Finally we have mutations wherein when you actually so those were for fetching of data but for actually changing data in your applications you would end up using mutations. Mutation again as we saw is just a special type and we can define different types of mutations which take care of other different things in your application which are of concern on your controller level. So those can be like CRUD operations those can be like session management you can expose it as a mutation or complex things like file management and different kinds of controller level concerns or side effects as you may say. Here's a fuller example of how the mutation might look. So from our example what we had is like we could publish a commit and say that hey publish this as a blog post and so this shows that how that would actually work. So what we do is we specify first of all we specify after the operation is done what is the response being returned? So that again is defined as a type and it says that hey this the response will have these many keys or this data after the operation is performed and then in your resolution and it takes like ID and the body of the post that it wants to commit or publish and then in the resolution you perform whatever business logic you have and then finally return it like typecast whatever response you have and send it back to your frontend. The last part of this in like concept in your GraphQL Ruby would be subscriptions which is basically allowing you to have streaming responses on your GraphQL querying which are implemented by action cable but again like we have a lot of other ground to cover so we'll leave that for now. So those are the basic main parts of GraphQL and I wanted to give that as an introduction so that now we can discuss of how or what are the various things of concern for us like when we start using GraphQL over REST API what are the other different things that we need to think about in terms of what are already supported in your Rails applications via REST. So some of them are like that we'll go through like first of all validation. So similar to like on your rack and your Rails application when you send something on REST it performs lots of validations of what kind of like parameters are sent or those kind of things. On your GraphQL side again whatever query is being sent it before it starts it performs validation. So here if in our previous example if we try to find some different field which is not supported first of all it will show us an error on the client side itself because the client already knows what is supported and not. So this provides us with information of already on the client side before even hitting the server that hey this field is not supported you cannot actually fetch this. Even if you try to fetch this on the server side as well from all the type definitions which it has it will perform validations and say that hey you're trying to access this field but this field is actually not available and based on that we can perform validation of what we are trying to query. The other part of this is supporting error handling again we are talking about before it even hits your logic business logic the validations and error handling on the GraphQL side. So we already saw the example of how query validation is done and how that if you're performing invalid query it will catch it automatically and return a proper response to your client side saying that hey this is not a valid query. GraphQL also takes care of these other things wherein since it has a powerful type system it knows violations in your queries or data that you have provided. So it might it on its own takes care of if you're trying to access a union or interface in a invalid way or you're trying to provide data which is not like null values for not null values. On your business side of things if you have a model and you want to if it's taking care of validations you could do them like user error handling wherein here if you see what I'm doing is it's performing this mutation and if it has some kind of errors we can catch those errors from your active record model and then map them and return them as a simple GraphQL execution error. This will create a top level error key and that allows us to provide a context on if you're performing an operation it will return an error response and say that hey these are all the errors you were trying to when you were trying to do this mutation. You can also provide richer errors. So let's say you have a form which like you know you want to provide your own kind of definitions of error response. So you can define an error type and then you can tie that together in your mutation and then finally when you're actually performing the operation build out your error responses and those will be typecasted to how you have already specified your own custom type definition and provide higher rich responses as errors in your mutations. Similar to your controllers on your schema level you could also catch all errors by using rescue from. So in your Rails controllers you can use rescue from. Similar to that in GraphQL schema what you can do is you can catch all errors by rescue from and then provide user friendly errors after those are being caught. One of the powerful features which I like or why when I started using GraphQL is what was blown away is introspection and what this does is it expose since like GraphQL has this type system what it does is it allows to already inspect what all things are supported and exposed from the API. What this does is it allows your teams to communicate easily. So after I've built my API I don't have to communicate via like Swagger or other applications that hey this is how you have to run your queries. You can then use introspection on your schema and what it does it allows us to have this kind of schema on your client side. This is not even like on the front like on the back end. So what it does is you can introspect or get information of hey this is an endpoint for some query what are all the fields supported on this query or what are all the like actual information of fields that I can access from some query. So this provides like a very powerful way of someone on the front and trying to get someone from the mobile side trying to get access of what actually supported from your application or not. Since like you're exposing all of these things you want to limit some of the things which might or might not be publicly accessible. So which is allowed by making use of visibility. So in your types or in your tables you can specify hey this field is visible only to this and this user. We already have this context that we saw. So you can say that hey this is visible only if this user is logged in and fetch information. And this allows to have what I like to say call us what is called a schema driven development wherein you define your schema and you specify it to your teams and then your teams can then access the schema and then build applications. Some concerns that when we started using GraphQL were of how since we are allowing the front end to decide what it is actually trying to fetch we don't have a good control of what number of queries it might run. So some of the things which we can avoid like having performance impact is by using batching or these other things that we'll see. One of them is lazy execution which you can do by like a basic object store or use these gems like GraphQL batch, batch loader or directives like defer. What this basically behind the scenes do is when we are sending some query instead of fetching or doing the post.find or something what it'll do is it will collect all the IDs it wants to query and finally when it is building the response that it wants to send back to the front end will it actually like return the loaded objects instead of querying everything. This is how you can hook the lazy executors up and then once you send these three queries it will actually perform the single query like find all the IDs together and then perform it as a single query. The other way of speeding things up is by using batching and this batching is on two levels. So in our application if you might note so this application is loading this queued commits, published commits and archived commits and when I do a page load all of these commits, all of this data is actually being loaded in one single. This is being loaded in one single query wherein GraphQL on the client side groups together given a time like let's say in 20 milliseconds everything is executed. So those things get bashed together on the client side and what you can do is then pass it to multiplex and return your responses. Instead of performing like end different HTTP queries it will batch those together and return responses in one and handle it on the client side as well. As well as you can use libraries like data loader on the front end and back end to group together or batch together your queries when you're performing these queries. Other big major concern that GraphQL always has been is caching since in GraphQL unlike REST you can use ETag and other things in GraphQL you're exposing just single endpoint of GraphQL. So this has a concern that you cannot use those features but basically you can use other things which can be used for caching. So GraphQL suggests that you have a unique ID and if you don't have a global unique ID you can also pair that together with type name and then use these for caching on your client side if you're using client library like Apollo, GraphQL on your client side it has a way of storing this itself. On the back end of course you can always use Rails cache or use a library like GraphQL cache for when you try to access this data. Things like Akamai are since like the GraphQL has grown a lot they are now working on supporting this in a better way. Versioning we already talked about this one of the biggest things that makes GraphQL exciting is supporting versioning in a way that you can communicate easily what is deprecated and not. And so this allows us to have a specified versioning wherein from your GraphQL Ruby you can say that mark a field as deprecation and give information of why this is deprecated and that is easily communicated with your front end as you can see over here and then whoever is on the user side of it can take care of how they want to handle their deprecations and remove those fields. Some other considerations since the GraphQL is text-based and JSON-based it allows us to have all of our responses being made over Gzip using React Deflate as well as behind the scenes it has you can use something like relay or other specifications to speed up your pagination. Finally if you're already using your REST applications today the way that we have seen in most of our client applications is keeping some of the things you don't need to move everything today to GraphQL. What you end up doing is slowly moving your individual REST controllers to use GraphQL like POST or single REST controller objects. And then finally we end up in a situation where some things like REST or authentication are left as REST. If you already want to support as well your REST as a GraphQL endpoint you could use libraries like Apollo Link REST to perform GraphQL kind of queries like using REST API endpoints. I think I'm out of time and that's all I have. I'll be around if you have any more queries or just would like to know if you are using GraphQL in your applications. Thanks.