The Python Podcast.__init__

Share on social media:

[00:00:12] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode. With 200 gigabit in private networking, node balancers, a 40 gigabit public network, fast object storage, and a brand new managed Kubernetes platform, all controlled by a convenient API, you've got everything you need to scale up.   And for your tasks that need fast computation, such as training machine learning models or running your CI and CD pipelines, they've got dedicated CPU and GPU instances.  

Go to python podcast.com/linode,   that's l I n o d e, today to get a $20 credit and launch a new server in under a minute.   And don't forget to thank them for their continued support of this show. Your host as usual is Tobias Macy. And today, I'm interviewing Sebastian Ramirez about FastAPI,   a framework for building production ready APIs in Python 3. So, Sebastian, can you start by introducing yourself? Hello, Tobias. Thank you very much for having me here.  

[00:01:12] Unknown:

Yes. So I'm Sebastian Ramirez. I'm a software developer from Colombia. That's why the accent.   I'm currently living in, Berlin in Germany. I work for Explosion,   which,   they're the creators of spaCy, the NLP   package, and Prodigi, the machine learning annotation tool. So, yeah, that that's me. And do you remember how you first got introduced to Python?   Yeah. Well, actually,   I started doing, like, web development and just, like, plain JavaScript stuff even before there was, like, a Node. Js   or at least it was not, like, mainstreams. And I was doing, like, a bunch of, online courses,   everything   in JavaScript because that's all I knew. And then at some 0.1 of these courses required doing Python, and I was like, yeah. Well, let's just try it. And I just started the course without knowing Python and just trying to learn it on the, while I was, taking it. And I ended up liking it a lot and, like, ended up, like,   from then on, I ended up building everything mainly,   in Python.  



[00:02:15] Unknown:

And so now you've been working in Python for a while. You're working for a company that is making good use of it in the machine learning space, and you've also ended up creating this web framework. So can you start by describing a Yeah.   So  

[00:02:38] Unknown:

Yeah. So, well, FastAPI is a web API framework for building   modern applications. So it has, like, high performance. It's easy to learn. It's very fast, to code. Like,   writing the code using FastAPI is, very fast and easy. And, like, it's ready for production. Like, it's being used in several production applications,   in several places, and, it's all based on standard Python type hints, type annotations.   So   by using these modern, like, recent type annotations, you get auto completion everywhere in, like, all of the editors   and also type checks. So, like, you get type checks for free in your editor that tell you, like, hey. You cannot, like, combine this string with an integer or stuff like that that you wouldn't get if you didn't, like, have these type,   annotations.  

That's all by using plain type annotations in Python. But then FastAPI   uses those standard type hints   to, generate automatic   API documentations   and to do to do validation for the data   and serialization, like data conversion and all this stuff. And this is, like, all   mainly for building   JSON   web APIs. So that's, like, more or less, like, what FastAPI is. Now what are the, like, the the frustrations or, like,   things that made me   end up building FastAPI?   I I I prefer to think, of it, like, as inspiration   from other frameworks and also, like, other tools. They're more than frustration because, like, there have been, like, a lot of,   ideas   that have been taken, from,   different places that ended up, like, in FastAPI.  

So, for example, you have, like, a Django rest framework. That was 1 of the first things that I saw that provide, like, automatic API documentation that was, like, amazing. And you have, like, the simplicity of Flask that you can build, like, a very simple application that doesn't even require a database   system for building an API for, like, you know, for, cases that don't require a database. And, like, there's, like, a bunch of frameworks and idea that come from other places. For example, at some point, they created this standard, Swagger, that then became OpenAPI.   These tools didn't even exist before   when there were, like, like, these standards didn't exist,   when they created the previous frameworks. So   then, like, there were a lot of additional tools to integrate these standards with the frameworks that already existed. And they, like, did a a lot of a of work, and they did a great job with the tools and the capabilities that were available at the time. What FastAPI did was try to take, these ideas and, like, combine them with, for example, with the new ideas of new frameworks like Sanyk that provided a very high performance   web framework for Python. I was, like, on par with the Node. Js and stuff like that. And then they combine   this performance   with the standards, with the tooling, and all the ideas in a new framework that was all based on some of the Python type annotations. And this is probably the main thing that FastAPI did on top, which is, like, having it all based on standard Python type annotations.  

And it's all powered,   underneath   by Starlet, which is like   the, 1 1 of the,   at least, 1 of the fastest,   Python frameworks. But, Starlet is mainly like a bare bones   framework or toolkit for building   tools on top of it. And then FastAPI uses that, and on top adds by Dantic.   That is the thing that, those all the data validation and parsing and all this stuff. So, like, there have been, like, a lot of tools that have inspired the things that are done in FastAPI. And then, like, the additional stuff that I was trying to solve that was not yet solved that ended up, like, giving birth to fast API was to make it all based on the open standards, like OpenAPI and JSON schema and, OAuth 2, which is, like, integrated into OpenAPI.   And to, with that, to have, like, automatic documentation,   using, for example, Swagger UI or, Riddick, which are tools that are,   based on these same standards. So, like, by by being based on standards, it's easier to integrate everything together and to build, like, a more powerful tools that are, like, supported,   on each other. So, yeah, that's, like, the the main things that ended up, like, making me,   build FastAPI   to to provide these new  

[00:07:07] Unknown:

these new tools and these new ideas on top of the ideas from, many, previous frameworks. And what are some of the types of projects that you were working on that motivated you to put in the effort to actually build out this new framework using all these capabilities from the tools that came before and some of the main use cases that you had in mind as you were designing the initial implementation of the framework?  

[00:07:29] Unknown:

So, like, at first, I actually had, like, a bunch of, combinations of   tools and plugins   with,   other frameworks, like with Flask and stuff to, like, try to achieve   more or less what I was trying to to do. And I was working for, like, several startups before, I joined explosion. And, like, I I got the chance to build many different projects, like, from scratch. So I was able to improve every time where were the tools that I was using for each 1 of these projects. Most of them had to deal with, like, data handling and machine learning and, like, data processing and stuff like that, which is, like, kind of a common case, currently. But also, all of them also have, like, a lot of simple   CRUD, like, create read that they delete data management,   which is, like, very generic and applies to many, applications or most of the applications. So this it was actually, like, building all of these new projects, 1 after the other, that I ended up, like, building this combination of tools and plugins. And that combining those ideas with the new tools that I was learning to use and to apply,   that I ended   up thinking that maybe it was a good idea to combine those new tools with all these previous techniques that I was already saying. And another  

[00:08:48] Unknown:

interesting element of the current trend of web frameworks and web development is this focus on API first   frameworks and issuing some of the end to end capabilities that are built into some of the earlier generations such as Django, where it incorporates the view layer and the HTML generation. And I'm wondering what you find as being the benefits of building the API first or API only framework,  

[00:09:14] Unknown:

and some of the challenges that are imposed by having that incorporation of the view layer in the framework itself? Yeah. So, like, many modern applications end up having, like, a separated back end and a front end. And in many cases, it's even, like, front end team independent of the back end team. And because, like, many more applications end up using the building the front end with JavaScript library like React or Vue JS or Angular or things like that. And then they end up communicating with the back end through an API.   That that has the benefit of, like,   surprising, like, concerns   between the front end and the API. And they're also, like, has the the the possibility to, like, build an API that is not necessary only for a front end, but also   a system that service that can be used by another back end systems, by another back end, services, by mobile applications.  

So I guess, like, that's probably 1 of the main benefits apart from, like, all the improved   user experience from this, modern UI frameworks. But, yeah, like, that's probably, like, what I think has been driving this, tendency of separating the the API from the front end every time more. Nevertheless, like, if you want to,   use, like, as like,   let's say, a a common approach or a a a an older approach of having the the front end built with templates in the back end. You can still do that with FastAPI using Jinja templates, and you can use, like, SQL alchemy models. And you can, like, end up having, like, a very,   let's say,   early age   standard   framework. It probably won't show much of the benefits of FastAPI, but, yeah, you can actually, like, do that as well. And not to go too far down the rabbit hole, but 1 of the challenges that I've seen with  

[00:11:02] Unknown:

building these 2 separate layers of the API server and then the JavaScript application that interacts with it is the fact that on the front end, you end up having to do a lot of the same data validation that you would be doing in the back end if it was a fully integrated system. And I'm wondering what your thoughts are on that briefly. Yeah. That's actually quite a quite a common, problem, and I think that's something  

[00:11:24] Unknown:

that using open standards can help a lot. In FastAPI, when you build an application with FastAPI,   if you want it or not, you end up building an application using an open standard, which is called OpenAPI. An OpenAPI uses, the standard JSON schema for declaring the validation   for the data types and, like, the shapes. It declares, like, validation and also, like, the shapes of the data and where are the types and where are the   valid types of any interaction with data. You can actually and that's also something that we have done. You can actually extract these JSON   schema definitions   for the entities, let's say, for the post request that your API is going to expect. And then you can use that same JSON schema and integrate it with a front end framework.  

There are, for example, plugins for React, that allow you to generate a form based on that JSON schema and apply, like, the same  

[00:12:15] Unknown:

validation that is going to be applied in the back end. So it's actually something that can get some benefit from the fact that that it's using some open standards. And there are a number of other different fashions of web APIs that have come about, and there are some different generations. OpenAPI being 1 of the more recent ones, and another being GraphQL. But there are also things such as JSON LD or the sort of quote unquote traditional REST. And I'm wondering what's involved in adding support for some of those additional specifications   beyond OpenAPI?  



[00:12:46] Unknown:

Yeah. So OpenAPI is more or less, like, a way to define,   kind of bare bones,   REST API more or less, like, all based on JSON, but it's, it doesn't, like, assume much. So you can build almost anything with, open API. With something like a JSON LD, which is JSON linked data that assumes   a little bit about how is, your data laying on the underneath. Like, what are the relationships that your data has? So to build something integrated with JSON LD,   whatever tool you use, it will require,   the tool to know also how the data is stored and how it's a how it's how the data is communicated and, like, handled in the database. So it will also depend on the database.   So it it requires,   the tools to be tightly coupled, and,   that's something that you're not necessarily always have the chance to do. For example, if you are using a NoSQL data   system like MongoDB or Redis or Cassandra or I don't know, You don't necessarily   have, like, a very straightforward   way   to define where the relationships   between entities. You might not have, like, multiple interconnected   entities whatsoever, or you might have, like, different types of data that is cached and then not cached. And so adding these tools requires a bit more of integrating them into the the actual, like, data storing layer. But, of course, you can also do it. There there's people, like, building,   this   additional   for example, JSON LD is still, like a web API,   like a web API system and can be built on top of open API. And there's people, like, building I don't remember if you got JSON LD. There's also, like, others building another of this JSON based, APIs. I don't remember exactly the name. But, yeah, you can absolutely do that on top of FastAPI,   but you will have to build some parts that integrate with the 2 with the, like, the data storage directly. For GraphQL specifically, GraphQL   is kind of its own standard. It has its own way to define data, its own way to define how to query the data. And it actually doesn't use that much, like, HTTP standard parts. It uses post for everything. And, like, there are some things that you can do, and there are some cases that it solves very well. For example, if you have deeply nested   relationships and you want to query very specific data that that has to traverse, like, these relationships. Right? And you want to query some specific data in the nodes of these relationships,   GraphQL is a very good tool to solve that problem. But for many other problems, it's like the, it's not necessarily the best approach to solve it. For example, you wouldn't necessarily use GraphQL for a machine learning API that only receives some type of data and returns operation because that will require, like, even making the clients   talk in GraphQL. So it's, very good for some specific use use cases, not necessarily for all of the use cases, But still, GraphQL ends up requiring specific libraries that are dedicated specifically to GraphQL, and the part that the API has to do is only provide provide   a single post endpoint. So if you want to do GraphQL   with FastAPI, you will probably use a tool like a a Reactney  

