 Hi, good morning, and this is Anitha from Matt Street then I work with the engineering team Building large-scale web applications and microservices using Python and I'm a proud mother of two So today we are going to talk about building graphql API with Django So first I'll take you through what that what are the topics that we are going to cover through the next half an hour So you're going to look at the graph query language background like why and how it came into existence and Compare it with the rest API's and we look at the basic building blocks of graph query language the schema the types the queries mutations and the resolver functions then we'll take up a very simple use case and We'll see how we can build a Django graphql API server for that use case And then we'll try out some more queries and mutations using the graphql ID Briefly introducing graph query language. It's a data query and manipulation language for the API's Something like we have a sequel for databases. We can say we have graph query language for the API's So graph query language is basically a standard for developing API's to describe the data That is available with a server using a schema and then we can define queries, which can be Like the client can use the queries to request whatever data it requires and the response is going to just have the data that he had Sorry Okay The response is going to be just the data that he had requested so Traditionally developers web developers have been using our rest API's for developing their web applications and we all know that rest API's have satisfied all our requirements so far and We have different URLs for accessing different data objects. We have the usual Crowd methods like we have get a request for retrieving data We have a post put and delete operations happening for any change to the data and So how did this graph QL came into existence in the first place? So back in 2012 when Facebook was revamping their mobile app web app like mobile applications They figured out that they had a lot of issues like the mobile applications were crashing and there were a lot of performance issues So when they were trying to fix these issues They figured out that there was a lot of inconsistency between the data that was being returned by the server and The data that was actually required at the client end So in order to fix this they saw that there was a lot of Developmental effort required at the server end So there came a requirement for an API which would give power to the client to just query for whatever data it requires and This was hoping to solve their problems of performance for the mobile web app mobile applications And that's how graph QL came into existence within Facebook They were using it for several years maybe two three years and then around 2015 they open sourced it for other people and the community and as such like there are a lot of programming languages which support graph QL today and There are a lot of organizations which have actually adopted graph query language and they are using it in their production systems right now So it basically supports reading to writing and also subscribing to data So the server can actually send data to the clients based on any events that are happening and There are it can easily aggregate data from multiple sources So you might have some of your data residing in a maybe an rdbms some of your data residing in a maybe a Redis cache It's very easy to aggregate data From these different sources and put it in a single request and send it back to the client and the main Concept here is about the request is the whatever is being requested is going to be returned in the response nothing more and nothing less and As we see the logo of graph QL we can see nodes and we can see edges So this is how data is visually a basically visualized within the Graph QL server so the nodes or the data objects and the relationship between them is the edges And this is basically represented as a graph So next let's compare rest and graph QL APIs where do they stand apart or is the difference between them? So the first end is like we have different API endpoints for fetching resources in the case of Rest API so we know that if at all we need a page to load with different kind of data we might be calling different API's to actually retrieve all the data that is required and This causes a lot of round trips and this can even cause load lead to latency in a page loading You know in the in a UI basically so in graph query language We have a single endpoint which is going to collect all the data that is required that was requested in a query basically So if you see there are also some nested queries which can be called in made in the call And so there are for example if you want to collect a number of metadata for a particular object Maybe there will be related data in other objects. This can all be performed with a single query single API call Okay, in the case of rest we have more control is given to the server so the API requests are defined at the server side and The data structure that is going to be returned is already Programmed at the server side and the client has only has got to make the call and receive the data that has already been Predefined at the server end, but this can also lead to a lot of data over fetching and under fetching So the client will fetch more data than is required and then pass through it drop Whatever is not required and then use only a minimal data maybe or sometimes when there is a requirement that it needs some Additional data, which is residing in the server Then they had to wait for someone to go and make changes to the server so that the data is being returned So this is the case with rest API. So we call this problem as data over fetching and under fetching. So in this In graph query language, we can see that once the schema that is the data that is going to be Residing in the server is defined that it's free the client is free to go make any changes in the query and get Whatever data they need they can get get as less data or as more data they want So this basically solves the problem of over fetching and under fetching and in this world of mobile applications We it is important that we make data loading very efficient and also we might have several different clients Basically using a single server and each client will have a different requirement They will probably there will be a client who just needs a bare minimum of metadata That might be some other client which requires to show the whole lot of data So it's now the powers on the client side to just modify their queries and receive whatever data that is required by them Okay now in this world of like where new products evolve and the product iteration happens Very fastly like we there'll be a lot of UI changes required Maybe that'll be usability testing results and then we use our feedback and based on that There'll be a lot of UI changes happening and every time a change happens in the case of a rest API The you know the process is like the development cycle itself is kind of along Like long like that'll be a back-end and front-end team discussing about what now how what data needs to be queried or returned from the server and then the back-end team will go make the changes and then they'll be The API is to be provided and then there'll be an integration happening. So this basically increases the product cycle and Development cycle basically so graph query language when it is used if the schema is going to define all the data That is already available with the server then it's the client the client is free to go and Make the changes query at his changes to the query at his end and just get whatever data they need so that the development cycle is very quick product iterations are faster and this also Ensures that the back-end and front-end team they work like they do not depend on each other and The development cycle itself they have a different pace in their development cycle for both back-end and front-end We have we basically give more control to the client Okay, and the case of rest API is we have this versioning which we have to maintain very stringently and We have to ensure that these minor versions do not have any breaking changes And when there are some major major versions released Then the client has to ensure that they use a right version to make the API calls to the server and if at all So that the back-end team decides to not support any of the older versions then the right communication needs to go to the clients and So a lot of back-and-forth and a lot of communication happens But in the case of a graph query language We can add new fields or new types to the schema without affecting any of the client queries Which means that we can just maintain a single evolving version and still the client has control He does not have to make any changes to keep in pace with the server changes They can just they have control of what data they receive because Basically, they request what they want and they receive that So we have basically when we want to build a graph query language server We have two basic components that we have to consider one is like the schema which is going to decide or define the structure of your API and another is the resolver functions which is going to decide the behavior of your API So schema is basically like a blueprint. It is like the save of the server's capabilities It is the data model that is basically residing in the server app server and Resolver functions is like the actual implementation of your API It will decide where the data is going to be fetched from for each of the query Okay, so as we see the building blocks of graph query languages like the schema, which is the And we have the resolver functions schemas basically telling the client these are all the data types associated with the App server and these are all the queries that you can possibly make and When we say queries it is only about the data that is being fetched So these are the different kind of data fetching that can happen with the server and it's analogous to our get request in our arrest and The mutations are basically the changes that we can make to the database like we can create a new record or we can Update something we can delete something. So all those are mutations which is analogous to our post put patch delete methods in rest and Then we have the so just defining these is not enough like it is only defining these are the capabilities But resolver functions are actually implementation of the API So they decide where the data needs to be fetched for the query is called what data needs to be fetched for that particular query that is decided by the resolver function and One very important thing is like we have this graph Ql query which can integrate data from different sources your some of your data can maybe Come from a different API itself Graph Ql API or maybe even a rest API some of your data might be lying in a rdbms Some might be on your a disk cache and a single query will actually It's very easy for it to aggregate data from different sources with the help of these resolver functions Because this resolver functions is the part where we decide where the data is going to come from Okay, so to bring up a graph Ql server. What is that that we are going to do? Practically, so first thing we'll define a schema this within the schema We are going to define these are the different object types or the data types that are supported by the server And then we'll define query types So these are the different ways which a client can query a server That is what is defined within a query types and then these are the different mutation types That is the different kind of data modifications that can happen So all these are defined within a schema and then once the schema is freezed So the back-end and front-end team can go and start their own developmental work They don't need to have any more discussion further than this so then we come back to Defining our resolver functions at the app back inside and The resolver functions basically decide when a query is called What is the data that we need to retrieve from where so that is defined by the resolver functions And after doing all this book put all together Like basically make a schema with the defined query and mutations. This is nothing but Like instantiating your class So once this is done the back-end the graph Ql server is up So let's look briefly about what are the different types and what are the Kind of data that's available like how do we define different kinds of types within the server So types are described the kind of data that's available in the API So if you can see actor is an object so different objects are defined and within them we can see Fields being defined a field in itself can be another object. So this is the way we also define relationships between the objects So this is basically provided as a schema definition language within a graph QL Which is a simple syntax which we need to follow to define the schema So we have a query here, which basically the queries like I said, it's like fetching the data So we have at when we specify as particular ID We will get only a single object in return and when we specify We want a listing API with all the actors or all the movies then we get a list of objects So this is a basically this follows schema definition language And then we define a schema by adding all the queries and mutations which we have defined We'll put it together in a form of schema Okay, now let's look at building a Django GraphQL API for a online movie store Take it a very simple use case where we have just two tables They are like we have a table called movie and then we have a table called actor the movie table We have it's related to the actor table like in with one too many relations We can have a movie can have more than one actor So it's a very simple use case for which we are trying to develop a Django GraphQL API So to use this we have an off-the-shelf library graph in Django Which provides a lot of features for you to develop a GraphQL API on top of Django It's very easy to use and we have it supports Django 2 and versions and above And it connects basically what it does is it will connect the models from our Django ORM to our graph in object types That is all it does and it's very easy to just get our app server up and running Using this So we have a short demo So we go about Just quickly take you through what we will be actually adding as pieces of code just to make you understand It's going to be sorry So we have the we usually define the models for our tables as like any other Django application And the one need to hear difference here is we are going to have a schema file here so Okay, we are going to import all the models and This is the one file where we are going to define everything related to our schema And this is the only file that's going to make the difference between a Django and a Django GraphQL So we are going to define our different object types first maybe an actor type and a movie type which is related to Which is related to a model here each of the model object type related to a model then we define something called a Query so these are the different kind of queries that is possible So we can see we have the list queries and we have the retrieve queries basically and then we are doing some resolver functions Resolving the actor so these are the functions which decide what data to retrieve from and then we have the So once these queries are defined here and we put in a schema with these queries Then the client is free to start making the API calls like this client knows what kind of data is available at residing with the server Let's also look at how we define mutations like for mutations Basically, we are going to make changes to the database so that has to be some input given and that can be in the form of an object and So we have input object types defined here actor input movie input and we create the mutations with the Create update our usual like how we define our rest API is like where we can do a create update Maybe using serialized rest framework. We will do a create update delete the same kind of methods classes needs to be added here So we'll have a update movie a delete movie delete actor and all of these is defined as a mutation and class and then we'll add a schema here and putting together the query and the mutations and We have a urls where we have a single url here as compared to our rest API is where we'll have a huge set of urls each url representing an object resource here It's just going to be one single url Then we'll add the Basically, we'll add the graphene Django to our installed applications and we'll have We are good to go Okay, so let's look at the So when it runs on a when we start the Django server basically We will be able to use using the graphql endpoint. We will be able to use a graphql ID, which is a An inbuilt tool which helps the developers to try out their queries and mutations and If you want we can turn it off with a single single simple syntax So this is very useful to see how our queries really work So now let's look at we have a lot of queries written here. So one is like get all the actors So as you see I want all the actors and with their ID and name So let's see what it returns Okay So I'm able to see a list of all the actors that I've stored in my database Similarly, let me see what I've written for the query. So for the query I want all the movies their ID the title and all the actors details as well So pretty much everything that is there in the database. So I need everything so that comes up So I have a list of movies and the actors and all the details that has been stored. So let's say I want One leader identifier Okay, I don't need The name of the actor. I just want one client. They feel she just wants the identifier Sufficient so let's see what so that based on the query the response keeps changing So there is no change to the server side server side just describes a schema and that's it Whereas the client has control and power over what data it can receive and let's say the someone is not interested in even looking at Actors they just want the information about the movie just the ID and the title Okay, so we just get the data that is requested so this is a power of graph query language and this spot sets it apart from rest and Let's look at okay now. Let's look at maybe we have a list of actors Let's try to add a new actor. Maybe create actor Okay So any changes to database has to happen through mutation and not query query is just a data fetching. So we will Create an actor here. Okay, so now I create an actor with ID 8 now I want to update this actor name. Maybe I want to make it Wilson, Jr So, let's look here update actor Okay, I need to add eight here okay and Update actor. Okay. It's updated now and For some reason, let's say I want to delete this actor. Okay. Let's first list and see whether it's all appearing here Get all actors. Okay. Now I want to delete my Record that I just created Okay, I've deleted it and Get actors. Okay. Now, let's see if I'm going to change some syntax. Maybe I leave out something here I Try to delete an actor. Maybe we just already deleted. Let's see what what it does like So it gives a very meaningful error message So graphql has an inbuilt parser and validation in bitparsing and validation happening Which is not available with rest where here like any kind of error a message is like very meaningful And we know what to look change in the query Yeah, pretty much done Organizations use this graph query language in production basically so we have Twitter we have Shopify we have Coursera. We have a lot of organizations are using this in their production systems And even public they are exposing it as a public APIs So now we come to the question of whether So does this mean that rest does not have any more Purpose to serve or is it like all of us are going to just throw a rest and move to graph query language? The answer would be no because rest is here to stay and Graph query language. Yes. It is very powerful in a lot of ways It provides a lot of Control to the client system especially in today's world where we want the product iterations and the development cycles to be very Faster and we have this is the world of mobile applications. So yes graph query language is also here to stay And I feel that like both rest and graph have to work together to achieve our purpose So if we have like basically any developers, you know DNA is like that when we find something new and interesting in the market like we would like to go and try it out and implement and adopt it That is there in every developer But when we really try to use something new that is in the market like if you want to use it enough for a particular use case What are the different considerations like we have to first think about whether we have a set of problems, right? We might have some predefined problems in our end And if there is a solution that exists for the problems that was developed by someone already and it's provided off the shelf Then there is no harm in adopting it and using it for to solve our problems We do not have to go and reinvent the wheel basically But if if there is something that we is new and we just want to try it out and use it because it is new I think that will not be the right way We have we'll probably It's depending upon each use case So if you have like let's say for example, you have a requirement where you need to upload files Graph query language doesn't support it as of now So there are a lot of ways in which rest does stand apart and it has to be It will stay whereas graph query language serves certain other different purposes like if you have a single server Or maybe and you want different clients accessing it with different purposes and different sets of data Then you can very well use graphql and both rest APIs and graphql APIs can be used within the same app server basically so I think that Coming to the end of my speech like takes any questions. Thank you Hello Yeah, my questions regarding the authorization and authentication principles So suppose we have a multiple clients and they have already given some ad authentication and some kind of authorization Can I such make a authorization to take only those data which they required not the all? so You mean to say about the normal login authorization and authentication system Which we can implement through our usual Django thing here because we are going to build graphql APIs along with Django Here this API is not an architectural style actually. It is just a specification. So So using Django authentication authorization, you can always provide the required Authorization to the clients and apart from that like if you want to restrict any data Then it has to be done through your schema and maybe your resolver functions Apart from that the queries are free to for the client to use Hello Hi, very nice talk. Thank you. I just want to know at the back-end level which databases that graphql actually sports Graphql actually supports all the databases like mostly Postgres Redis it even supports graph DB So and also other APIs because all of these are like put into the resolver functions. It is so so graphql is just a Way of developing the APIs. It's a specification basically So how it cannot apply to any kind of database it can retrieve data from any data sources That is how it is Hi So my question is when is it? Why not use graphql in every case and when is it when is it better to use the rest? means Why can't graphql directly replace the rest that that is my question Yeah, the one question is like when I said we have a Case where we have we need to upload files. It is not possible with graph query language And as such graph rest APIs are Like have been there for long and I would say that one important reason is like we Especially with Django. We have a lot of documentation and community support Which I would say like it's not currently present with graph query language Maybe it will evolve to that point where we can start use Placing rest. I'm not very sure because there's a lot of things which has to be developed But right now I think it can work in conjunction with rest and solve our problems of any use cases whatever use case we have Hey Anita, thank you for the talk Just wanted to know like is the session based authentication possible through graphql I believe that graphene does that for you is so like what when we tried in our Organization when we tried developing a prototype we were we wanted to stick to Django basically because we trust in Django's authentication and Giraffql was only used for us few APIs in these cases. It's not used for authentication or Like you mentioned so So suppose it's not a greenfield project It's a like a 10-year legacy system and you want to build a graphql layer between the the rest API that we already Have and between the client so at that time can you tell like how do you do the authentication in that case? Like you have to pass on the session information from the browser to the graphql server and from the graphql server to the to your actual server So I'm not really explode that part. I'm feel free to write to me. Sure. Thank you so much