GraphQL in the wild by Arianne Dee

Speaker 1: Thank you for coming to my talk. I know there's a pretty awesome talk happening at the same time, so I really appreciate it. First off, a show of hands. Who here has used Explored a GraphQL API before. Okay. And who here has tried to implement a GraphQL schema in the back end on a side project? A couple people. And who here has used it in production? One person, yay! So your questions can be directed at her as well afterwards. So thank you. My uh talk today is called GraphQL

Speaker 1: in the wild. Some people here like lemuras, so I added that in. So now I know a bit about your experience. I'm gonna talk a little bit about mine. I have, I would say I'm a generalist, have Done a lot of stuff in the past. You can read about it in my bio, but related to this talk, um, I taught myself Django about two years ago as um the only employee at a startup. Then I realized I needed some mentorship and I worked at Seven Geese. They were using Django and I've been there for one and a half years. So we're based in Vancouver, Canada. We're about 30 employees total. But back then there were like four back-end engineers, and two of them were we're doing separate things. So they're kind of just two of us

Speaker 1: and then like four front-end engineers. And we and so my coworker Tony who is amazing, is very curious about new things and was into interested in trying out GraphQL kind of you know early on. And so we have been using GraphQL in production for about a year. In the talk description it says 2017 and I think all their sixes got changed into sevens because it happened in a different one. too. So yeah, it's been about a year. There have been a lot of talks. There's a lot of resources online about GraphQL in general. Not as much about using it in Python. But I wanted to focus this talk less so on like an intro to GraphQL and more about

Speaker 1: what we've done to move it from like cool pet project to use Using it in production and how it's helped us. But there will be an overview of that, but I'm gonna kind of breeze through it a little bit so that there's room for questions at the end, and then if you have questions about it, we can kind of go back. So First of all, let's talk about RES. REST is pretty awesome. You can, you know, you've got that separation of client and server code. You can not update the server and still have like mobile views and um and just different views of the same stuff. And yeah, it's great, right? We all love DR DRF. I actually haven't been I've only have like a few months of DRF experience so I know more about GraphQL.

Speaker 1: But there are some issues with REST. One thing was that we were noticing a lot of performance issues One thing is when you're trying to get related data, so you've got you know your normal list view, that's cool, but what if you want like a dashboard view? Um, and so you want to show a lot of related data, um, you know, you have to Go into this nested structure, each one of those endpoints is like a different request. So that takes a long time because you need a lot of requests. Another thing is the amount of time it was taking for serialization. That ended up being the the vast majority of the performance issues we were seeing per request. For example, our user resource, you know, so what Seven

Speaker 1: Peace does is we have a performance management platform. So you can set goals, you can have meetings with your managers and give peer feedback and give peer recognitions and a lot of all of that is user focus, right? So we're sending the the user with everything. Our user, extended user resource has 34 fields in it. Only four of them are important, so we're wasting about 88% of the data that we're getting back from the server. So Rust was still working for us, performance issues aside, but then the designers came up with this dashboard that to build. It looks like this You know, you can see my objective, my objectives or my goals,

Speaker 1: the tasks that are related to those goals, the overall progress, some stats. My latest update to the goals, but then this is also on the page, and all of the goals related to my coworkers and my manager. And then just for fun, some summaries about the organization and the team that I'm on So for an example, bunch of data that we need to get from that, we were shaking in our boots about like how we were gonna do this with RAC. Right? And so we had a little bit of a challenge. My co-worker, Tony, had used GraphQL before. He thought this might be a good time to check. Check it, try it out. He and I had a little bit of a friendly competition going. I would try to use our REST

Speaker 1: API endpoints. I didn't have to worry about versioning. I could like reduce the number of data I was sending per resource and he was going to look at GraphQL. The winner of this challenge, if I won, I would get to name his is about to be born baby boy. And um my mom I'm Filipino, my mom is a travel agent. We have weird names She knows someone whose child is named Spaghetti 88. So I was just gonna take that. So uh so Tony's son was gonna be named Spaghetti 88 Anguirilli. So uh and if he won. He I would not get to name his son.

Speaker 1: So it was on. Um and our results were with rest This is what it looked like in the Chrome inspector about the network calls. There were a lot of them. And in GraphQL, it looked like this. So comparison about 10. 3 seconds overall and 5. 5, a lot of that is just loading stuff. So what is this crazy voodoo magic? Like um and how how do we actually use this in production? We wanted to know. There were uh, you know The security guy is like, what about this and what about this and what about this? And we're like, uh, I think we can solve them. So as many of you know, GitHub is one of the major players to move