[00:16:06] Unknown:

and connect it with FastAPI, and then you can provide more stuff on top of FastAPI. But, it's probably, building stuff with GraphQL probably requires a bit more of GraphQL specific levers. And as we mentioned before, there are a number of other frameworks available just in the Python ecosystem for building various types of web applications. I'm wondering if you can just give a bit of your sense of where FastAPI fits into that broader ecosystem   and some of the reasons that somebody might choose FastAPI over some of the available options.  

[00:16:37] Unknown:

Yeah. So, like, for example, 1 of the ways people might want to use FastAPI is to complement some existing applications. Let's say you have a Django or a Flask application,   and you want to add   additional features on top that are just, like, purely   API based and you want to integrate that with the rest of your application,   You can generate database models that use the same database that your other application is using, and you can add these extra features on top with FastAPI that will be probably   a a lot faster to write the code itself.   It could improve performance. It will probably improve performance   because FastAPI gives you performance that is, like, on, on par with Node. Js and Go,   it's a bit faster than some of the Go frameworks. And that's, like, pretty cool given that Go is a compiled language. So, like, it's for some cases where you need to add performance or when you need to add WebSocket support or when you just need to, like, build some extra features   that that   API based, that will probably be a good that will probably be a good use case. And nevertheless, there there's a lot of people that are migrating,   their current applications to FastAPI just because it ends up easier,   to, like, manage the same code base. And it's for   some of these users, it ends up being, easier to, like, manage fast API code. But yeah. Like, also, like, if you want to build new features, if you want to build a new project,   if you want to reduce   a code duplication,   and, like, the the fact that it provides automatic documentation   that can be used for by clients, by the front end team, by all the back end teams, that's also probably a like like like a selling point for FastAPI because   in in this new startup   world we live in where, like, there's   deadlines all the time, and there's not not not a big chance to, like, build very thorough documentation of every feature that you build.  

Having the tool generate the documentation for you and the validation and the serialization, everything just by you writing your code normally. That's that's something that is probably quite, appealing. And you mentioned that the type annotations being a first class concern of the framework helps with the developer ergonomics.  

[00:18:51] Unknown:

And I know that in reading through the documentation,   that was also a consideration in terms of how you built it to be optimized for developer workflow with the editors that most people are using. Wondering if you can give a bit more of a background of the design philosophy   and your overall approach to building out this framework and the considerations  

[00:19:12] Unknown:

that were incorporated into it? Yeah. So, actually, like, the design of how the how the the API let's say, like, the the API to use a package, not like how you build an API. But, like, the design of how FastAPI itself works have, like, a lot of just   design itself of how it should feel like, of how you should, like, work with it in the editor even before writing the internals of the code. And then the the internals of the code were written to match,   those expectations and those ideas that I wanted to have because it it's all   made so that you can have all the completion everywhere for almost, like, everything or, like, for everything.  

Everywhere you can have auto completion with FastAPI, you will have it because,   most of us, like, mortal developers that can't memorize   everything,   use a lot of these, auto completion. So it was made to to work with that. Another key factor in the design was to reduce code duplication so that, you don't have to declare   the same data in multiple places. But that you can declare, like, in 1 single place, and then,   that's the only where a place where you have to declare it. For example, if you declare that you're going to receive a body and the body has to have some specific shape and has to be invalidated in some specific way and is documented   as having that shape, you only have to declare   that a type once, and then the rest is done automatically so that you don't have to duplicate code in different places. But then you have to make sure you keep in sync, and then you have to make sure that,   it's not obsolete. And whenever you refactor it, you just have to change it in 1 single place. So that was another of the key factors. And the other key factor was that the whole   framework   is built around standards. The whole framework is built around open API, JSON schema, and o f 2. So,   like, the way that you interact with it, the metadata that you declare, everything is made   to match these standards so that you can very easily build something that is already,   like, let's say,   applying best practices and following standards just by writing   your standard   common code. So  

[00:21:23] Unknown:

I think that those are, like, the main key factors in the API design. And I know that you also built the Typer framework for building CLI applications with some of these same concerns in mind of improving developer ergonomics and being able to lean on type annotations   for automating a lot of the ancillary   aspects of building out these different programs. And I'm wondering  

[00:21:47] Unknown:

what the relationship is between the 2 projects and how working on 1 influenced your thoughts and design decisions on the other. Yeah. So while building while working with FastAPI and, like, using these type annotations and realizing that it was actually useful, and it ended up being a good idea. And being able to use just functions and declare standard Python type annotations   was a good idea and that it was it improved, like, productivity and stuff. Then I I I also realized that   there was   a no no framework for doing the same for for command line applications. There were several. There were several, like, inspirations and and tools. For example, Hug,   which is also an API   framework, API and CLI.  

HUG was built before there were, type,   annotations. So it wasn't able to use   standard type annotations   internally. So the way you you create a code is not as simple as just, like,   writing standard standard Python code with annotations. But it's still, like, it has it had all these ideas. And, there were several others that had these ideas of annotating the data, declaring   a additional metadata and the validation and stuff in the same declaration of the functions parameters.   And the I just realized that that there was no tool providing,   that way of interacting with it and that way of, like, using it just with plain modern Python. So that's why I ended up building a typer. And, like, the design is almost exactly the same as FastAPI. So if you are using FastAPI, using typer is like it feels like doing the same. It would actually what powers typer underneath is click, and it's all just done by click. Typer is just like a very lean layer on top to simplify development so that you don't you don't really have to learn much. You can use type annotations. You can just build a function and then just use type or direct. In fact,   I recently built also, like, typer is the library for building CLIs, but I also built this new package called typer CLI, which is a package to be used in the command line that lets you use any Python file that has a function and can convert it into a command line application   by using that that command line, package. And then you get auto completion for free   for your scripts without having to create, like, a full   common line application   or, like, a full package. So, like, these   these tools and these ideas, like, it's just like to simplify development and to simplify the way you use it so that,   you can, like, you can, like, think the less possible in the library and just, like, the most standard Python   possible  

[00:24:25] Unknown:

to get, like, this functionality. That's that's that's the main idea, I think. Digging deeper into that experience of the developer, can you talk through the workflow of getting started with FastAPI and some of the ways that that workflow evolves as you start building out more complex and bigger applications with it? Yeah. Well,  

[00:24:43] Unknown:

actually,   writing applications with FastAPI   and some, being, like, a lot of just writing the business logic, like, the business logic of your own application.   You actually don't end up writing a lot of FastAPI code itself,   because, like, it just tries to get out of the way. But,   you normally just, like, write your own code and, like,   use the tools and the packages that you would normally use.   For example, you don't have to   to have, like, plugins or integrations for doing most of the things because you can just, like, write   a plain functions   and then, like, for example, use dependencies, which are integrated in FastAPI. And for something to be used as a dependency, it just has to be a function that has parameters. So you can also, like, use standard libraries and standard packages   that you are already using for many of these, tools and features. So it's mostly just like writing your own code. It's just like you add some small layers   on top of the code that you're already writing, and then you get an API. It's mostly that. I think I think that's mostly, like, the workflow that you end up having. I know that with Flask, for instance,  

[00:25:52] Unknown:

if you want to   modularize   the application, you end up using their Blueprints interface   for being able to build out these components that can potentially be plugged into other applications. I'm wondering what the analog would be in FastAPI and how that manifests.  

[00:26:08] Unknown:

So FastAPI has a similar thing, which will be an API router so that you can have, like, a main API in some file, like like, a main API app in some file and then create,   additional, like, routes,   additional routes or additional path operations in some other files, and then you can import them in the main file and just integrate them together. It's actually pretty simple, and you can also, like, add specific requirements   for different subsections   of your application through that. But, it's quite simple, and it's probably similar to Flask Blueprint.   But, yeah, it's it's,  

[00:26:42] Unknown:

mostly that. Digging deeper into FastAPI itself, can you talk about how the framework is architected and some of the ways that its internal design has evolved since you first began working on it? So FastAPI is actually Starlet.  

[00:26:56] Unknown:

Starlet is the the framework I was talking about built by Tom Christie. Tom Christie is the same creator of Django REST framework that I think you interviewed, like, in   February or something like that. FastAPI is actually just a starlet   on steroids,   and the steroids are mostly Pydantic. So   those are the main 2 key components. And what it does is just, like, glue them together. Bydantic is a library built by Samuel Golding,   for doing data serialization validation   and, documentation.   Then FastAPI puts these 2 things together   and adds some,   extra,   layers on top of some extra functionality, for example, handling dependencies because FastAPI has a simple dependency injection system that allows you to, like,   deduplicate   a lot of the code and, like,   modularize   the way,   you add requirements to each 1 of the endpoints.  

But then, like, most of the FastAPI code is dealing with these 2 libraries that are the way what is actually doing the the hard work underneath. And the other the other key thing, I think, in in FastAPI internal is that, there's a lot of code duplication   in fast API itself, like in the internal code,   just to provide a little bit of extra functionality   for, end, developers, for end users of FastAPI.   So for example,   there's a lot of a method,   declarations that include, like, all of the possible   key arguments,   keyword arguments,   for the for the methods and for the functions.  

And, that could be used like just it could have been done, like, just, as   a a kwx   parameter that receives just everything, but I wanted it to have auto completion everywhere.   So there's some extra effort into managing that and maintaining that   just so that we, developers,   using FastAPI,   can, like, have those extra benefits of, I mean, to completion and type checks for everything everywhere.   So those are, like, the the main,   aspects internally of FastAPI. But the the the main work is actually done by Starlight and by Dantica.  

[00:29:11] Unknown:

Yeah. Things like that of exploding the quarks into the   situation of having to dig 3 or 5 levels deep into a different set of function stacks to say, okay, well, here's a quarg that's getting passed into something else. What does that require? And then what does that require to actually finally get the list of accepted keyword arguments rather than being able to have that available at hand at the top level function? So the care that you put into the framework is definitely evident in things like that, as well as the extensive documentation that you've provided, including a lot of the history behind the framework and some of the reasoning behind how you came to these different design decisions. And so I'm wondering   how you managed to find the time to   have that level of care and detail, and some of the challenges  

[00:30:05] Unknown:

that come along with that level of dedication to the framework. On 1 side, exactly what you were saying about the the expanded   QRs   everywhere. Like, that that's something that, has been difficult for me always on, like, having to dig very deeply into documentation of all their libraries to find out what are the available parameters. Like, I wanted people to be able to install and,   almost, like, never come back to documentation because they could just do everything without the completion. So that was some of 1 of the, like, the objectives   I had.  

So I guess that helps motivating.   On the other side, I guess, like, unique   privilege   of working for a company that, gives a lot of value to open source and, like, they give me time to maintain my open source,   tools,   like, apart from Works. So, like, I dedicate, like, some, I don't know,   a a a 5th,   of the of the time I'm working   purely to the open source tools I'm,   I'm building. Also because, like, we use them internally, but,   you know, it's not necessarily   common for a company to like give people time to, develop open sources stuff. So that helps a lot. And on the other side, I think I have a very patient wife because I dedicate a lot of my free time just to these open sources. So, like, all the afternoons, all the weekends, I end up, like, solving another issue and doing this things. But but it's also, like, because I really like building the tool. I like using it, and I like, enjoying   how it works. So I want to build it, to solve my use cases too. But I really like,   the feeling of,   helping others and knowing that it's being used by others and that is helping others, like, building to their tools and, like, help them solve their   social problems, their community problems, like the their products and, like,   like yeah. I really like the idea of helping others build stuff. I'm, like, just doing a little bit,  

[00:31:59] Unknown:

extra to to help with that. Going back to the design of the framework, you mentioned that it has built in dependency injection capabilities.   And because of the way that it's designed, it's possible to just import different Python libraries   and start using it right away. But I'm wondering what are some of the specific extension points that you have exposed for people to be able to build various plugins for FastAPI and build out more of the ecosystem around it? Yeah. So on 1 side, yeah, dependencies are, like, 1 of the main points where you will add, stuff because you can add, like, for example, database  

[00:32:35] Unknown:

session management, you can do it independently,   but you can also, like, add authentication   and security and authorization stuff in dependencies. So there's a lot of stuff that you can do in dependencies that gets executed   even before   your root,   handler functions,   is executed. So that that's probably 1 of the main points where you will extend it and that you don't actually have to create a new package or, like, a plugin or something. You can just, like, import the tool that handles, like, datavizations and just add it in a in a function. Unlike a dependency, it's a fancy word, that in the end is just like a it's just a function.   FastAPI is just a function, and you just add it there,   in the in the as part of the parameters   of your endpoint handlers. The other main point of extension, I will think is the ASGI, the ASCII spec itself. ASCII is like this new standard. I know you know, but for for those that don't, ASCII is the new standard comparable to WSI to use the was key. I never know how to pronounce it. And ASCII   it has all these   definitions and all these ideas of how to interact between   an HTTP server and the Python code. It has it defines all those interactions, and there's a lot of stuff that you can plug in that is, automatically   compatible   with all of these ASCII frameworks. So you can find, like, any plug in for ASCII, and it will be compatible   with FastAPI.  

For example,   you want to add the tracking with some API   monitoring system. There's there's an I a a an ASCII plug in for that, or you want to add Sentry   to your API. There's an ASCII plug in for that. There there's a just, like, a lot of these plug ins that are built just for plain ASCII, and you can just add them   directly. You can also build 1 of those,   but, I guess people is probably   gonna just end up, using a lot of the already existing ones. And then, like, a more a hardcore   level of extending fast APIs, you can also declare   your own root class overrides.  

So you can define   the extensions to the internals of fast API itself   and the way it handles, like, a the function that you declare for your API. This is probably quite more hardcore, and I wouldn't expect many people to need   to do that. But,   you can do it. And for example, there's this package called fast API utils, by David Montag,   that that, for example, allows you to use class based   views. I think that's the the the common term so that you can declare your API using classes instead of plain functions. And that's the way it works. It just, like, adds and modifies these internals   in the ways that,   in the points that you can extend them and that you can override them. So, yeah, there's   plenty of places where you can integrate   and modify and extend the things in FastAPI. But in most of the cases, because FastAPI is quite,   like, plain and doesn't have a lot of assumptions   on your data or your tooling or your   components.  

You can, in many cases, just, like, add your standard   code, and it just works. Like, you don't have to, like, make sure it integrates with FastAPI in most of the case. And as you mentioned,  

[00:35:58] Unknown:

because of the fact that you are building   on top of the ASGI specification   and the framework is entirely built around   necessarily   accessible to users without causing it to be too confusing?  

[00:36:23] Unknown:

Yeah. So, like, the first thing is that, like, the   is, like, incredible. For example, Tom Christie, has done a lot of work with Starlet, with UVicorn.   There's also, like, a lot of people like Flowium on, that is doing a lot of extensions   and ASCII middleware and stuff. Like, it's also 1 of the common terms of HTTPS.   There's also, like, a hypercon there are, like, several   ASCII servers just to start with that. And, like, the the community is great and, like, it's actually   quite healthy, I will say. So it's strange   that the community   is quite new. Like, ASCII and all these async stuff is quite new. But I would say that it's   very healthy and, like,   growing growing very well and, like, creating a lot a lot of innovation   in the area. 1 of the main things I think is, like, difficult   for people   is understanding and thinking about when to use a sync and when not. And,   there's all this idea that if you go async, everything has to be,   sorry, async. If you have if you go async, everything has to be, be async, and everything   has to be async compatible and stuff like that. And then, like, they just end up not using it because they don't necessarily know how to use these functions and where to put the await and where to put the async and all the stuff. But, it's not really like that. For example, in FastAPI,   using the same idea from mister Lev, and it's actually just, like, don't buy star lev, Let's you use standard functions, standard libraries, and it just does the right thing underneath   and runs any code that is not   a async compatible   in a thread pool. So you don't have to deal with any of that, and still you get, like, performance benefits from that. So I think 1 of the main,   challenges,   is that people are scared of these async tools, and then they just, like, end up not using anything at all just because it might be,   dangerous.  

But, yeah, like, you can actually use a fast API without ever writing any async code. So, yeah, like, I I think that that's 1 challenge. The other thing is all their libraries   that rely   very heavily   on thread local variables,   they end up being a problem. Not with ASCII,   just with async in general,   because   in async,   contexts,   a single thread could execute   more than 1 task, and 1 text task could be executed in more than 1 thread. So, like, all these combinations   and the assumptions   or thread local variables   don't hold anymore. And there's actually the alternative,   of context bars   that that is available in, newer versions of Python, and there are, like, back ports and everything. But still, like, there there are some, there are many   older libraries that that, don't   actually, I don't know if that many there are some older libraries are compatible with these new ideas. Yeah. Like,   it's normally some specific   use cases and some specific libraries that rely heavily on these, things. But in most of the cases, it's just, like,   fine. Like, you can just work very well with, with these new tools, especially when using these these ideas and these these functionalities of being able to just to declare standard functions and, like, having the framework, do the right thing for you if you are not using an async compatible or a sync first, library. What are some of the other sharp edges that users should be aware of when they're working with FastAPI?  

I think I think that's   mostly it. Like, handling, older libraries,   I think, is how do all the libraries that depends specifically on thread locals? It's not the dependent threading. Like, they can use   the threading and stuff, but, if they do this magic tricks of using threading local variables,   that's 1 of the cases where it can be   problematic.   And I think that's probably 1 of the main   cases where you where people should be, like,   aware of,   of, that that something could go strange in there. Also, like, the this this idea of just adding a sync to everything   when the the library that they are using inside of a function declared with the sync is actually not compatible with the sync. That that could be, like, a problem and   degrade performance.  

But then in the cases where people don't know   where to use a sync or not use a sync, in FastAPI, they can just, like, use   plain functions without the sync, and it will just do, like, the right thing underneath and, want the great performance. And, like, whenever they get the chance to, like, understand, like, all these sync parts on, like, what, libraries are compatible with each other, then they can take the benefit the extra benefit on the extra performance of that. I think that's probably the the main   sharp edge,   that people should be aware of and, like, deal,  

[00:41:11] Unknown:

with care. What are some of the other   interesting   or unique or underutilized features of FastAPI that users might not be aware of that you think they should use more frequently? I think 1 of the  

[00:41:23] Unknown:

important things that I think people don't   realize   very often is that they can use, for example, for security and authentication and all these things, they can use a combined,   dependencies,   in sup dependencies.   And many times, people end up,   subclassing   the fast API dependencies, and then they end up having to duplicate a lot of the code. I think that's something that has to be improved in the documentation because I guess it's not that obvious. But in many cases, you can do, like, very complex   interactions between the dependencies. For example,   you could require a user to have, like,   like, a token authentication   or a cookie   or to be, like, I don't know, authenticated in some other way. Like, it has to be 1 of those different things. And then you can combine all that with dependencies in a sub dependency that then   is added to to an endpoint   function handler. And then, like, the the way you combine them is just like in a simple function that takes the values from the from the other dependencies. You don't have to create a subclass,   something that does something,   like, quite complex to get all the possible attributes and all the possible values from different places. I think that's 1 of the features that people don't necessarily realize. Another 1 is using all of 2 scopes.  

I think this is probably quite underutilized   because it provides a lot of flexibility, but the same as all of 2, it's a complex oauthru is a complex specification,   and it's like a complex subject. And, it's a complex,   interaction because, like, all the combinations and all the ways that it can be handled, like, all through is that the system that is used by Facebook, Google, GitHub, Twitter, all these guys to provide, like, 3rd party authentication,   and they log in with app x and all the stuff. And FastAPI has a support for all these things, like, built in. But all the way these things   interact with each other is actually   complex   at at the abstract level. Not not even talking about code, like, the way it everything interacts is not necessarily so obvious. So I think it's something that people don't realize that they can actually do with FastAPI. But it's also, like, 1 of the the the points that needs to have, like, even more documentation   in FastAPI itself. I I think those those are the main 2 things that, are probably underutilized   of FastAPI.  



[00:43:43] Unknown:

And what are some of the most interesting or unexpected or innovative ways that you've seen FastAPI used by either yourself and your projects or other people who have been leveraging it?  

