 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, SCP was introduced in 1991. And then after that, we've seen things like, for example, Geocities, which allow people to upload websites online without having to know what a server is. And that was something, 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 like Web 2.0, which is the second version of the web, where the focus would be more on user generating 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. 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 the operation of your resources. So for example, you can do a get, get a list of posts. You can do a post and create a new post or change it. Then you can 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, such a network. And this is quite important because they start having problems that normally you wouldn't have because they start having, like, billions of users, thousands of millions of different devices. And also, the problem is 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 applications. And in current days, the web is still evolving. So we don't have collections of documents anymore, but we have apps. And these apps are not simple applications. 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 study the website because the developer experience much nicer than what it was before. So we start creating APIs. Is APIs to basically allow a client to communicate with a backend or also communicate between different backends? Or just even if in a stopper, you could have a front-end team and a back-end team. And you would have APIs to basically connect them together instead of building like a monolith, for example. And REST became industry standard, 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, underfetching, which basically means you do a request, and then you have to do more requests to get more data. All the other data you need, for example, you have a blog post where you want to 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 overfetching, where you send 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 would 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 documentation is still painful because there are this bit of manual work to do. So we start looking for some alternatives. And we're thinking, what if the clients that we have could declare the data that we need 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 would respond with this. And this is basically what GraphQL is. GraphQL is a queer 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. It can be used with HTTP. It doesn't have to. So you can use it with WebSocket as well or any other protocols if you need to. 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 boss 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 have a GraphQL API as a schema. And a schema basically solves 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. 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 bigger demo later. Didn't change. Okay, so I was only talking about querying now. So this is how you do a querying in GraphQL. So you can specify the operation type, which is querying 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 everything 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 called ID to the edit category mutation, and then we are passing a hard-coded title in this case, and then we're fetching the data. So basically, mutation, they basically work the same as queries, so the same syntax and the same results. 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. That can be what you want. Then the other one is, for me it's really interesting, it's subscription. So it's an easy way to subscribe to an event happening on the backend. So in this case, we can subscribe to an event called onCategoryUpdate, and every time this event is called, we get the data back, but only the data that we requested. So it's really powerful. You have one way of declaring data that you need for all 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 you, the user in the post is gonna do a query to both of them, but for your client, for your front end, this is transparent, which is really powerful. And if you work with front end, there are clients that make dealing with GraphQL really, really easy. You don't have to do much. Like 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 front end dealing with data. So fetching the data, normalizing it, storing it in our temporary store, and then showing it on the front end. And with GraphQL, the first three steps are basically already done for you. You can use a client, you define this as you want, and then you get it back. And if you wanna see some example in the front end, 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 it's 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 these types, for example, as 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 runtime using tools like Imports, 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 why 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, kind of compiling the code in a way, 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 he's doing is getting all the fields that you see there, so year and attendees, and then he's creating the init method, representation method, and other methods that you could use for sorting, comparing components in this case. And it's really powerful because with four lines, you've done something and you do it 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 EuroPython, and 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, just actually using Data Classes and the dude, but it's also creating GraphQL type, so you can use this and create a server method. So yeah, the library is called Strawberry, and the reason why I created it, it's mainly because I wanted to have final learning, so I wanted to experiment with basically creating a new library, thinking how could people use this, how to make it easier to use, and also the reason is I wanted to experiment with a new feature because GraphQL is quite new in Python, and we are still not, I mean, 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. Ooh, that went too fast. And also the other thing, it's really wanna improve the ecosystem, so we now have four libraries, but when I started this, we had two libraries, one was in 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 old 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 kinda pass a function to the fields, but the other option is this one, which kinda 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 maxCategories 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 gonna show a demo of this quickly. So yeah, this is what we have 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, which 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 or something, and you can specify the unit, so it can be like using a metric system or the imperial system, and you don't really have to do different points or passing filters, get parameters. So yeah, the current features are, it supports async, so you can do async all your stuff, so it supports subscription, which is using async.io, so it's really simple to build something that's listening to PubSub and sending an event back to the front end, supports mutation queries, there is a debug server that kind of works, doesn't really work with async because it's been messier, I didn't really spend much time on it, and then there's support for ASCII, ASCII is a synchronous implementation of WISCII, so it's basically, it's WISCII but works with async, and ASCII 3 basically means that it works with any ASCII server, so you can use Salette, you can use Respond, Bocadil, 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, 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 REST 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 it's really powerful because it allows you to reuse types and without having to worry, to, 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 Graphine, if you wanna use GraphQL right now in production, the only library that works, and it's been used in production is Graphine, then there are the other three. So Strawberry is the one I'm working on, and then there is Ariadne and Tartiflet, and they are new, and they take two different approaches. So they use, instead of writing in 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 checking them out because they are really interesting, and there are different ways of doing the same thing, which 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 client people working on mobile apps, but also APIs that are really user-friendly. So API that don't waste data for users, API that 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 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, I'd be happy to take them. Thank you. Thank you, Patrick. So if you have any questions, please come to the microphones. Yeah, seems we have a question there. Thanks for a good speech, and I have a question as a backend 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 retrieven, but for GraphQL, 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 use Graphine and Django, there is a tool called Graphine Django Optimizer, which is basically analyzing the query that's being received by your backend and is 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 Graphine or any other library. There are other things you could do to improve. For me, there are kind of work-hounds. You can use Dataloaders, so basically there is a way to kind of 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 later, and there's a lot. Okay, 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 the data fetching, and then you're returning it. So yeah, point on 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 SQL Alchemy, you can use Graphin, which has Graphin, Django, Graphin, SQL Alchemy, where you can get a Django model or SQL Alchemy model and it's converting to a GraphQL type. And so you don't have to do right the GraphQL type again, but you still have to decrease yourself. There is also some tools like, there is support for Django filtering Graphin 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 Graphin and why you had to do something new? Okay, so when I started this in October when Graphin was, so basically the main maintainer Graphin stepped down and it was basically working on the project, but the problem was that it didn't give access to maintaining the Graphin to anyone. So basically it was a moment where I was doing progress, I did a couple of progress, like Django has framework support for Graphin, it's something I've done, but yeah, I was trying 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 many on this set also because I want to experiment with new feature and try a different way of doing things. Okay, any more questions? Thank you for your talk. I was just wondering like how you feel about schema-first development versus like 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 as I said, like 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-comparison 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 there are libraries doing that and I don't like writing things twice because you have to write the schema and then you have to touch 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. 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're concatenating together, but I don't see that being something common. Thanks. Other questions? Okay, thank you Patrick. Thank you.