Speaker 1: To a GraphQL API. And we all love and trust GitHub, right? So if they could do it, we could do it. We actually did it about the same time. And I'm just gonna show you quickly A little bit about what that looks like. So here is the graphical app. It is awesome. It's like Swagger, but way better. Or the Django Rest framework stuff. So I want a new query. And so I am the viewer. Let's see, I want some repositories, and I only want to get the first 10. And this is weird stuff that I'll go over briefly later. And let's see.

Speaker 1: Oh, those have some issues. Cool. No, I don't want that right now because this is just a demo, but let's see where that comes up. So So I can see my name. I've got a few repositories in here. But pretty much GraphQL you can it's a query language. It defines how you query data from your APIs. It's similar to SQL, which is a query language for your databases, but this is above the layer of databases. This is This is API business level logic. You can have totally different models in the back end from what you display in the front end, and that's actually highly encouraged.

Speaker 1: So According to GitHub , the ability to define precisely the data you want and only the data you want is a powerful advantage over REST API. Some of these advantages include, yeah, the data that you want and nothing more, nested fields, and strong typing. So, does it play well with Django? Uh the answer is kind of. Since this This is really powerful for front end and JavaScript and especially React. Also, Facebook, I I forgot to mention, Facebook was the people who actually created GraphQL. They've been using it internally

Speaker 1: in productions Since 2012, they had this issue with getting too much data, especially for their mobile app that doesn't need as much data as their website. And they open sourced it, they announced it in January 2015. So about two years ago, open sourced it about half a year later, and now you know it's just grown and evolved over time. But Because it's more for the front end, I think the JavaScript communities have really taken to it. There's like five different versions of it in Node and in Django, we've got graphene, which is pretty cool. It's pretty easy. but there are some drawbacks. So here is the GitHub readme for it.

Speaker 1: So you can just use It has hooks to work with Django, especially their ORM. You can also use SQL Alchemy and maybe Pee-Wee sometime in the future. That's been there for like a year. So how do we set it up? It's like two seconds, pip install graphene Django, add it to your installed apps. and set the URL that you want all of GraphQL to go to. So GraphQL, it has a single endpoint And you send the data that you want in the query and your variables either through the get query parameters or through the post body. So that can be anywhere. I'm calling it GraphQL. It also

Speaker 1: has it comes built in with that graphical app, which you can explore it everything with. So um so that's it mostly. Then you have to define your queries and your And schema. It's as simple as this. If you're using Django, you just say, hey, I've got everything in red, by the way. Sorry for anyone who's colorblind, hopefully you can see it, but like Django object type. is in red. I wanted to do that so you can see what exactly is coming from the graphene library or the Django Graphene Library. So it wasn't so long. So yeah, say it's a Django object type, you're creating a node, and it's going to be based off of this model, the task model in Django.

Speaker 1: You also have to define, so besides your nodes, you have to define how you're going to enter the schema, so your root query. So here I'm just saying it's goals. This is the the kind of data that I'm working with in my company. And then you can resolve goals in a certain way by saying here's the query set to look at. And then add it to your schema. So here is a little bit of a drawing that I overlaid with things I got from the Apollo blog, Thanks Apollo. So you've got the triangles is where you're entering the schema, and then you can use GraphQL to traverse the rest of it. And the yellow bits are the nodes. And then all the little things coming off of it are like fields of that node. So

Speaker 1: graphene will take that automatically from your Django models. You can exclude things Of course. You can also define custom nodes. So for the user node, if I want full name, I can say full name is this type string. And string is from the graphene library, and then resolve it. And so whenever you have resolve anything that's like a field, you can have a resolver for. And I'm because I'm going to talk about resolvers later a bit. So you can say what it returns. Great. So that's pretty easy. So I'm just gonna show you a bit about all that stuff I've done just now, what that looks like, that will get us this

Speaker 1: goals. Um, and I've got some tasks, and they each have a name Okay. And yeah. So that's it for now So that gets you that. And so you can use this on top of any project that you're using, regardless of whether you have a REST API or not. So next, adding filters and pagination. This makes it a little more complicated. So you've got goals and name and progress. But how do we get certain things like what the total count is? And how do we do pagination and filter on