[00:43:53] Unknown:

So for example, recently, I saw this,   someone built, the coronavirus   tracker API   with, coronavirus API data. I was like, oh, that's I think that that's very cool that, it can help someone build something that is useful for us, like, as a society right now and be able to, like, get, like, accurate information easily and, like, handle it and,   deal with it with code, which is the thing that we can, like, provide and the the tool that we can use to to help. So I think that that's a very cool use case. Another 1 is that Chad Smith, the creator of PIPx,   created this application called Term Pair, that allows you allows you to,   handle your terminal   from the browser   and, like, see the terminal session live in the browser, and it's all built with the fast API and WebSockets. And I think that was, like, a very,   very cool application that I hadn't thought about, like, that you could actually do that. Then it's, like, all built   with Pass API. That that that was that 1 was very cool too. Another 1 is   xpublish,   which is for publishing x-ray   x-ray   as as an API, which is like a kind of distributed   NumPy integrated with Dask. And then, like,   they publish that as an API through FastAPI. I think that's a very, very cool use case. Also, like, some of the applications build up by Uber and Windows and Netflix, they are using FastAPI in some way. I I will share the links with you later. I think that's it's very cool to   see, like, this, very known companies also using these tools and, like, seem that it's useful for,   all the levels of organizations.  



[00:45:33] Unknown:

And when is FastAPI the wrong choice for a web framework?  

[00:45:37] Unknown:

So if you already have an application   that is not necessarily based on an API, probably not based on API. Let's say you have a Django application and you don't need to add any new features. It's already working. You don't have to change it. Like, there's no need, to migrate it to FastAPI because, like, you know, the the we, as developers, we like to   refactor stuff and change stuff.   But if something is working and it doesn't need to be changed and, like, there's no need for extra performance, like, there's no need to change it. Like, that that I think that will be, like, 1 of the main use cases where you wouldn't want to use FastAPI. Like, if you have something that is working and you don't have to change anything and, like like, there's no need.   Another case is if you are building an application   that is not an API   and that you want and you need to build the whole application with the templates in the back end and you, really need an administrative   interface for, handling the data in a database, that's probably not a very good use case for FastAPI. The thing is that more and more,   these modern applications   require being built, as an independent   API and front end.  

So I think there are more and more fast API ends up being the right choice. But if you are in 1 of these use cases where you,   where you need to build something that is based on back end templates, you are probably better off with,   with, I don't know, with with the tool that you already know. Given that, you can still do that with FastAPI.   You can use Jinja templates. You can use SQL Alchemy database models,   and you can, like, replicate the same thing that you will do, for example, with Flask. But then,   you are not getting, like, any specific   benefit necessarily.  

So if you already know how to do that in some other   way, then you're probably better off, like, with that way that you already know. And another use case is, for building, like, a static website, a static web application.   I think, like, using something in the Jamstack, like JavaScript, APIs, and markdown or or markup will be, like, a better way to handle it. For example, using   Next.   Js or Hugo   or Gatsby or 1 of these tools that generate a static   a static web page or, like, a static web application   that doesn't require   interact doesn't really require any interaction with the back end server,   then, like, there are there are tools for that. And it's it's actually not   related to FastAPI   itself. It was related to building a back end application   to serve something that is actually just like static content. I think there are modern,   ways to do that, in in a better way. I think those those are probably the main cases where FastAPI is probably not the right choice. And in your experience of building and maintaining and growing the FastAPI  

[00:48:24] Unknown:

project and some of the surrounding ecosystem, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?  

[00:48:31] Unknown:

I think I think,   a key,   aspect I think I learned is that it was actually possible.   Like, I'm just like some random guy that had 1 idea and had 1 problem that I wanted to solve. And, like, I just, like, put my work on it, and I just, like,   decided to do it and to try and to solve that problem. And it ended up being quite useful. So realizing that   you don't really need a genius to build a a tool that is useful for others that solves your problems, solves other people's problems. You can be just, like, a very normal person like me, just willing to do the work to solve a problem. That that's all it takes. That, that was a very cool realization. And another 1 was that community actually helps a lot. Like, people are willing to help. I I was   hoping for people to to help and to help others and to, like, join the community and, like, help other people, but I wasn't I was hoping for it, but not necessarily expecting it. And I have realized that there's a lot of people really helping others. Like, when when you go to the issue tracker in FastAPI,   there's a really   very nice people and a bunch of people that are just going there and helping others with their questions. And, like, in the guitar chat that now has, like, more than 700 people. It's just too much,   for me to help everyone that asks   questions there. And and there's a lot a lot of people that are there just, like, helping out helping others, and it's just, like, to help the community. So that that's been something,   an awesome realization,   as well. And, like, 1 of the   unexpected challenges and learning is something like, you know, internals   of Python. So learning a lot of how Python types   work. And so, for example, undocumented features and undocumented ways of how Python handles types   internally,   because   they are used by Pydantic, which is the tool that powers fast API, internally. So, like, handling,   being able to see all these inner workings of these tools is also, like,   mind bending sometimes, but, it's it's a really good   learning,  

[00:50:39] Unknown:

path, I think. What do you have planned for the future of the framework and any   new or improved capabilities?  

[00:50:46] Unknown:

