 Hi everyone. Welcome to my talk. Who am I? I'm Patrick and you can find me online at with Patrick91 almost everywhere. I work at WebAgency which is called Think Studios. We do website for clients and also we have Internet projects. We mainly use Django but it really depends on what we are building so we change technologies quite often. But yeah, we try to use new technologies as soon as possible because it's good to keep up to speed with the new stuff that's going on on the web, especially on the front end. So the modern web, as developers we have seen the evolution of the web so from static website to website with small interaction to website completely interactive and one of the best practice is to use REST APIs for the communication between the client and the server. But yeah, REST APIs are good but sometimes you need something that's better than it because there are some issues. One of the most common issues is too many calls. So for example, imagine that you have an API that gets the user with an ID. You get something like this which is fine for example if you only need to see to show the user name but if you need for example the friend's names, you need to do a call for all of the user and this is as you can imagine it's not good especially for the user experience of your application website. So one solution is to create a new endpoint which is user with friends which will return the user with the friends and so on. But then you need also the avatar for the user then you create another endpoint. But in another page you just need the user name and the image in the avatar. So you create another one and so on and so forth. And then this is only one case but imagine if you have many endpoints it's gonna get really bad. So another solution like a workaround that you can do is to return everything that you can get from that resource. For example you can return the user with the friends in the avatar but then you are sending too much data you're wasting bytes. And it's not again it's not a good experience for the end user because you are wasting their money actually especially in foreign country. So you send too much data in this big block. One solution is GraphQL. GraphQL is a queer language created by Facebook around 2012 but has only made open source like two years ago around 2015. And they say in their specification that GraphQL is designed to build client application by providing an intuitive and flexible syntax and system and so on. This is really complicated for me. And I never read the specification because I always saw the example which is something like this. This is GraphQL. GraphQL is a query language where you can specify from the client what you actually need. For example in this case you are asking to get the user name, email and the friends name. And you get when you do this call you get something like this. So you only get what you actually need and it's really easy to use. But one of the most powerful feature and I guess also one of the most like feature is typed. So everything in GraphQL is typed. So basically your schema is going to have typed. For example for a previous query you have a user type. You just got a name, an email, there are strings and there are always there as you can see from the exclamation mark. And then you have a list of friends. And friend is another type which is going to have probably name and email as well. Then another feature is introspection. So basically every GraphQL endpoint is going to expose some metadata so you can get all the types. For example in this case you can use GraphQL which is an ID in browser. So it gives you how to complete on your API and the arguments and the fields. So for example it's getting the product ID to the name description and it's getting the picture with size 500 and so. So right now I've shown you the query which is basically the way to get data from a GraphQL. But also you need to change the backend data for example. Like with rest APIs you do a post request, part request or delete. So with GraphQL you always use one single endpoint and one single HTTP web which usually is post. To change data use mutation which is a way to mutate data on the server. And then you also have another operation type which is subscription. Which is similar to the query but you subscribe to the update street which is usually use web sockets. So a query is done, it's like this as I showed you have some fields and you can have also some arguments. So for example in this case it's going to get the human with ID 1000 to name the ID with unit of foot. But this is only a short time for the query. The actual extended operation is this one. So basically specify operation type. As I said you can have pre-mutation and subscription and maybe in the future they can extend the specification. Then you have an operation name which is basically used mainly for debugging so you get logs on the server without. And you also have some variable definition which includes the type that you define and then you have the selection set. And when you run this query you get the data that you ask for. But yeah this is Python conference so you want to use this with Python. Use this with Python you just use graphene which is a library that implements the GraphQL server. So you install it and then you can just import like this. You import the library, you create a class of query. In this case I'm creating a class which has got only one field which is a low. And then for each field you create a function which is called resolve underscore the field and you can return what the field is going to return. And also you can use the arguments and do some magic stuff. And then you can create the schema from the query and you can execute the query. But yeah this talk is mainly about Django and there is an extension to graphene which is graphene Django which is similar to graphene but it's got some nice features for Django. To use it you install like this and then you have to extend the installed apps with graphene Django and then you have to create a main schema which needs to be specified in the settings. My convention is to use a folder called API and a schema file and inside the schema file will be the schema which has been imported from all the other applications. Then you have to add the GraphQL view. In this case I'm adding the GraphQL view under GraphQL slash GraphQL and also I'm enabling graphical so I can debug the API without doing any code. And then use like this. If you have an ingredient model you can just import this and you can create an ingredient type with the Django object type that's provided by Graphene Django and it's going to create all the fields for you so you don't have to do any of these functions. You can still do it if you need to do some custom stuff but it's done for you if you don't need to change anything. Then you can create a query where you have to specify the query set. And this is something a bit tricky because since you can't do nested fields with Graphene you need to be careful that you're not doing anything. So you can't do anything with the API. There are 10 plus one queries because it's going to be bad on the performance side. So you can check the fields that are needed and you can do select related or prefetch related if needed. And then you create the schema from the query. So one of the problems that we had at work is to do a lot of things. We are using Django and it's easy to do authentication. GraphQL in this case is just a Django view, normal view. So you can use any method that you like. For example, we were using JWT tokens but you can also use session tokens if you don't have a single web page application if you're only using GraphQL to enhance some part of the website. And yeah, you can use any Django version. This is a different paradigm on doing query. So for the permissions, you basically, you don't really have permissions models but you have permission on the actual fields. Which is, I think it's really good because you can say, for example, if I'm logged as a super user I can see the user email. And if I'm logged as a standard user I can only see the user name. But if you, for example, need to have integration with REST framework, for example, you already have an API, this is something that is not working right now. And I made a request that you can have a look at it if you want. And you can also use, I'm using it on one of the projects at work because I need mainly some use cases to test and see if there is any bugs. Basically what I've done is to, you can use Graphin Django with Django REST framework serializer so you don't have to specify the serializer again, especially for the mutations. Yeah, then I would like to touch on a bit of the security. Because since you can do nested fields, some malicious user can do big queries. So for example, they can have like 100th level of nesting. So one of the solutions I think it's been adopted by GitHub, which is using FQL in production and also it's public. It's to just limit the number of nesting that you can have. And for example, if the nesting level is more than 10, they just stop the query because it's probably something that's a bit strange. And also you have long queries. Because since you can also specify arguments, you maybe you can end up with a query that's going to take too much time. And I think Facebook is doing something like this. Basically they have a timeout on the query. When the query is going to take more than one second, they just stop the query and they return nothing, which I think is what we should do because one second is already too much. So this is the back end part. For the front end, as I said, this is, you can still use any client that you like to do post-request to the web server. But there are two main libraries that you can use for doing queries, GraphQL queries. One is Relay, which is on your right. And basically it's a library developed by Facebook. It's only for React. So if you use React, this is probably one of the best solutions because it's supported by Facebook. The only problem is that the development is led by Facebook. So they do stuff only if they like. But it's really good. And the other solution is Apollo, which is I think it's community-based. And basically they have clients for vanilla JavaScript. If you don't use any framework, they also have clients for VJS React. I think also Angular and some other one. I was really fast on this talk, sorry. So I'm going to touch a bit on the front end part. I don't have slides, but basically with this tool you can do, there are some other features that I haven't told about GraphQL. But some of those are, for example, fragments. So you can have, like, some components that depend on other data. So you can basically, you can only do one query, including the components. And then you get everything with just one query. For example, if you have an about page, and then you have, for example, the user name in one place. And for example, you have the user fence in another page. You can combine the query from those components. And it's going to do only one query. And also, one of the issues is caching. Since you are doing post requests, you cannot use something like Barnwish or pure Django caching. Because you are doing post requests. So one of the solutions that's been implemented by both Facebook with Relay and Apollo is to use client-side caching. So Apollo is really good at this. Basically when you do a query, it's going to cache the results for you. So if you do the query again, it's not going to call the server. It's going to just return the data. And other solutions could be to use, to analyze the query that you are doing and do caching on those ones. But it's a bit harder than just pure REST APIs. Because, said, you are just doing post calls. And probably this is going to improve because GraphQL is quite new. But a lot of companies are using in production. Like Facebook, of course. Shopify and GitHub are the main ones. And they are really pushing it to the limits. And they are also contributing to the spec, which is really good. So, yeah, that's my talk. If you have any questions, please feel free to do it. And, yeah, thank you. Hey, thank you for the great talk. So my first question is how do you deal with pagination using GraphQL? Sorry, I do you pagination. How do you, yeah, how do you paginate? How do you deal with pagination? Oh, yeah, there is one of the ways using basically as come up with that sort of pagination system. So as I said, you can specify the arguments in the query. Let me see if I can find it. So in this case, for example, I'm specifying the ID, but you can also specify, for example, the start and the end. And I think, yeah, Relay is doing something, it's using like edges. So basically, instead of returning the list of the user, in this case, you will return a list of edges. So you can get the IDs and the, yeah, the start and the end ID. Maybe if you chat with me, I can show you some examples because without code it's a bit hard to understand. Thank you. And my second question is while using Django REST framework or some kind of a RESTful approach, you can really easily specify which end point is public and which end point is private. Can you do this via GraphQL because you have only one end point and can you specify that this data is public and this data is not public? Well, the answer is yes. But I don't know how to do it because I didn't have to do it. But I was watching a talk on GraphQL by GitHub. Basically, they are doing something like this. They have two ways to do this. The first one is since they have the API is public and they can also, for example, you can, with your application, you can log as a specific user. They have permissions. They check, before even doing the query, they check the fields that you are asking for and they check if this field is, can be accessed by the current user, then they run the query otherwise they throw an error. And the other one is the schema. The schema is public, usually. So basically, when you expose like some fields, it's going to end up on the query, on the schema, schema definition. And they have some metadata on the, on some fields that basically they say, oh, this query, this field is only for internal use. So when they are logged as GitHub, they can see that field. But when they are using it as a public user, they don't, it's not shown. All right. Thank you. Any more questions? Thank you. You said that a lot of companies use GraphQL already. For Django, Graphene, did you take any open source project as a reference to see their problems, how they handled it or would you recommend any open source project to look at? Sorry. Just starting with Graphene and GraphQL, would you recommend some open source project as reference? There is, I think there is, there was Star Wars API which was done in Python and Django, I think, and there is the same for GraphQL. So you can just Google for SW API or SW API GraphQL or Star Wars API GraphQL. That's one of those. All right. We had one more question right here. You mentioned that, do you have any example or could you talk about how these mutations are done through the query? Yeah. I have an example. I'll just give you a second. So basically our mutation is pretty similar to a query. So I have to remember where I've done it. It's probably in a second. Okay. That's the mutation. Basically you specify the the oppression name then the name of the mutation which is used on the server and then you specify some inputs. In this case I have an input which is called input and then this is the type. As I said I'm using JSON with token and one of the reasons why I did the pro records for the mutations for for GraphQL Django is because I wanted to use this serializer which does everything for me. And yeah, as I said the mutation is similar to a query. So you have to pass the input to the user and you can get the data. You can specify the data you want back. So do you want to see the Django part of this? Yeah. This is actually it. It's similar to the when you use Django object type from GraphQL Django. So you use serializer mutation and you specify the serializer class and then it's going to create the mutation for you. Just because I need it. Alright. Any more questions? Alright, then give Patrick a round of applause again.