Speaker 1: on them. So these red arrows are now going to be called connections. We're going to add a few different things. And so when you are when you have like a many to one or many-to-many relationship, it's going to now be called edges. So that you can do things like get the total count of the edges or get these things called cursor for pagination. And I'm just gonna and then you can also use um you can filter, you see um, oh no. Ah, anyways, it also adds it also adds filtering. So how you get that is something called relay. Facebook uh Relay has it is kind of like Redux

Speaker 1: for JavaScript. But let's not worry about that. You don't have to use relay in JavaScript to use the relay pagination features in Graphbean. So all you do is say I'm using this relay node interface and that changes all of your connections To changes your list to connections. And then you can use something called Django filter connection field, and that adds the ability to define your Django filters class that you want to use. And so you You can use your Django filters on every node. Lastly, or almost lastly, we have kind of built-in documentation. Which is one of my favorite features of GraphQL. So I can just say, here is

Speaker 1: the description of this field, and then what that ends up looking like. is in these docs, I can go into query, I can look at goal node, I can look at, oh no, sorry, that is a mistake. Where did I add? it too. Anyways, uh here. So if I go into progress, I can see the description just in here, but you can also you almost never need description Because they should be describing themselves, ideally. Okay, then there's a lot of other fancy stuff that you get, which we're not going to talk about, but if you have questions, you can ask me outside.

Speaker 1: And pretty much the answer is it can do everything, pretty much everything that you want it to do. You might need a little bit of tweaking, but we've added our own new fields. return different um Django model types um on the same node using unions uh everything like that. So you've got some pretty cool stuff. There's some pros for uh GraphQL. It's like self-explorable, like you don't have to set anything else up, and it's pretty fun. You've got easy documentation. I find it personally more intuitive to implement than Django Rest framework. And that's just on the back side. Like you know, in building APIs. There's a whole load of benefits for the front end.

Speaker 1: So what makes what are some use cases that make it better than REST? So as we saw before, those complex views If you want summaries, dashboards, stats, your nodes don't have to be connected at all to Django models. You can return whatever you want. So we have a stats node that does a lot of processing in the back. And send it to the friend. And we were good this way. That was about September to November We were only using GraphQL for complex views and gets. But then we had this other challenge. We were building this feedback form

Speaker 1: and we wanted to create a survey builder that would auto-save. And the front-end people had tried implementing it already in REST. There was like all this stuff we were using, like reactive, like Rx. js to do do certain things, you know, determining when you're creating a new object, so a post, versus when you're updating an object, versus when you're deleting it, things have to be done in the right order. And if you if something fails, you have to remember what else needs to come back, come after it. So we had this idea to use GraphQL for it. And it ended up working really well.

Speaker 1: So instead of um doing each Each item we just like send it a big payload and the back end it's up to the back end to figure out how to save everything so that what's in the database actually looks like the payload that you got. So if you got a successful response. you know that what you're showing is actually what's on the back end. And you know you could do this without GraphQL, but the benefits of doing it with GraphQL are the type checking. You don't have to check each input that yes, this is a float. Yes, this is a string. Because it'll it'll uh do all that for you and give you an error if it's not right So there are these things called mutations instead of queries. So those are the two main components of GraphQL.

Speaker 1: And how you set that up. This is what it looks like in the end. You've got a mutation here. You can pass in some variables and pass those variables into the mutation. And then when you press and when you send it, what is in here is another query. And that's the data that you get back. That's the result of doing those that mutation. So you know have you if you've ever had this problem where you change some data, something else then changes, and so you need to do another request to see how it affected it, that's all in one request now. you just yeah define what you want to return.

Speaker 1: So you can define some inputs. They're like nodes, but the There's actually no quick way that I know of of getting the input types from the Django model. You kind of have to build these yourself. And in that way it's different from a put or a patch because you're not you you're not supposed to think about it in terms of I have this object, I want to change this field to this In this field to this. It's more like I want to mutate this object in some way. I want to do something to it. And the backend should have a better understanding about what that means and do it itself. Oops, that was not supposed to be like that. So

Speaker 1: yeah, you can define a mutation like so. You have the GraphQL mutation class, you define what inputs you're taking in. I'm actually only taking in an int and a float in this case and not the inputs that I showed on the previous screen, but I wanted to show you how it could be done. And then the goal part is defining what node is being returned by it. So that's what you can query on when you're actually doing the mutation for your return. And then you do a bunch of stuff, make sure it's atomic. And then you just add it as a mutation onto your schema. Okay, so looking back at our graphical

