Hi, everyone. Welcome to my talk. Who am I? I'm Patrick, and you can find me online at patrick91, almost everywhere. I work at a web agency called Think Studios. We do websites for clients and also we have internal 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 technology 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 frontend. So the modern web, as web

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

API 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 friends names, you need to do a call for all of the user, and this is, as you can imagine, 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 get 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 going to

get really bad. So another solution, like a work on 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 and the avatar, but then you're 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 a 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. I never read the old specification because I always saw the example, which is something like

this. This is GraphQL. GraphQL is a queer 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 friend's 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, it's really easy to use, but one of the most powerful features, and I guess also one of the most liked features is typed, so everything in GraphQL is typed, so basically your schema is gonna have typed.

For example, for your previous query, you have a user type, you just got a name, an email, there are strings, and 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 gonna have probably name and email as well. Then another feature is introspection, so basically every GraphQL endpoint is gonna expose some metadata so you can get all the types.

For example, in this case, you can use graphical, which is an IDE in browser, so it gives you a complete on your API and the arguments and the fields, so for example, it's getting the product ID too, the name, description, and it's getting the picture with

size 500 and so on. Right now, I've shown you the query, which is basically the way to get data from GraphQL, but also you need to change the backend data, for example, like with REST APIs, you do a post request, patch request, or delete, so with GraphQL, you always use

one single endpoint and one single HTTP word, 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 updates to it, which is using, you usually use web sockets. So a query is done, it's like this, as I showed, you have some fields, and you can have some arguments, so for example, in this case, it's going to get the human with ID 1000, the name,

the height with unit of foot, but this is only a shorthand for the query, the actual, the extended version of the operation is this one, so basically specify the operation type, as I said, you can have query, mutation, and subscription, and maybe in the future, you can extend the specification. Then you have an operation name, which is basically used mainly

for debugging, so you get logs on the server with that, and you also have some variable definition, which include the type that you define, and then you have the selection set, and when you run this query, you get the data that you asked for. But yeah, this is a Python conference, so you want to use this with Python.

Here's 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, we just got only

one field, which is a loop, 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, if you already use it. To use it, you install like this, and then you have to extend the installer ups 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 Graphi code, 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 it, 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 the 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 N plus 1 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 get the schema from the query. So one of the problems that we had at work is to have authentication on the API, and basically, since we are using Django and it's really 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 announce some part

of the website. And yeah, you can use any Django stuff. Then you have the permission. This is a different paradigm on doing query. So for the permissions, you basically, you don't really have permission models, but you have permission on the actual fields. And 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 it. I'm using it on one of the projects at work, because I need mainly some use cases to test and then see if there is any bugs. Basically, what I've done is to, you can use GraphQL

with Django SQL serializer, so you don't have to specify the serializer again, for especially for the limitations. Then I would like to touch on a bit of the security,

because since you can do nested fields, some malicious users can do big queries, so for example, they can have 100 level of nesting. One of the solutions, I think it's been adopted by GitHub, which is using GraphQL in production, and also it's public,

is to just limit the number of nesting that you can have. For example, if the nesting level is more than 10, they just stop the query. It's probably something that's a bit strange. Also, you have long queries, because since you can also specify arguments, maybe you can end up with a query that's

going to take too much time. 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 return nothing, which I think is what we should do, because one second is already too much. This is the back-end part for the front-end.

You can still use any client that you like to do post requests 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. 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. The other solution is Apollo, which is community-based. Basically, they have clients

for vanilla JavaScript. If you don't use any framework, they also have clients for Vue.js, React, I think also Angular and some other ones. I was really fast on this talk.

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 talked about GraphQL, but some of those are, for example, fragments, so you can have 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 friends in another page, you can combine the query from those components, and it's going to do only one query. Also, one of the issues is caching. Since you are doing

post requests, you cannot cache, you cannot use something like varnish or pure Django caching, because you are doing post requests, so one of the solutions that's been implemented by

both Facebook 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 that 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 caches on

those ones, but it's a bit harder than just pure REST APIs, because you're 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 thank you.

Hey, thank you for the great talk. So my first question is how you deal with pagination using GraphQL. Sorry, I do pagination. How do you paginate? How do you deal with pagination?

Oh, yeah, there is one of the ways using basically has 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, 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, we return a list of edges, so you can get the IDs and the, yeah, the start ID and the end ID. Maybe if you chat with me, I can show you some example,

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 RESTful approach, you can really easily specify which endpoint is public and which endpoint is private. Can you do this via GraphQL, because you have only one endpoint,

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 APIs 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 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 some fields, it's going to end up on the schema, the schema definition, and they have some metadata on some fields that

basically they say, oh, this field is only for internal use, so when they are logged as GitHub, they can see the field, but when they are using as a public user, 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 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 all this stack, would you recommend some open source project as reference? I think there is, there was a 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. We had one more question right here. You mentioned mutations, do you have any example or could you talk about how these mutations are done through the query? I have an example, just give me a second.

So, basically, our mutation is pretty similar to a query, so I have to remember where I have

it. That's a mutation, basically, you specify the operation name, then the name of the mutation,

which is used on the server side mainly, 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 Graph in Django is because I wanted to use this serialiser, which does everything for me, and as I said, the mutation is similar to a query, so you have to pass the input,

of course, then you can get the data, you can specify the data you want back. Do you want to see the Django part of this? This is actually it? It's similar to the

one used Django object type from Graph in Django, so you serialise the mutation, you specify the serialiser class, then it's going to create the mutation for you. I'm just adding a token field, just because I need it.

All right, any more questions? All right, then give Patrick an applause again.