So 1 of the 1 of the main thing is FastAPI has a lot of documentation, but I think there's still a lot of extra documentation to add. I already have, like, my own   internal backlog of the ideas I want to add. For example, I want to add a lot more of out to the documentation. For example, how to use all their authentication providers like,   GitHub, Facebook, Google, things like that, and how to build your own   authentication   provider, and how to build your own   system that allows, for example, 3rd party applications to interact with it in the in behalf of your users,   things like that. There are normally, like, kind of complex studies, but they are quite,   easy to build with FastAPI, but it's just not very well documented yet. So I think that's something that that has to be, documented.  

Another thing is that there are there are a couple of   full stack project   generators   based on FastAPI that   built, like, they help you, like, quick start,   your your application with, the full, back end, simple front end, all dockerized wins with some, with some database and some,   some, asynchronous job handling.   And I have to update some of the parts of it to to, like, use the the latest, like,   features of FastAPI itself. And the the other thing I really want to do is build our React   admin   user interface,   using, like, the new tools and ideas,   in React using TypeScript and using Hooks that has, like, has been, like, a very development   experience. So I think, it's something that it can work very well and can help a lot, too. Like, being able to have, like, a generic admin user interface that integrates with FastAPI. That that's 1 of the main things I have, like, for the long term,   let's say,   future,   for FastAPI.  



[00:52:39] Unknown:

Are there any other aspects   of the FastAPI   project or your work in open source  

[00:52:45] Unknown:

or asynchronous web frameworks in general that we didn't discuss that you'd like to cover before we close out the show? It's it's funny that it seems like this is, like, quite a new, like, all these async ideas and async tools and stuff. And it sounds like it's very new and moving very fast. And it has, like, this probably, like, this feeling of   young and maybe immature or something like that. But then if you look closer   at these,   applications and these tools, like, most of these applications are really lean.   They have, like, very little dependencies,   and most of them have, like, 100%   test coverage,   and they have, like, a lot of, like,   type annotations. Like, most of them have, like, 100%   type annotations. Like, you know,   it feels like if it was, quote, unquote, immature,   it is actually, like, with very, very high standards of quote quality. And,   I think it's it's   it's just like that we want to be super safe   in how we build these things and, like, to make sure that we do the right decisions on the right things in APIs. But even though many of these,   libraries,   have version that are even pre 1, for example, past API is version 0.50   something. But either already has, like, a lot of background compatibility,   layers, and stuff to to be able to be compatible with previous versions of the old libraries. I think, like, the sync ecosystem   is very healthy and actually very mature   even if we, it looks quite young still. And I think,   yeah, it's it's a good time   to start playing with it and start trying these these tools and these ideas and  

[00:54:28] Unknown:

and using these these new techniques and these new tools. Well, for anybody who wants to follow along with the work that you're doing or get involved or get in touch, I'll have you add your contact information to the show notes. And with that, I'll move us into the picks. And this week, I'm going to choose the show Once Upon A Time that I started watching recently. It's a interesting TV series that focuses on all the different fairy tale and fable characters and remixes a lot of the stories that we're familiar with and interesting new ways. So I've been enjoying watching that recently as,   you know, respite from reality. So I'll  

[00:55:02] Unknown:

definitely recommend that for if you're looking for something to watch. And so with that, I'll pass it to you, Sebastian. Do you have any picks this week? That's very fun. I know my wife really likes that show too. I haven't watched it yet, but, I know she she really taste it. And, yeah, I have, like, a couple of picks.   1 is the Cloud Atlas   movie. It's actually super long, and I think that's why many people has not watched it yet.   But I watched it, like, I don't know, some months ago, and I really like it. It's very long, but it's very   interesting. Like, all the the the the philosophical concepts involved are very interesting. It's for from the same guys of The Matrix, the Wachowski brothers. It's quite interesting. Another 1 is the isa Kasimov's,   robot short stories. Like, it's a Kasimov is the 1 from Irobot. It's the 1 that the the guy that coined the term robot the robotics.  

And the the the story is the it's just science fiction, pure   pure, simple science fiction, but it's, like, really interesting and really, really enjoyable.   And   on the on the tools   side, I will recommend   Python dev tools. There's this package by Samu called dev tools that has a debug function that you can use in your code, and then it will print   the any variable that you pass to it, pretty printed,   showing which line it was called in, showing what was the function that was calling it. Like, a lot of information that is super useful for the booking where you cannot just, like, plug at the booger. And it's,   I think it's quite new and not many people know about it, but it's a real lifesaver.  

And another 1 is h t t p x, which is the new async   compatible   request,   tool for Python.   So you can do, like, HTTP requests   in a sync contexts   and also in a standard, like, normal,   function,   non async   context.   I think yeah. I I think that's it also yeah. I I actually have a couple other apps that I wanted to share with you. Now that we are, like, all, in our houses,   RescueTime is a very good app for tracking your time on the time that you spent working and, like, do it automatically.   And the other 1 is Joplin for taking notes. I will share the links with you, when we finish. That's it's actually quite a bunch. I probably have,   probably should have  

[00:57:22] Unknown:

picked less, but, yeah, whatever. No. It's it's helpful to, have all those different suggestions. So I definitely appreciate that. And I appreciate you taking the time today to join me and share the work that you've done with FastAPI.   It's definitely an interesting framework and 1 that I've been hearing a lot about from a number of different people. So you've definitely been doing something right, and I appreciate all of your time and effort on that. And I hope you enjoy the rest of your day. Thank you very much. Thank you for having me here. It was a real pleasure. Have a have a great day over there too.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at dataengineeringpodcast.com   for the latest on modern data management.  

And visit the site of pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host at podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.