Speaker 1: viewer, you know, you can see that where the different parts fit in, the inputs, the return data, the variables. And so this simplifies the client side logic that they have to do. You don't have to be Yeah, along with the gets and the writes, the front end loves it. If you want to make your front-end developers happy, think about using it. But what's the catch? And so this is the more important part of the talk. So one thing is that graphene is the only library that you know is really viable to use uh to implement a GraphQL schema in Django and Python.

Speaker 1: Um it was released about a year ago and you can see since then there hasn't been that much activity on it. There it is a young library and there hasn't been a ton of contributions and so there are bugs, there are um, you know So it was released in 2016. The docs are not super complete. If you have questions, often you have to ask a question as an issue in the in GitHub. Also, sometimes it lags behind the GraphQL specs. So for example, total count is in the GraphQL specifications, but as far as I know, is still not yet in the Graphene library. So we had to build that ourselves There are some bugs with the resolvers.

Speaker 1: If it kind of has some weird logic. So we've had to rewrite a lot of that logic about how things get resolved. Because you know, first we want to Return the resolver query set, then we want to filter on that, and then we want to do other stuff, and the order that it does it by default is not right. And lastly, one of the big things is that the source code is quite complicated. There's a lot of metaprogramming in it, and as someone who's only an intermediate Python developer, it's kind of hard to dive in and make the changes that you want to make. So I would say that's kind of the biggest hurdle to using it

Speaker 1: So yeah, the real world is messy and you're not gonna want to use graphene exactly in the way that it was made. Um this is not actually Spaghetti 88, just a baby I found in Giphy. Um but yeah, the real world is messy. Uh and GraphQL is just a query language. It's not telling you how you should do spag certain things like authentication and authorization and uh and caching and stuff like that. So we had to address it still. So first, what about permissions? You know, for us permissions were a really big issue because

Speaker 1: we have different companies using our product. People from one company should not be able to see them. any of the data from another company. So one option that is kind of what the graphene docs say you should do is perform authorization on each resolver. And that would be a pain in the the butt. We don't want to have to call our DRF authorization class every time we want to get a connection. The other option is to extend graphene to perform that authorization on every connection, which is what we did and what I encourage you to do. It's not like DRF. It doesn't have all these hooks to like, you know, put your custom logic here. You know, you have to you have to actually extend the classes.

Speaker 1: What we did, if any of you have tried to do it, so we First of all, added to each node what the DRF class that we're we're using for authorization is. And then we extended Django filter connection field. On the connection resolver, we added the user authentication. So are they logged in? Can they actually see any data? And then when you resolve the connection, we say okay from your node we know you're supposed to have this authorization class we'll apply those authorization limits on the original query set and then that's what you should use to do the rest of it. Um so that's pretty good.

Speaker 1: That's a solvable issue if not it like even though it kind of takes some effort. But what if someone is requesting too much data? We've got um denial of service. Uh it doesn't necessarily have to be an attack, it could just be someone is requesting too much data and it's uh hogging up time on your server And so what we did, because you know you can traverse as much as you want. GraphQL has some things like you can't do cyclical things, so you can't have have an infinite loop, which is good. But you can just like have someone like a script create like a really big amount of stuff. So What we went with at first, which is the easiest way of doing it, is having a whitelist for the allowed queries. So we actually had all of our queries in the back end

Speaker 1: in Python and gave each of them an identifier. And then the front end would have to call that GraphQL query by its name. And so that way we were allowed to say these are only the queries that anyone can run on GraphQL. That you know works a it works up to a point and it definitely had its downsides, so we were trying to move away from that. So another thing you can do which GitHub first did is add a maximum limit to any connection. So theirs at first was 30, now it's 100. So every time you want to get a list of stuff, you have to define how much you want. They also

Speaker 1: have implemented a maximum query cost, which is something that we have only just done last month, finally. So you can say You know, you can max access 5,000 nodes on any given query. And this is how GitHub calculates theirs. We do it a little differently, but you know, having it there is awesome and it enforces limits as well. Because we just said if you don't have a limit, then we're assuming you're getting a thousand. And something GraphQL also has is rate limiting Based on query costs. So before their V3 API had a certain rate limit. Now you can't, that rate limit doesn't make as much sense since you can grab so much more data.

