We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

GraphQL in Python

00:00

Formal Metadata

Title
GraphQL in Python
Title of Series
Number of Parts
118
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Over the past few years GraphQL has gained much traction, but what’s the state of GraphQL in Python. This talk describes what GraphQL is, why it has been created and the current state of GraphQL libraries in Python. There will be a short history of GraphQL, some examples of what makes it shine and why it can be preferred to REST. We will also analyse the current state of GraphQL in Python, having a brief overview of the current libraries and then having an in-depth look at Strawberry a new library based on dataclasses that makes it easy to create GraphQl APIs in Python.
Keywords
Point cloudGoogolWorld Wide Web ConsortiumComputer animationJSON
Google MapsWorld Wide Web ConsortiumServer (computing)Patch (Unix)Boundary value problem2 (number)Revision controlCartesian coordinate systemFront and back endsOperator (mathematics)MathematicsWeb 2.0Electronic mailing listFocus (optics)Mobile appState of matterWeb serviceScaling (geometry)User-generated contentRepresentational state transfer1 (number)BlogWebsiteClient (computing)Computer animation
FacebookCartesian coordinate systemWeb pageWeb browserSoftwareBand matrixMathematicsShift operatorDifferent (Kate Ryan album)FacebookScaling (geometry)World Wide Web ConsortiumAndroid (robot)Lecture/ConferenceComputer animation
Mobile appScale (map)Category of beingQuery languageMobile WebOcean currentWorld Wide Web ConsortiumMobile appWebsiteStandard deviationEnterprise architectureAuthorizationInformationClient (computing)RoutingLink (knot theory)Multiplication signCASE <Informatik>Query languageCategory of beingGraph (mathematics)Source codeProduct (business)Exterior algebraScaling (geometry)Electronic mailing listDependent and independent variablesPoint (geometry)Filter <Stochastik>BitFront and back endsOpen sourceBlogFacebookTwitterUltraviolet photoelectron spectroscopyStructural loadCartesian coordinate systemCommunications protocolSoftware developerSingle-precision floating-point formatWeb pageUniform resource locatorLecture/ConferenceComputer animation
Category of beingQuery languageAbelian categoryString (computer science)ArmElectronic mailing listType theoryMenu (computing)Descriptive statisticsShape (magazine)Dependent and independent variablesRootField (computer science)Category of beingCASE <Informatik>InformationQuery languageLecture/ConferenceComputer animation
Query languageElectronic mailing listCategory of beingSoftware testing
ImplementationDescriptive statisticsString (computer science)Software testingType theoryGroup actionCategory of beingCASE <Informatik>XMLProgram flowchart
MathematicsSoftware testingDemo (music)MultilaterationComputer animation
Operations researchCategory of beingElectronic mailing listQuery languageAbelian categoryPay televisionQuery languageOperator (mathematics)CASE <Informatik>Reading (process)Type theoryMessage passingParameter (computer programming)Field (computer science)Revision controlCategory of beingDebuggerPay televisionResultantEvent horizonGateway (telecommunications)Multiplication signClient (computing)LoginData storage deviceSystem callFront and back endsDifferent (Kate Ryan album)Computer animation
Front and back endsDebuggerClient (computing)Variable (mathematics)CASE <Informatik>Bookmark (World Wide Web)Line (geometry)Personal identification numberSocial classHidden Markov modelFunctional (mathematics)Type theoryRun time (program lifecycle phase)Graph (mathematics)Field (computer science)Error messageElectronic mailing listLibrary (computing)Game controllerRepresentation (politics)Server (computing)CodeConnectivity (graph theory)Lecture/ConferenceComputer animation
Library (computing)Type theoryMultiplication signPersonal identification numberSocial classProduct (business)Lecture/Conference
String (computer science)Abelian categoryQuery languageCategory of beingMenu (computing)Electronic mailing listFunctional (mathematics)MappingMessage passingMenu (computing)Computer configurationCategory of beingField (computer science)Computer animationLecture/Conference
Query languageElectronic mailing listAbelian categoryInformationCategory of beingLimit (category theory)Parameter (computer programming)Demo (music)Type theoryMaxima and minimaCASE <Informatik>Field (computer science)Category of beingElectronic mailing listQuery languageComputer animation
Electronic mailing listCategory of beingLine (geometry)Parameter (computer programming)Field (computer science)CASE <Informatik>Power (physics)Computer animationSource code
Filter <Stochastik>Parameter (computer programming)Dimensional analysisExecution unitPhysical systemMetric systemPoint (geometry)Field (computer science)Computer animation
Query languageServer (computing)Tracing (software)Field (computer science)ImplementationDependent and independent variablesTime zoneEvent horizonPay televisionMultiplication signAuditory maskingSynchronizationDebuggerServer (computing)Query languageASCIIBitComputer animation
Tracing (software)Field (computer science)Projective planeData miningProduct (business)WebsiteField (computer science)Social classBitMultiplication signMathematical analysisElectronic mailing listResolvent formalismDigital photographyMatrix (mathematics)Lecture/ConferenceComputer animation
System administratorEmailFunctional (mathematics)Type theoryField (computer science)Product (business)Numbering schemeComputer fileResolvent formalismLibrary (computing)BuildingFormal verificationString (computer science)Right angleWorld Wide Web ConsortiumLecture/ConferenceComputer animation
TwitterWorld Wide Web ConsortiumFront and back endsBand matrixBefehlsprozessorInformationSoftware developerClient (computing)Lecture/Conference
Software developerPhysical systemStructural loadSystem callCovering spaceProduct (business)DatabaseRepresentational state transferSystem administratorEquivalence relationPoint (geometry)Speech synthesisInformation retrievalGraph (mathematics)Computer animationLecture/ConferenceMeeting/Interview
Library (computing)InformationQuery languageBootingCoefficient of determinationServer (computing)Mathematical optimization
Fatou-MengeIntrusion detection systemBlogElectronic mailing listQuery languageComputer virusSpeech synthesisGraph (mathematics)DatabaseLecture/ConferenceMeeting/Interview
Parameter (computer programming)BitEndliche ModelltheorieField (computer science)Graph (mathematics)Type theoryFunctional (mathematics)SequelDifferent (Kate Ryan album)DebuggerQuery languageLecture/ConferenceMeeting/Interview
Different (Kate Ryan album)Projective planeMoment (mathematics)Software maintenanceSoftware frameworkFrictionRepresentational state transferArithmetic progressionLecture/ConferenceMeeting/InterviewComputer animation
Software developerCodeLecture/Conference
Social classCodeType theoryData compressionLecture/ConferenceComputer animation
BitDifferent (Kate Ryan album)Library (computing)Numbering scheme
CASE <Informatik>Numbering schemeFilm editingString (computer science)Meeting/InterviewLecture/Conference
Transcript: English(auto-generated)
Hello everyone, thanks for the introduction. So, the web is not so old. We've been using it for about 30 years now, but it's been constantly evolving over time, so we've seen different ways of creating content, different ways of using it, and also different devices of using the web. For example, HTTP was introduced in 1991,
and then after that, we've seen things like, for example, GeoSeries, which allowed people to upload websites online without having to know what a server is, and that was something, it was, I think for me, was the start of the web, as we see it now. And then in 1999 and 2000, we had something called
Web 2.0, which is kind of second version of the web, where the focus would be more on user-generated content, so you see lots of blogs, and personal website, and kind of like GeoCity, but a bigger scale, so everyone in the world would do it, and it was not something that was only in the States. And also we've seen REST and SOAP,
which are technologies that have been used to allow different services to communicate together, and also we're now using them to have clients, application communicated with a backend. And especially REST became really, really popular, and I think it's a beautiful concept,
so you use HTTP, and use HTTP verbs to do operation of your resources. So for example, you can do a GET, get a list of posts, you can do a PUT, and create a new post, or change it, then you can have DELETE and POST to create, for example, a new comment, and there is also PATCH and some other non-standard ones, and it's really nice.
And in 2004, we've seen apps like Gmail and Google Maps, that were basically pushing the boundaries of the web, what the web could be. This is 2004, it was something really, really different seeing this application running on a browser, and you could do things without having to refresh the page,
and it was really powerful. And then in 2006, we've seen Facebook, that then became a global scale social network, and this is quite important, because they start having problems that normally you wouldn't have, because they start having billions of users, thousands, millions of different devices, and also problems like network,
and also low bandwidth, and so on. Then in 2007, another important change was the iPhone followed by Android devices, and this would mark a shift in the way we built applications for the web. We start having mobile websites and mobile application,
and in current days, the web is still evolving, so we don't have collections or document anymore, but we have apps, and these apps are not simple application, they are really complex. Even for a simple website, like my website was a single page application, which seems simple, but you still have as an API behind, and it's complex, it's not just HTML and CSS.
And it also makes sense to build applications now instead of just static website, because the developer experience is much nicer than what it was before. So we started creating APIs, APIs to basically allow a client
to communicate with a backend, also communicate between different backends, or just even if in a startup you could have a frontend team and a backend team, and you would have APIs to basically connect them together instead of building a monolith, for example.
And that became in the system, at least in the non-enterprise world. But it really didn't scale with time. While it still makes sense for some use cases, you still have some issues like, for example, under-fetching, which basically means you do a request and then you have to do more requests to get more data, or the other data you need.
For example, you have a blog post where you wanna get information about the author, but the author, for example, is a link to the author, so you need to do another get to fetch that information. The solution for this would be to create a new endpoint where you get all the data, but then you have issues like over-fetching where you're sending way too much data to a client
that's basically not needed. And I think for me, the other issue that was really painful is way too many endpoints to remember, because imagine if you have 100 resources, you will need to do at least 100 URLs endpoints. And with that, you also need to add documentation to basically document all the endpoints that you have,
all the ways that you can use the endpoints, filters, and so on. While you have some tools, especially in Python, to generate the documentation is still painful because there is a bit of minor work to do. So we start looking for some alternatives, and we are thinking, what if the clients that we have could declare the data that they need?
So let's say we have a client that needs something like this, so it needs a list of categories, and for each category, it needs a name. We could send a document like this, saying, oh, I need the category and the name, which this is basically like a JSON, but doesn't have the values. So we would send this to the backend,
and the backend will respond with this. And this is basically what GraphQL is. GraphQL is a query language, and it's being created by Facebook in 2012, and then released as open source in 2015. And it's being used now in production by Twitter, GitHub, and loads of other sites.
I think Reddit as well. And it can be used with HTTP. It doesn't have tools, so you can use it with WebSocket as well, or any other protocols if you need to. And in the case of HTTP, there is only one endpoint, and you send the document here to request the data that you want. So you do something like this, HTTP post slash GraphQL,
and you send something like this, and you get back the data that you asked for. And for example, if you wanna ask for more information, you can do it. Just change the shape of your document, and then the response is gonna be this one based on what you asked for. It also has a type, so every GraphQL API has a schema,
and a schema basically lists all the type that you have, and all the fields that you have for each type. So for example, in the previous API, we have a type query, which is the root of our API. So all the fields are coming from the root query. And then in this case, we have a categories, which is a list of categories. Then we have type category, which has a name,
and then a list of menu items. Then menu item is only a name and a description. And then, having all this together, it basically allows us to use tools like this one to basically have an easy way to get the documentation
and do testing, for example. Let's see if I can get to the, yeah, here we go. So we can see the schema that we had before, and we can also see the documentation. So for example, you can see we have a list of queries here, there is only one categories, and then the type is category, and then there's names, so you can explore the API
like this without having to basically write any code or check the actual implementation of the API. And for example, when you can add description to the types, so in this case, declaring what the string is, but you can do this with any type. And this also allows you to do testing like this,
so you can use autocomplete, and you can basically explore the API and test it, which is super powerful, because you don't have to do much work to put this in practice.
I'm gonna show a bigger demo later. Didn't change, okay. So I was only talking about querying now. So this is how you do a query in GraphQL. So you can specify the operation type, which is query in this case, and then an operation name, which is only used for debugging purposes.
So for example, you can have logs with all the operation names, and then you can specify the fields that you want. And this is the extended version. If you're just doing a query, you don't have to pass query and the name, so you can do what we've seen before. But if you wanna, for example, edit data, you can use mutations, which they work the same. So you have a name, the operation type, then a name,
and you can also pass arguments. For example, in this case, we are passing an argument in call ID to the edit category mutation, and then we are passing a hard-coded title in this case, and then we fetching the data. So basically, mutation, they basically work the same as query, so the same syntax and the same result. So you can also, you can do a mutation,
you can request for the data that you want back. It doesn't have to be a different data. It can be what you want. Then the other one is, for me it's very interesting, is subscription. So an easy way to subscribe to an event happening on the backend. So in this case, we can subscribe to an event called on category update, and every time this event is called,
we get the data back, but only the data that we requested. So it's really powerful. It's, yeah, one way of declaring data that you need for the operations. And there's much more. There are tools that I think I'm gonna use where I work now, to basically build an API gateway. So you have one single gateway that's talking to different GraphQL APIs,
and then it's gonna basically do the API calls for you. So for example, if you have a user microservices and a post microservices, and you're asking for the user and the post, it's gonna do a query to both of them, but for your client, for your frontend, this is transparent, which is really powerful. And if you work with frontend,
there are clients that make, dealing with GraphQL really, really easy. You don't have to do much. For example, I was on Meetup a couple of weeks ago, and there was a company that was using REST, and they were saying, we spend about two thirds of our time on the frontend dealing with data. So fetching the data, normalizing it, storing it in our temporary store,
and then showing it on the frontend. And with GraphQL, the first three steps are basically already done for you, because you use a client, you define this as you want, and then you get it back. And if you wanna see some example on the frontend, you can talk with me later. But yeah, we use Python, and we love Python.
And I think Python syntax is really beautiful, and especially with Python 3, with the additional features that we've seen, like for example, typings, which I think is my favorite feature in Python 3. So typings are basically a way to annotate functions and variables and classes with types, and you can use this type, for example,
you can do type checking, so you can check if your function is being called with the correct variables. And you can also use this at runtime, using tools like Inforce, where you can say, I want this function to raise an error if the type that's being passed is wrong. And this, it's not what you usually want,
but it's useful in some cases, especially if you're dealing, for example, with external APIs, and you need things to be in control. And you can also, there is also things like mypyc, that it's optimizing your, it's kind of compiling the code in a way, or using the type annotation as a hint. And then the other feature that I really love is called data classes,
which I think it's been inspired by actors, if you know the module, and it basically is using typings to allow you to create a data container, so a class that only holds data in a very simple way. So this decorator, what it's doing is getting all the fields that you see there, so here and not in this, and then it's creating the init method,
representation method, and other methods that you could use for like sorting, comparing components in this case. And it's really powerful, because with four lines, you've done something that you do here with 30 lines. And Python and GraphQL, I mean, if you've seen it,
this, the previous data class, it kind of looks like a GraphQL type, so in this case, we have same class, which is called Europipe, and then there are two fields, and the type. So I created a library called Strawberry, where you can use this decorator called Strawberry type, which is basically doing what data classes is doing,
which is actually using data classes on the node, but it's also creating GraphQL type, so you can use this, and create a server based on that. So yeah, the library is called Strawberry, and the reason why I created it, it's mainly because I wanted to have fun and learning, so I wanted to experiment with basically creating a new library,
thinking of how could people use this, how to make it easier to use, and also the reason is I want to experiment with new features, because GraphQL is quite new in Python, and we are still not, I mean, if you've seen, if you check JavaScript, there are so many libraries, and they are doing so many cool things that I think it's worth having them in Python as well,
especially because Python is much nicer than JavaScript. That went too fast. And also the other thing is I really want to improve the ecosystem, so we now have four libraries. When I started this, we had two libraries. One was using production, but it wasn't really updated over time,
so I think having other libraries that are trying new things, we can share experience, we can basically cross-pollinate each other with ideas and improve the whole ecosystem, hopefully. So how does it work? As I said, it works with typings and data classes, so let's see an example. This is the schema that we had before,
so we had menu item, category, and as you can see, it maps one to one to Python, more or less. But yeah, as you can see, there is no way, we're not fetching any data here, so I was thinking how to pass the data. There are two options, so one is to kind of pass a function to the fields,
but the other option is this one, which kind of looks like a property in Python, so you use a decorator, in this case, strawberry field, and then it's using typings again to basically understand what's the type that's been returned, so this is creating a field on the query called categories that returns a list of categories, but you can also get a max categories argument,
so in this case, it's doing a fetch of the categories passing either 10 or whatever the limit that you pass to the argument, and I'm gonna show a demo of this quickly. So yeah, this is what we had before, so again, we can get a list of categories,
then for each category, you can get the items, and so basically, it's like 20 lines of Python to have this,
which is quite cool, and you can also specify arguments to the fields, so I think this is one of the most popular things in GraphQL, so in this case, it's only returning one category, and it's really powerful because, for example, you can have a field that can return, for example,
the height or something, or the dimension of something, and you can specify the unit, so it can be like using a metric system or an imperial system, and you don't really have to do different points of passing filters, get parameters.
So yeah, the current features are, it supports async, so you can do async.io stuff, so it supports subscription, which is using async.io, so it's really simple to build something that are listening to PubSub and sending an event back to the front end,
supports mutation queries, there is a debug server that kinda works, doesn't really work with async because it's been messy, I didn't really spend much time on it, and then there's support for ASCII, ASCII is asynchronous implementation of WSGI, so it's basically, it's WSGI but works with async, and I think ASCII3 basically means
that it works with any ASCII server, so you can use select, you can use responder, bocadillo, and so on, and soon, I'm trying to work on the docs, I got a bit stuck with the design because I really like things that are really nice to look, and then when I have a design, I'm gonna finish that. Then I wanna make it stable,
so we're gonna use this hopefully for, if you know PyCon Italia, we're building a new website, and we're probably gonna use Strawberry for the API, and that means I have a production project where I can test this and make it stable, so we wanna have Django support, a friend of mine is doing Django support, which should be ready hopefully in less than a month,
then Apollo tracing, which is basically a way to do metrics, analysis on GraphQL APIs, because you don't have, it's a bit different, and you can, for each resolver, you can track how much time a field it took to load, and then field permission, which is gonna work similar to Django's framework, if you're familiar with that,
but you can specify a list of classes on each specific individual field, and then you can validate, for example, if a user can see the field, and so on, which I think is really powerful because it allows you to reuse types and without having to worry, for example, without having to create a public user and a private user,
you can basically check, for example, in the email, you can say, oh, I only wanna see the email if the user is the current user or is an admin, which is really powerful. So I really wanna see more people using GraphQL in Python. It doesn't really matter if it's my library or any of the other three,
so Graphene, if you wanna use GraphQL right now in production, I think the only library that works and has been used in production is Graphene. Then there are the other three. So Strawberry is the one I'm working on, and then there is Ariadne and Tractifred, and they are new, and they take two different approaches. So they use, instead of writing Python to define the schema, you write the schema
as a string, as a file, and then you can attach resolver functions, basically, to your types, to your fields. So it's a different way of defining the schema. I recommend check them out because they are really, really interesting, and there are different ways of doing the same thing. It could fit what you're doing more.
So yeah, let's go and build better APIs. I think as web developers, we should focus on creating APIs that are really easy to use for our developers or front-end people or clients, people working on mobile apps, but also APIs that are really user-friendly,
so APIs that don't waste data for users, APIs that don't, yeah, don't waste the bandwidth and the CPU of the user, because yeah, we are now in Switzerland, and everyone that's coming outside, they're using roaming, and roaming,
most of my friends, they have to pay for it, and it's really expensive. So even in first-world countries, we still have issues with data being expensive. So let's try and build better APIs. Yeah, my name is Patrick. All the information out there, that's my Twitter handle. If you have any questions, happy to take them. Thank you.
Thank you, Patrick. So do we have any questions? Please come to the microphones. Yep, seems we have a question. Thanks for the good speech,
and I have a question as a back-end developer or a system administrator, let's say. We have a GraphQL endpoint implemented on production, and I noticed that I have a huge load on my database,
and what kind of tools do I have in GraphQL to investigate that situation? Because for using REST, I can try to find what calls were made and what data was retrieved, but for GraphQL, maybe it can be a little covered.
Yeah, there is a lot. In Python, there is not much, though. So what you can do, especially if you're using Graphene and Django, there is a tool called Graphene Django Optimizer, which is basically analyzing the query that's being received by your back-end, and it's trying to do fetch-related,
select-related for you. The other things would be to implement a middleware that's doing the tracing support, so you can send information to Datadog or maybe the Apollo tracing server, but right now there's nothing built into Graphene or any other library. There are other things you could do to improve.
For me, there are kind of work-outs. You can use data loaders, so basically there's a way to postpone the fetching of some information. So for example, if you're fetching, I don't know, like a list of blog posts, and for all of them, you're fetching the user as well
with a different query. You can get the list of IDs that you're fetching and then doing it later. So when you know all the IDs that you need, you can fetch them, so you don't do n plus one query. But yeah, we can also talk about it later. There's a lot. Any other questions?
Okay. Hello. Thanks for the speech. So I'm new to GraphQL. I would like to know how do you connect this with your database, because this is not evident to me. Okay, so connecting, I mean, it's like REST API,
basically you have an endpoint where you do data fetching and then you're returning. So you have Python functions where you get the data and you do this for each field that you have in your API. If you use something like Django, if you use Django or SQLAlchemy,
you can use Graphene, which has Graphene, Django, Graphene, SQLAlchemy, where you can get a Django model or SQLAlchemy model and it's converted into a GraphQL type. And so you don't have to write the GraphQL type again, but you still have to do the queries yourself. There is also some tools like,
there is support for Django filtering Graphene as well, so you can plug that in and it also gives you arguments so you can do filtering on the front end. Any questions? Don't be shy.
Okay, we have one question. Can you go into a bit more detail of the differences with Graphene and why you had to do something new?
Okay, so when I started this in October, when Graphene was, so basically the main maintainer of Graphene stepped down and he was basically working on the project, but the problem was that he didn't give access to maintaining the Graphene 21.
So basically it was a moment where I was doing progress. I did a couple of progress, like the Django framework support for Graphene, it's something I've done. But yeah, I was trying to, and to contribute, but there was a lot of friction because basically no one was able to merge stuff. I think now in April we got access to GitHub
and PyPI to publish things. So now there's people working on it. I'm trying to work, but I'm focusing mainly on this instead also because I want to experiment in the future and try different ways of doing things. Okay. Any more questions?
Okay. Thank you for your talk. I was just wondering how you feel about schema first development versus the code first? Oh yeah, so as I mentioned, the first two are schema first, sorry, code first, and the other two are schema first. I prefer code first,
especially because I said Python is really nice to write and especially with Strawberry, you can reuse types, you can reuse data classes that you already have, wrap them as a graphical type and it works, and you get auto-completion on this stuff. While schema first is a bit different.
This is my personal preference, I don't like schema first. There are people that like them, especially I think there are libraries doing that. And I think I don't like writing things twice because you have to write the schema and then you have to attach it and you need to be sure that also
you're doing things in the right way, because if you mistype something, it's not working. But yeah, it's a matter of preference, I guess. Yeah, I mean, there might be some cases where you, not sure, I can't think of any, but there was someone building a dynamic schema
and they needed to do schema first because they had like a schema as a string, so we couldn't cut anything together. But I didn't see that being something common. Thanks. Okay, other questions?
Okay, thank you, Patrick.