Speaker 1: So it has a different way of calculating The cost that's based on the number of database connections that you're actually getting. And so they rate limit you based on that. And so lastly, what about performance? And for some people, this is the big elephant. Everyone uses this, so I add it to my slide. So sometimes these queries take a lot of time. And Django uh graphene doesn't really at first, especially at the beginning, didn't really do much to focus on performance. And it most Focus on getting it to work. Since V1 has come out, that was like a big performance improvement, but there's still a lot more that can be done. For example, um

Speaker 1: By default, it doesn't do select relateds and prefetch related when it resolves the query as it traverses it, which is not necessarily that it's not the most performant. Something we also did is reduce the number of count calls. Other So something you can do instead is have something that looks at the whole entire query and and adds things to it and resolve it all at once. So that brings us to the data loader. This is Facebook's answer to the performance issues. So initially, like without the data loader, this could take 13

Speaker 1: database calls for all these different fields, right? It's a lot of database calls. But what the data loader does is it analyzes everything, which returns a promise, and then It batches grabbing things. So if you have a bunch of users here in the friends that have the same PK, then you don't have to get them multiple times. You just get them in one big batch. So having a max query cost also helps with the performance issue. And for us, one of the biggest things is just front-end education about how to use GraphQL. Since this was a back-end initiative. You know, they were like, hey, okay, we'll use it, that's cool, and they really liked it, but they didn't necessarily know much about it, and they see it more as a back-end

Speaker 1: thing. than a front end thing. And so they're like, we'll get all the data, especially before we had the query cost. And they were doing things like this, where they're saying, I have all these goals, give me the idea of all of them, and then in the front end I'm just going to to count the entire length and that's gonna then that's all I need. But we're like I actually don't get any of that and just get the count. If you're only gonna show two like either the full name or if there's more than two one person than just the number of people, then just grab the first person. Yeah, and uh this is you know 32 comments on here. This is one of the longer issues in GitHub

Speaker 1: about graphene and you know you can follow it, it keeps changing kind of interesting he's added a whole bunch of new stuff um but there's still more work to be done so there are some considerations um it's still a young library uh I'm hoping Uh Cyrus isn't here today, is he? No? Okay, the maintainer. Like uh I was hoping to like maybe we could sprint on it tomorrow, but I actually don't know how how much he's into that. But yeah, it could use some work uh because especially because GraphQL um is just a query language and it doesn't specify how to do things. So how would Graphene know what to do about these Things. Yeah, and then authorization, denial of service, and performance are some of the big things that you have to look at if you are using it.

Speaker 1: So should you use it? Who is maybe considering using it now after this talk? That's cool. So go for it. If it's just a side project and for fun, it is really fun to know and to like have as a tool that you know. So also if rest is causing some performance issues that you're like, I actually don't know how to get around this. I could replace all my serialization serializers with something faster, but you know that's a lot of work. Also, if your REST format is making it difficult to read or write things. And importantly though, you have the resources and like development experience to know how to extend it in the way that you want.

Speaker 1: And you know, hold up, just like back off a little bit. I mean you should still try to do it, but think about it if you have a lot of sensitive insights information and or you're trying to create a public API, in which case you have to worry about rate limiting and query costs. And you don't have enough development resources to do it. it, um or not enough experiment experience to know how to extend it. So That's pretty much it. There's a lot of great resources on the web. The Zero to GraphQL video is know probably the one that's posted everywhere about a good intro. Yeah, and so thank you very much.

Speaker 2: Hi, thank you. Um what uh database engines do you recommend for the for supporting

Speaker 1: Um any? I'm not sure we use um MySQL. Um And is that what you mean by database engine? Okay. Um yeah, because you can it it really you it doesn't matter, I don't think. Um maybe for performance It could be a lot better for one or the other, but I can't say for sure.

Speaker 3: First of all, thank you. I've been wanting to learn more about this for a long time, so it's great to have somebody who's experience explain it to us. Um I think the part of it that I I don't quite understand is how do I have to do something special when I create my data models like if I I I like to make lots of little like union tables for permissions and stuff like that. Does that does that work with this? Can I just use what I already have or do I have to redesign the way that I handle I store my data to use this stuff.

Speaker 1: Um I don't exactly know what you mean by union models, but We've used all of our same authorization from Jenga Rest framework. There you can just kind of like add things to the node. So we added an authorization model to the node. So if you have other things that you want

Speaker 3: What's a node?

Speaker 1: Oh yeah. No, thank you. So Um so the yellow circles are nodes. Um and So in this example it's like list user and to-do are different nodes. For us they they relate to our models.

Speaker 3: Right, right, right.

Speaker 1: Yeah, so so it's just like I don't know. Does that make sense? So they're the the parts of the graph that you can traverse that are not scalar types. So they're the ones that you create yourself and they're the ones that you define based on your models or the way that your business logic is as like a resource. It's like a resource.

Speaker 3: Right. So if I if if I'm assuming that that maps to uh like a normal Django model that I have, what if I have a a foreign key?

Speaker 1: Yeah.

Speaker 3: How does does Is does gra graphene do the kind of the traversal to the foreign keys for me automatically? Is that the whole point?

Speaker 1: It does do it automatically. Um but you can also you'd also can Add as much or as little as you want to it. So for example, this goal node, if I don't have this Um it'll still have tasks. Er, well actually my models are my models are actually different because I'm showing a some something not based on the OKR goal methodology that we use. So if I remove these fields, it'll have a key results which is like tasks Already on it, but it's just the default settings. I can

Speaker 1: do this to say, actually change that field from the original name key results to the name tasks and then I can add different things in here. So I can add a description for the docs, I can um for different fields you can add the defaults and whatever. And then if you want to limit the subset of tasks that it actually receives, because right now it's getting all of them. Actually, I would need to do this if I need to change the name. Right now it's getting all of them. You can also use the resolver to change the functionality of what the default is and send, you know, a filtered. list of tasks down um

Speaker 1: like that. And so this is the query set that it's going to return from the resolver, and then the authorization is going to be on that, and any filters that you add are going to be on that.

Speaker 4: First of all, thanks for the talk. It was really great.

Speaker 1: Who's talking?

Speaker 4: Hi.

Speaker 1: Hello.

Speaker 4: I was curious when creating GraphQL endpoints in practice in a real production application. Do you find yourself making basically one giant GraphQL like endpoint that you can get everything? Or do you like tailor it to more specific pages Pages or use cases, like how do you divide that up?

Speaker 1: Yeah, so we do have one big schema that you can um access from you know, all these different nodes. Um, but that's based on our app. If you wanted to have different endpoints, you can easily do that in URLs and just have different versions of this schema in different places. Uh actually yeah I think there's some sort of setting to say which view uses which schema. And I think right now that's in the settings. py. I actually don't remember. I think it might just look for it automatically, but you can just set up two different schemas

Speaker 4: Do you have a recommendation on what like in your experience over the last year or so like what has worked better for you? Is it easier just to keep everything in one place. Yeah.

Speaker 1: Because you don't know when you're going to need something from from a different part of the app. Like ours are all kind of interrelated anyways. So it makes sense to have all that information available. Like a user, for a user, I need to know everything that they've done. How many recognitions have they received? How many goals have they created and checked into? So that makes sense for us.

Speaker 4: Sure, yeah, that makes sense.

Speaker 1: Thanks.

Speaker 2: I saw the the um interactive Like query builder where you can start building your query.

Speaker 1: Graphical.

Speaker 2: Yeah. Does that m mean that the uh server is exposing some sort of schema? to the client. I mean, because something that I would like to do in in the in the client side is uh have a schema that I can use either to validate data as it comes in or to auto-generate forms instead of having to actually create the form tags. If I if if uh GraphQL is exposing a schema, I was wondering if I can use that in JavaScript.

Speaker 1: Yeah, so it has introspection and um can tell you what the schema is uh and people have used it. Um think in TypeScript. I don't know if it worked very well, but it is possible to to get what that schema is. Yeah Another thing I didn't mention is when we use the whitelisting query method, we actually didn't expose that view to the outside world. You could only use it in development um just you know so other people couldn't run stuff on it yeah yeah

Speaker 5: so uh all of those extensions you've made Like for the authorization, your extensions to the uh filter connection field? Are those things that we can expect to see in upstream graphene at some point?

Speaker 1: Uh I'm really hoping so. I think now that I've given this talk, there's more incentive for us to get things merged and not just like keep it in in our own utils library. Besides that, like I I think what we should do is add pull requests to it and regardless of whether they get merged you can see what we've done and just copy it into yours. Yeah.

Speaker 6: That's our time. Sorry. Okay. So let's thank Ariane for her great talk.