Learn Python with Talk Python's Python courses

#315: Awesome FastAPI extensions and add ons Transcript

Recorded on Thursday, Apr 22, 2021.

00:00 Have you heard that Fast API is awesome. We have Michael Herman back on the show to help us make it even more awesome with his Fast API awesome list. He's categorized many extensions and other libraries working with Fast API to help you be even more efficient with this framework. This is talk Python to me, Episode 315, recorded April 22 2015.

00:35 Welcome to talk Python to me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy, follow me on Twitter, where I'm '@mkennedy', and keep up with the show and listen to past episodes at talk python.fm. And follow the show on Twitter via @talkpython. Talk Python to me is partially supported by our training courses. At talk Python, we run a bunch of web apps and web API's. These power the training courses, as well as the mobile apps on iOS and Android. If I had to build these from scratch again, today, there's no doubt which framework I would use. It's Fast API. To me Fast API is the embodiment of Modern Python and Modern API's. You have beautiful usage of type annotations, you have model binding and validation with Pydantic and you have first class async and await support. If you're building or rebuilding a web app, you owe it to yourself to check out one of our newest courses, modern API's with fast API over at talk Python training. This is the first course in a series of fast API courses we're building and you can get it for just $39. It'll take you from interested to production with fast API to learn more and get started today. Just visit 'talkpython.fm/fast API', or email us at 'sales@talk python.fm'.

01:48 Michael, welcome back to talk Python to me. Thank you. Yeah, it's really great to have you back. You've been on before. And there's a bunch of stuff that we're going to talk about that you've been up to, and we've done. So you were back on episode 206, when you talked about running Django in production, and you've had a couple of large sites that you've been running, and most recent one is probably 'testdriven.io', where you do some articles, some tutorials and some courses, right. Yeah. So life was obviously much different back in when I was no on the podcast back end. What was that February of 2019. But so now I'm still working on "testdriven.io". So that's a I do training courses for mid to senior level developers that are looking to learn test driven development, microservices, and AWS infrastructure and whatnot. Nice. It's mostly Python and JavaScript stuff. Is that right? Yeah, yeah, yeah. Well, maybe some of the same time Yeah, a bit. I also get a lot into like container orchestration and whatnot. Luckily, Kubernetes, a little bit of AWS ECS, as well. Awesome. And so what do you do now? So yeah, I am running tests from that IO on the side, but my full time main gig is for monitor. And we as the banner there says, we're doing machine learning assurance, really doing probably, machine learning, governance is probably more like what we had to redo the website, that's probably what we would establish machine learning governments would be there rather than assurance. But basically, we're helping to ensure that your AI is doing what it should be doing in production so that your models are basically inferences or predictions that your models are serving up are like within a certain bounds, essentially, right? Like if the input data changes, and you don't change your models, maybe they're not meant to understand that type of data. And they're just, you know, the thing is, you're always going to get an answer, right? Yeah, it just might be the wrong or invalid data, like, but it looks like a valid answer, like how do you know, right? Yeah, it's kind of like an Excel, like, whenever you get, you know, whatever it is, besides that, Na, or whatever, you know, you don't know that's, like good or bad or not. And so, yeah, we're looking for like feature drift. We're looking for model drift, we're looking for bias, you know, that sort of things. We're also we take all inferences that go through a model we're logging, and then we're also versioning, the model as well. So you can recreate the model run counterfactual type tests and whatnot. Interesting. Okay. Is that mostly Python stuff over there? What's the tech? Yeah, so it's a Django model. That's like the backend API. Using flask is sort of a middle layer to transform data between the API and the front end, the front end is in 'Vue'. And it's primarily AWS. And so using terraform as infrastructures code to simplify the maintaining of the infrastructure. That's cool. I feel like terraform is definitely taken off. I hear a lot of people saying that they're using it these days. Yeah, I really, is that like Ansible or sell chef, or it's like a competitor to that, right. Yeah, I think those are a little bit different. I would say it's more of a competitor to to like cloud formation. Okay, templates and cloud for I think there's a new sort of infrastructures code from AWS called CDK. That's a little bit more declarative, sort of how terraform is and I haven't had a chance to look at that, but I think that's

05:00 We're like the new hotness these days. And then there's one more called like, Gloomy, I believe is the name, but I haven't used that one. Yeah, cool. People want to learn more about what's going on with monitor, they can check out Episode 261, which is a little newer until April 2020. With one of your co founders, Andrew Clark, as he's still working with you. Yeah, definitely. Yeah. Cool. So we dive into all that sort of stuff over there, which is cool. So really, the main thing that we're talking about is fast API, right? Like, that's what we're both here. We're both fans of fast API on multiple levels. And yeah, so we're gonna talk about the basically all the extensions in the ecosystem around fast API, but make the case for us for fast API itself. Like, I feel like there was a white 1000 flowers blooming type of thing going on once async and await came out and Python right, we had the Django the flask, old standbys. And then when things switched with type annotations, and with async, and await those frameworks could move super quick to adapt to those. So things like 'Fast API' and 'Sanic', and 'Japronto', and 'Starlet' and 'API star', all these things just sort of came into existence. And you know, Fast API is certainly among that crowd, right? Yeah, 'FastAPI' definitely leverages Starlet. And so yeah, you get the whole async syntax async await syntax. I would say that I like fast API for other things. Like I don't really take advantage of async and await and like the I have one production app. And that's running a fast API. And I can honestly care less about async await. But yeah, it's more about like the developer experience that I get. And also, I really, like pydantic. I would say that, yeah, if you're really into pydantic and that's like, what you use for serialization, deserialization, whatnot, then I would definitely check out as API. Absolutely. Just, you probably don't realize it because it's not very obvious. There's like you scoured the website, you might learn this. I just interviewed Samuel Coleman, who the creator and maintainer pydantic about pydantic and all the cool stuff it does. So Oh, cool. People who are listening to this prop may have just listened to that episode. And Fast API is a framework that absolutely takes Pydantic and puts it on the boundary. Right? Like it's when data is exchanged with fast API, the most default way to do that is to somehow involve Pydantic models, right? Yeah. And I mean, like, if you think back to like flask, flask is like just a wrapper on top of word swig and not pronouncing that right. But it works with click, and a couple others that are escaping me right now. The Fast API is really just a wrapper. It's dangerous. And like a couple other Yeah, yeah, it's just a wrapper on top of pydantic open API, JSON schema, that sort of things. Yeah, a few more like sort of modern tools like that. And so what makes fast API cool is that you can makes it easy to like hook into those two, so you can like leverage that and build plugins and whatnot. Yeah. So you can say things like, here's my API endpoint that I expect somebody to send a JSON document to. Oh, and the argument to the document is just a Pydantic model. Yeah, right. And then fast API will either successfully convert that model over or send something like a 400, or four to two back to say bad data, we can't convert it to what we're expecting. And on top of that, Fast API then automatically generates the open API stuff, which you hinted at, based on those models, right? Yeah. Yeah. So you get sort of that runtime type checking that you're talking about. And so you're really abstracting that out all to Pydantic. And so like, you don't have to maintain like a test suite around that either. And so it handles all of like the error handling around that it sends back a nice, human and computer readable response. Yeah, one of the things I like is if you've got like a nested object, maybe I've got a Pydantic model and has a list of little baby Pydantic models. And then there's an error, the error would say, the third thing in the list is where the problem is not just there are some invalid data. But on this field, you got a list, you've sent me a list of things. The third one, that's where that type conversion error is, it's like really good about giving you like, allowing you to drill out of where the data is wrong. Yeah. Okay, cool. So we've got the async and await stuff, which you said you don't use a lot. But if you need it, it's there. It's nice to have it right. It's really there. We're going to talk about some of the places that like plug into that in a moment. Pydantic i think is a big one. The Open API stuff is a big one. And to me, also, deployment is just simple, right? long as you've got 'Uvicorn' or 'gunicorn' plus uvicorn. You kind of go good to go right? There's not a lot of other stuff you got to do on the server, just 'gunicorn', fire this thing up and maybe point nginx put nginx in front of it. Yeah, yeah, definitely. I like how it doesn't have a development server, either. So you have to use it, too. Yeah, Uvi corn and development, I think that helps beginners that are new to sort of web development conceptually understand that, hey, this development server is there's a difference here between this development server in this production server, where as like with flask, and with Django, where they give you like a development WSGI server right out of the box. I think it's confusing because a lot of people are like, Well, why do I need that? Why do I

10:00 Can I use this instead of Gunicorn? Exactly. And they always come with this warning. This is not a production server, please don't use this. And you're like, Okay, well, yeah. What if I want to test it? Like for performance? Is it kind of like what I would expect? Is it really different? Like, there's all these things just like just make it run? What you're going to run in production anyway. Right? Yeah, yeah, definitely. Yeah. Pretty cool. Okay. Well, I think that's a pretty solid case. For fast API, I do think it's probably its biggest parallel competitor type thing is probably flask. You know, a lot of times people are using Django, they're trying to do a little bit more than maybe what they're doing flask. flask has many, many plugins as well. So I don't know, what do you think about this? Do you see these working together? would you use one instead of the other? It's interesting, because I think last week, you know, flask announced their 2.0. Yes, they did. But another 2.0 is going to have some async and await support. And that'll be interesting. Because like the entire class, part of the power behind flask is the ecosystem, like you have just Yeah, 1000s of plugins, some might argue that's like, there's too many plugins. But regardless, there's a lot of different plugins there. And so are they all going to start migrating over in supporting async? and await? What are they going to do? So I think that'll be interesting. But I would say there's obviously a lot of comparison type articles between flask and fast API. I don't know. Like, I try not to get into the either or type thinking and try and think of an in both like, they're both tools. I use all three. I like fast API for certain things. I use Django for other things. I use flask for other things. And so it's just all about like the tool having the right tool for the job. Yeah, yeah, I would say that fast API is more similar to flask than obviously is Django. And so it's probably going to be comparable to flask. But I still think that there's like certain reasons that I would probably use flask over fast API. Sure. That may well be because one of the plugins that you're talking about exactly nailed the use case. Yeah. And I'm also going to have David and Phil on to talk about the flask 2.0 release pretty soon. So Oh, cool. That's I think there's been this sort of like leapfrog thing is probably going to put flask back, if not ahead of fast API and some of the cool features, it'll bring a lot of those features over, I would expect, it's also worth pointing out that like, in flask, you can still do cool stuff with say Pydantic, right, you just need one extra line of code, the very first line of your API method could just be "model=pydantic.thing**request.getform", or whatever the call is to get the form data that's been posted over get the JSON data that's been posted over, and then just run with it the same. Yeah, yeah, there's a nice like flask Pydantic plugin as well. So yeah, you can definitely use Pydantic inside of flask. And then there's also like 'Flask-RestX', which will give you nice 'OpenAPI/swagger' type support as well. So if you want that out of the box, interesting, okay. And a lot of this is awareness, right? Like knowing Oh, there's this thing that I can go get right, knowing that I could get flask Pydantic, or the Open API, so on. And that brings us to our main topic here. How do you discover these things and know that they're out there? Right? It turns out, there's actually a bunch of extension type libraries for Fast API. I don't know, there's an official login model for fast API, but certainly things built to make Fast API better and add functionality to it right. And so I learned about a lot of them from your awesome fast API lists, but maybe just for a minute, for people who are not aware of this whole trend of awesome lists, maybe just talk about awesome lists for us a little bit like, What's the story? Where did these things come from? Yeah, I can't remember exactly. When they started popping up. I feel like maybe like five years ago, something like that. But I mean, awesome list is, I guess, just literally just a list of awesome things. In theory, it's contributed, maintained by the community. I mean, oftentimes, what really happens is like the main author becomes like sort of a dictator around that, which I think is totally fine. But I think there's just there's 1000s of different awesome lists out there. And so it's just, you're like a meta, meta Awesome, awesome list of awesome lists.

13:55 So it's, it gets a little crazy. He does get super, super meta, and it gets very specific as well. The one that probably people know best in the Python space is "awesome-python.com" which is really General, right? I mean, there's flask stuff and fast API stuff. There's zillions of other areas. And then there's all these offshoots, like yours around fast API and some for flask and so on. Cool. So when did you create your awesome fast API? It can't be more than two years ago, right? Because I'm saying on fast API's, it must be like a year old. I would say, I can't remember when we launched the core, the fast API course on test driven, but it's like, right around the same time. I think the list probably actually came out before that, because the first blog posts on fast API came out in January of 2020. So it was definitely after that. Yeah, really cool. Well, and I think, you know, it's fast API being around two years old. It takes a little while for these extra libraries to build up around it. Right. And I definitely think it's gaining momentum. It was for the first time it showed up on I think it was the PSF Jeff

15:00 survey for 2020. And went straight to number three is the most popular web framework. It was really yeah, quite interesting how popular Yeah, how quickly it became popular. To me, it's because it brings together these little pieces, each one that is kind of a neat new modern Python idea, like type hints, like Pydantic, like async, and await all those things and just bring it all together in one go. Yeah, this has all the things that I care about. This is cool. Alright, so your awesome list is broken down into a bunch of different categories, like third party extensions, and then resources, including, say, a podcast episode like this one, and so on hosting, and so on. So what I thought it'd be fun to do is let's just maybe go through some of those sections, and highlight a couple of the tools or extensions or whatever, that are really neat. Yeah, that sounds great. How about the fast API admin for the first one, one of the reasons why I did create this is like, mainly for these third party extensions for like listing these. So I think it's kind of 'Django packages.org' really aggregates them really well, for you know, obviously for Django, I don't think there is one anymore for flask, the main flask Doc's used to have a list, but it just got out of control. Yeah, but I think one of the powerful things is definitely the ecosystem and like these extensions, so I thought, like, someone's got to, like, start this so fantastic. Alright, so the first one, I think, is pretty interesting. Is this fast API admin. Tell us about this? Yeah. So if you I mean, if you're familiar with Django, like one of the powerful things that you get from Django, right out of the box is a nice cred admin, where you can interact with your models, your database models, in sort of like a cred GUI like fashion. And so you can add data all have sort of the crud functionality right out of the box, so you don't have to jump into SQL. So yeah, this just like mimics where that same sort of behavior. Very cool, very cool. GUI. That's one of the main features of Django that I would see people using it for it. Yeah. So the idea is basically, if I want to create users or mess with other tables, like, do they have products and categories, and it's just like a grid type thing to add new ones, edit existing ones, right? Yeah, yeah. It's very straightforward. But yeah, it's not like, there's not really too much to say about it's not some super sexy interface or anything like that. But it is like, it just saves a lot of time. Yeah, like one of the main features of the newer Django3.2 maybe was that there's now templating, for its admin stuff to make it look all super cool. Yeah. But to be honest, I think one of the really important things is to make it easy for people to get started. And you know, for me, if I had to build a little admin back end thing like that, it's like, Alright, well, there's half a day. Gotta do that to add it. But if you're starting new, and you're like, Okay, I got this page showing, but now I need to edit them. Oh, no, like, this is gonna be such a pain, right? Having something like this, you can just plug in, it'd be really helpful to say, Oh, actually, maybe I will choose fast API over Django rest framework, for example, potentially, because it might have an admin, right? Yeah. Like one of the negatives about this. And this is one of the negatives with Django is a lot of people use it for stuff that is not intended to be used for like they try and create like you make a consumer facing version of it. I think that's partly the impetus for like the templates is to be able to do more stuff like that, which I think that is not, then you have to make everyone sort of an admin. I think that's a bad practice. Yeah, it might lead to some problems. Yeah, yeah.

18:17 Yeah, Joe, out there on the live stream says, Does this include identity? Like, can I get a I'm guessing, a restricted admin back end? Yeah, I'm not sure. We are going to talk about other things that do include identity. And I suspect, I haven't logged in, but there's probably some point where you write some bit of API endpoint, maybe I know, there's got to be a way where you restrict access to it. Yeah, it does have admin secret here. And maybe that's it. I mean, if it works, I haven't used this particular one. I don't use orders and production. Last I looked at this, it didn't work with any other ORM s besides tortoise, but I know like that, if it's built similar to the or designed like the DjangoArm on Django on, doesn't have like a concept of permissions. So it's just it has like a super user. And if you're super user access, you get access to it. So there's not really any. I think there's probably maybe some extensions you can use to like limit access. But yeah, yeah, it looks like permission. True. Maybe there is like a concept of permissions here. So I'm thinking there's two places where you can put a little bit of protection here. One is this where you say the 'URL /admin'. Do URL could be /UUID out of some insane length. Right? So it's not very guessable. Yeah. And then this app secret, I suspect is like, What is the secret? You know, Knock knock, what's the magic word sort of thing? And there's just one login for it. But for the right type of app, that's probably good enough. Yeah, you would definitely want to change that URL in production. You don't want a Ford/admin. People are just always poking for stuff like that. Yeah, I don't know if you've ever Yeah, I'm sure you've done it. And there are no people out there in the audience have ever done this. But if you haven't, it's shocking. If you go and you just tell the log of your site like the main request log, you'll just see like request

20:00 For all sorts of like, weird, unrelated stuff, people just trying to guess to see if it exists. Like, there's all sorts of requests for like WP admin. Yeah, '.php' on my site and is written in Python. It has no admin thing like that whatsoever. But people are just going, is there this type of Can I get and try a default password against a PHP admin back end? Or try that for a Joomla back end and just start jamming on those things? Right. And so having that URL, something that's just not default, was not a big piece of security. It dissuades the bots, I think, yeah. Yeah. Keeps the honest people honest. Exactly. You want to hack, you got to do it for real. Okay. Speaking let's let's talk about authentication. There's a whole section on different types of things here, right. Yeah. So the one that I like best, or the one that I've used the most, I guess I'd say FastAPI users. Okay. I think that's the most popular one. Yeah, yeah, this is a So it uses all like it uses job based off but you can also sort of like you can store your job wherever you want. But this also has like a session capability built into it where you can store Django cookie, okay. There's a lot of times people are storing jots and local storage, which could lead to excess typing attacks are like open you up to like some Yeah, x assessor cross a scripting or get those mixed up. But yeah, yeah, I thought that was cool. You don't see that a lot. And like, sort of like libraries that are like job based. Yeah, that's cool. Yeah, it has either a cookie off or a dot off back end, which is cool. It also supports different ORMs. So if you'd like SQL Alchemy, you can do that, if you'd like MongoDB can do that. Ortis or ORMR, which I haven't actually heard of before, but we'll probably talk about it in a minute anyway. But yeah, quite neat. And also OAuth too. Yeah. So this is quite neat. If you want to plug it in, it looks like a bunch of people have contributed to it. So it looks pretty lively. Yeah, it's very popular. Yeah. I mean, one thing people might want to check out is the sneak package advisor. Have you seen this? Over here? And you can put all sorts of different packages in here. So if you like this one, or that one, you could actually pull it up? Have it tell you maybe not always that quickly? The health of the human, like, how popular is it? how healthy is its maintenance, and the security and sustainability and so on. So if you're like, Oh, I got these two or three extensions that might be doing the same thing. It might be worth throwing into this sneak package advisor and get a sense for like, this one seems a little stronger terms of liveliness, is the popularity score, is it based on similar packages? Or just like kind of global? Yeah, that's a good question. Because I can't imagine that there would be a more popular off library for fast API. I think it's global. I'm pretty sure it's like a logarithmic global type thing. Because, yeah, right. This is probably the most popular one. So what's going to beat it right? But it's only 798 stars, relative to like, flask users or something like that, right? Yeah. Yeah, I'd have to look and actually see, it does, like show you similar packages, if you can find sometimes it'll say, here's some other stuff that's like it. But anyway, I think that might be something to like, bring together with just awesome lists in general. Right? That's give me a chance to check these out and see how they're doing. You've also got flask. Fast API login based on flask login. They're both too similar in both words in the same place. Yeah. Yeah. Cloud auth, which is kind of cool. So like using authzero, or AWS cognito, or things like that. If you're doing that anyway, that might be nice. Yeah. Auth zero that just got bought by somebody. I feel like Google or something like that. Facebook. Yeah. I think they might have. Yeah, I feel like they bought something else. And then, you know, little fish, big fish whale,

23:40 I think often just bought Yes, that's right. It was Octa. Yes. Right. Yeah. Another one I wanted to throw out there while we're in this section. But I don't see here. And I don't see anything that does this. Possibly. Let's look at fast API security. Maybe this one does. It's not super documented over there. I feel like this throws some of the permissions in there that you would really want but a place called like 'OpenAPI' type stuff. More like the general Oh OS, OWASP stuff, if you check out secure and just how did they get this as the modern PyPI package name, just the word secure. But this one, it doesn't say that it plugs in with fast API, but it plugs in with flask and Django and Pyramid and CT and responder in starlet and starlett is the foundation. But I think that it would actually and what it does is it does things like it sets all the default header behaviors like that the phrase, you can't embed somebody else's your site into somebody else's site. And that cross site scripting protection is that and certain types of cache policies and whatnot. And just by doing like one line of code over on against it, or one or two lines, it'll automatically just like wrap every request with one of those. So that might also be interesting to think about in this regard. Yeah, those headers can get confusing.

25:00 If you especially if you're using like a single page application, you have to, if you're trying to use cookies or some sort of like, you know, session based off or whatever at the same time. Yeah, like it can get pretty complex on those headers. So yeah, that seems like a cool package. Yeah. And if something new comes out, that should be added that you don't pay attention to. But you happen to upgrade your package. Maybe it'll bring like the new best practice along Right. Yeah. Okay, so that's authentication databases. You have it broken down into ORMs. Query builders, ODM, which is for document databases, but it looks like a quick scan that document== MongoDB for the moment here. Yeah. And then there's other, which like JSON exchange and whatnot. Let's talk. Let's talk ORM first. Big like you pointed out big news for SQL alchemy, right? Yeah. SQL alchemy 1.4 newsletter last week or the week before the change actually broke fast API, or actually broke the flask course. because it requires the database URL to have PostgreSQL as the name rather than just Postgres. And so, you know, that broke the course. So little little annoying, but you know, yeah, and it blows my mind as to it broke one of my fastapi courses, because we were using async. We were using the new one, the async one, but then they said, well, you're using a driver that doesn't support async. So we're gonna throw an exception instead of just work more slowly. And so yeah, now again, you had to put like a separate different driver in there and so on. So yeah, yeah. So we find out sometimes the hard way about these releases, but yeah, so what's the big deal 'SQL Alchemy'? And then we got the SQLAlchemy in here. Yeah, let's see. So I mean, I haven't updated this like for specifically for like anything new with SQL alchemy. So yeah, there's that fast API SQL alchemy? That'd be interesting. And take a look at that one to see if I have there been any updates since SQL alchemy new one has been released? It looks like no. Looks like it hasn't been touched. Yeah. Yeah. So maybe if you're looking to contribute, maybe there's something to be done here. Because SQL Alchemy used to not support async. The big thing with a SQL Alchemy 1.4 there's stuff which changes the API to sort of move to something new. But the big one that's probably relevant here is SQL alchemy. Now as of 1.4, supports async and await like async, await, execute this query type of thing. Give me the objects back. And you might not care at all about that. But if you're using async, and await view, or API endpoints, invest API and but you want to use sequel alchemy, well, there goes your async. Right, it's gone because one of the most important things to await upon is the database. And so now the new SQL alchemy has that support, and I'm guessing this one, it probably doesn't support that, right, because it just it didn't exist. But yeah, so cool. Yeah, I'm not exactly sure. I'm sure it won't work, because the sample right here is exactly the same code I had that broke. So it's not gonna work. But it also is very possible to be quickly and easily updatable. I don't know, but people can check that out. I guess another one you've mentioned earlier, is tortoise orem. I haven't really done anything with tortoise was a story like databases are supposed to be fast. And here's the turtle going on.

27:58 Yeah, I mean, naming is tough. Right?

28:00 Exactly. I would say like tortoise is probably the most popular one or like just the one that I've like seen the most use out of in terms of seeing a lot of fast API projects. And so yeah, I think tortoise is one that's like leveraged a lot. Honestly, people use SQL alchemy, probably more than anything else. And they just like, don't deal with async type stuff. But if you want async and await, then yeah, I mean, tortoise definitely has quite a bit of support there. Yeah, you've got Pony ORM Ortis. ORM. Kiwi. I know peewee has an async version. I know the Django people are working on an async ORM story, but it's not there yet. SQL Alchemy just got it. One things I like about this is they put just what seems like a pretty fair graph comparing all the different ORM's in terms of performance. And tortoise orm comes up pretty nice on like, single inserts, and the whole updates. But there's also places where it's slower than other stuff. And they're just like, we're gonna put it all up there. And if you find it useful, here's what you get. And tortoise is similar to the Django ORM in the sense that it uses an active record type approach more similar to peewee whereas SQLalchemy uses the scammy data mapper approach, I believe, yeah, the unit of work style. Yeah, yeah. Yeah. And that's confusing for people because you've got to create the session, then you do all this stuff. And then you call commit, if you want to make changes, and it's not that hard to deal with. But it is one of those things just like why, where do I get a hold of the session? If I got a hold of objects, and I want to update it, like, I do find the Active Record stuff for simple cases. Pretty handy. Right. And it comes from Django as well. And that style. Yeah. So it'd be felt real familiar. Yeah. Yeah. Pretty cool. Joe, also out there says, What's the most popular database to use with fast API Postgres Express JS. Mongo, maybe is, like another example of a pairing? Yeah, I would say Postgres. Yeah, I think generally speaking, you're talking Python. It's Postgres. If you're relational MongoDB. If you're not, that seems to be like the story. The important thing here is that you may care about async and await. So then that limits the way in which you can talk to the things but both Postgres and

30:00 MongoDB have really good async story. So I think that still holds for fast API, the SQL lite have any sort of like, I don't know if you know this offhand, if SQL lite has any sort of async support, it doesn't I don't think the real way you access it has important behaviors that are any different. But there's a new driver that allows it to integrate with an async event loop async IO event loop. So it won't block the loop. But basically, it just means there's another thread waiting. And you won't get like true scalability, but at least like you're waiting on a query here and an external API there. They can both happen at the same time. But if you have a bunch of database calls, I think it just queues up. Yeah. Cool. All right. So tortoise ORM. useful, because down here somewhere, we probably have an await, I'm guessing. Oh, here's the you asked about the sequel, I here's the SQL library. aIIow. SQL lite is the one like there was recommending? Yeah. But down here, you can do you know, await, create object await filter object that first exactly what you want for simple access to those API's. Yeah, I mean, if you're just doing like a Quick Select or delete, or whatever it is, you're probably not going to get any sort of performance boost. But if you're doing for whatever reason, if you're doing a lot of different queries in a route handler that are not dependent on each other, or if you're like, doing more than one query that is very expensive. Yeah, that's also not dependent on each other, then you might get a performance boost like this, basically, the worse your databases, the better

31:26 the more of a benefit you're going to get. Because they think in a way, it's all about scaling, waiting in latency. So the more latency your database has, because you're doing slow queries, or it's like cloud and faraway or whatever, you're going to benefit from that. Yeah. But if it's a one millisecond response time, who knows? All right. You also mentioned GINO gino, this is like literally the first time I'm seeing it. What is this? Yeah, so Gino is from what I understand. It's more of like a full ecosystem. Okay, so Geno's, not ORM. is lightweight, Asynchronous ORM. So But yeah, I mean, it is an ORM. But it also like I believe there's a generator in here where you can build like a scaffold out an entire, like fast API app, sort of like based on your models. Yeah. Interesting. Similar to like how the rails like skeleton command works. And you're familiar with Yeah, that, like scaffold out like a quick crud app. Okay, cool. And it's one of these recursive acronyms. Yeah, it is. It talks about having an async API on top of SQL alchemy. I wonder how much importance that will have these days. But yeah, it sounds like it has other stuff. Like he talked about the whole community and stuff. So very cool. What else is in here that we should talk about? There's a couple other ORM's, people can look at query builders. I've used databases quite a bit. Okay. One difficult thing about databases is googling. like trying to Google any sort of like errors around databases. It's, you know, like it was what's gonna come up, but yeah, I mean, this is like one that's with this originally done by Kenneth rights and then hand it off, or is this different? You know, I'm not sure. I think it's by the same team that does a starlet. Yeah, yeah. Yeah. Tom Christie that's escapes me there. Yeah, yeah. Yeah, definitely. Cool. Now, he does a lot of stuff. Yeah, that guy's busy. I've had him on the show before. He's definitely a busy guy. That's awesome. Cool. So it's like a wrapper around SQL alchemy core that then will give you back proper queries and stuff like that. Yeah. Nice. Okay. odms. Just really quick mentions, as I was recently talking about beanie on Python bytes, beanie is kind of cool. It's an async way to talk to MongoDB and ODM object document mapper, because there's no relations, really. But what's interesting about that is is one has an async option. And two is all about Pydantic. So you're normally you'd have like Django models or SQL alchemy models, like the models are Pydantic models that go to and from the database, which has an interesting possibility for integration back into the like return types and stuff that you would have say for a fast API. Anyway, that's, if you're into it that's potentially worth checking out. It's based on motor, which is the MongoDB, official racing driver for Python. Yeah, the PR for that one came out, I think, last week, and I heard about it maybe the week before. So I don't know if that's like a new library beanie. But it's Yeah, it's quite new. Because I was talking to Roman is the guy who created this, and he wouldn't, he did some stuff on it. I talked about how I thought was really cool to ease and Pydantic models and types, but it needs indexes. And so he actually went and put a whole mechanism in for doing indexes. Gotta check them out. I guess that's just an example. But whole way in which you can put indexes in your models and stuff. Yeah. MongoDB indexes. Perfect. So pretty cool that it has that stuff built in. And yeah, it looks like it's coming on strong. So maybe that's a good one. Mongo engine is actually what I use over at talk Python, but I don't believe it's async. I have suspicions that will never be async. It's super, super involved, and it doesn't seem to be changing real quickly. So I'm guessing that that's kind of where it is. Have you checked out this PydanticSQL alchemy pydantic to SQL alchemy, I haven't no booze to convert SQL alchemy models to Pydantic models like I just talked about the benefits of having your database models beat Pydanic so they can be on the ground.

35:01 Right, yeah. And maybe this is just like a way to sort of map those over. That's kind of cool. Yeah, that is cool. I did when I looked at this earlier, one thing I wasn't psyched about, I'd be interested to hear your thoughts on this, Michael, the way that it does is that runtime, right? So the way you get your SQL alchemy model, you say, now I'm going to create a Pydantic user from my user, by passing it to a function that does probably magic metaprogramming, and boom, outcomes, this type identic user, right, and that's cool. But one thing I don't like about that style is the editors can't be very smart about helping you, right? Like, it doesn't know what the hecka identic user can do or can be or autocomplete, and all that sort of stuff. So I feel like a lot of these sort of runtime converter things. I don't know, they let the good editors like PyCharm in VS code down. What do you think? Yeah, I mean, is there a way to look at what it'll convert that down to? It'd be great if you could get it to like, spit out? Yeah, the actual model, a code file, you run this one time? And then you're like, we're good. Yeah, we're good. I just want to Yeah, way to go from 20 SQL alchemy models to 20 pydantic models, and I save that code and go with it or something like that would be cool. But I didn't know. So it must be cached. Sort of at some point. So yeah, yeah. That's interesting. Yeah, I do think it's really powerful, though. But it's just like, yeah, it's a little tricky to get help with what you're supposed to do, right? Because otherwise, you have two different like model concepts. Like you have your model like your database model, which is SQL alchemy. And then you have like, throw that your model, which is more of like a schema. Yeah. But pydantic calls the models. And so like, in my fast API code, I call them schemas. So I have like a schema.py file. Now the models.py file, which is the flask, sorry, I keep saying flask. But the

36:40 theory it's so hard, because they're they're the same size word. And they play a very similar role. Yeah, yeah. Yeah.

36:47 At least sponsoring this.

36:49 Yeah, just having them combined together, like would make sense. But yeah, I get what you're saying about like, you don't know exactly what that is like until like at runtime. Yeah. If I go to one of those and say, dot, it's like, it gives me nothing, right? Yeah. Yeah. Cool. Yeah. So Joe, out there in the livestream says, what would you recommend as a DB driver said, a psycopg 2 for Postgres and fast API, you got a recommendation? Well, like if you're using synchronous, you want to go 'psycoPG2', obviously. But if you're using async, then it's gonna use asyncpg. Yeah. So there's a separate async one. Cool. Alright, let's talk about that. I just bag on code generators. Let's talk about code generators.

37:40 Okay, because they are valuable. One of the things that's cool. Like here, I have a here's a little site I built for a course whether or not talk python.fm that lets you go and enter a city. And it'll tell you literally the real weather right now like for now, in Portland, it's broken clouds, within like a few moments, right? That's cool. And one of the things that's really nice though, with all these things are you can go to '/docs', and you get this cool documentation thing. And that's is where, like your Pydantic model kicks in for the JSON schema response and all those cool things. Right. So that's just fast API. That's amazing. But the next thing is the fast API code generator, right? So this takes an open API file, and then it will scaffold out your fast API app based on that. And so does it do all like the Pydantic models and whatnot? I'm not sure if it does, or is it just to the endpoints? It seems like it it says the response models pets, I think so from models import pets. Yeah, yeah. So you pointed at that documentation, that slash docs that I was just talking about? And you say, here's some API specifications, I want to fast API server implementation of that, boom, and you get it right. So you can sort of do like the document driven development. So then if you want to change your API, you change the open API Doc, exactly. Yeah, you can see right here it is actually generating the Pydantic models, and even the errors that it throws and so on, this is super cool. It even has support for, say, optional strings and default values versus non optional strings. Like it was cool. I'm not sure I would use it, because I don't find myself in a situation where I have that a lot. But if you wanted to do it, it seems like it would be really cool to have. Alright, related to that is the other side of the story. I want to talk to an existing fast API. Probably this would work for any open API thing, I would guess. But it's called it says it's for fast API. So generate a MyPy and Id friendly API client from open API spec. This looks cool. Let's see some examples down here. A both supports async and synchronous clients. And I'm guessing it's using the similar example model, because we have a pep here as well. So it generates the model, the Pydantic model that you're gonna exchange with the server and all sorts of stuff. This is cool. So what does this generate? Exactly? It's creating a client library to interact with the API. Yeah, like so instead of using requests to call the API and just putting bear dictionaries, yeah, it will actually generate the Pydantic models. And it'll give you the API endpoints as functions instead of just request this URL. Nice. Does that give you like swings, documentation and all that too? I have no idea.

39:54 That would be cool. Yeah, super cool. That shows you how to basically take all that stuff and generate those and it does say that it

40:00 generates ID friendly one, so it must export those and not do it at runtime, which you know those pet a you can see right here like from client models import peps who generates the Python files and then you consume them instead of at runtime so that you get like autocomplete and type checking and all that plus cool. Yeah, Teddy out here on the livestream says, What use case would you use fast API versus say Django rest framework? It's kind of hard to compare the two. I mean, if you're already using Django, then yeah, obviously go Django rest framework. But yeah, in terms of Django plus Django rest framework, versus Fast API. As always, it depends. It just depends on what you're doing. It depends on the size of API depends on if you need authentication depends. If you want, like, the cred admin, you know, type stuff happens on what tools you're going to be using to consume the API. You know, if you want something that's tried and true and battle tested, I would go with Django and Django rest framework. If you want to play around with the new hotness and take advantage of you take it away, and all the cool stuff that's coming out, then maybe check out fast API. Yeah, I would certainly say if you already have Django, and you're already using it, just want to plug into the same app and just keep rolling, probably just Django rest framework, right? unless you really want to commit to having multiple apps that you run separately, I don't know put behind nginx through URL routing or something like that. Also, you know, how much of the fast API features you're going to use? Right? If you don't care about async, and await and you don't care about the typing very much. And you'll care about the documentation like well, then it kind of comes down. But if like, all of those things are super important to you, maybe breaking that out matters. I don't know. That's kind of my thought as well. Yeah. Also, Robin Haase asks best jazz friend and framework for fast API. I mean, it's kind of open. Right. But yeah, there's anything that stands out is better. Now. I mean, it works well with Vue react Angular Vue j.s, because, yeah, because it's Vue. js.

41:51 Cool. All right. Another one here, I want to talk about that. super neat, is fast API profiler. This looks really cool. So it's middleware. I mean, in your the Django expert, certainly for the two of us here. Tell me how it works. I know in pyramid, there's a debug toolbar you can turn on. And then one of the parts of that is show me the profile. Like when I request this page, where was my time spent, show me my SQL alchemy queries actually interlaced in there, and so on, which is super cool. Django or something like that, right? Yeah. Django has Django debug toolbar. Yeah, you had said that it does. Basically, that works with your server side templating to like, figure out like, with that specific template, or with that specific route, how many different queries did it take to load this view, right? Find if you got the n plus one problem, because you pass this thing? And then you're all over? Yeah, touching the lazy loaded properties over and over and over something like that, right? It's not going to detect n plus one issues for you. But you should be able to see them. Yeah. If you're like, why do I have 100 queries on this page instead of two? Like, if that just jumped out at you? Right? Yeah. Yeah. So this is I'm guessing like that. Yeah, I wonder where the output prints out at. Because like with SAP, I usually don't have the server side template with it. So Exactly. By default, you don't just like just print out to the terminal, or it's worth pointing out that fast API does support Jinja. Yeah. But you got to do a little extra work to make it do it. So it says this is really like a leveraging py instrument, from Joe, Rick. And if you scroll down over on their repo on his repo, there's a bunch of cool output. I think it might even open up. I don't know, I'm not sure exactly where it goes, it might I think it saves it to like a profile file. So you get this like, cool little view of like the profile output here. Even there's like a terminal version, which is, I don't know, like a rich, colored terminal version. But there's a bunch of cool graphs and stuff you can get. There's a I think saw some here somewhere, you can open up some kind of like flame graph as well. That's cool. Yeah, you can dig into it. So basically, anything you can do with Py instrument, I think this is just a middleware wrapper that generates py instrument stuff for you. Which is, that's pretty cool. Yeah, a lot of stuff super powerful. Like, you could probably take some of that stuff and tie it into your integration type test to ensure that, hey, like, I built this route, this view takes X amount of time. And like, you know, now I want to throw a junior developer on my code, I want to make sure Hey, there's not like a performance loss. And you can like use, like some stuff like that to make sure that the number of queries don't all of a sudden, triple like the load time doesn't all of a sudden triple stuff like that. So tying like stuff into your test suite is like super powerful. I do that with there's a library called n plus one that does that very same thing. Oh, interesting. Yeah, very cool. Nice. Heard of you. I haven't used it. I another one. I think the stands out is pretty interesting is fast API mail. I mean, boring. But Sydney mail is one of those things that can take forever. Like, I had one of these admin parts of my site. I had a way to like send an email to all the people in this class, go 20 seconds. 30 seconds timed out. And it was going to like 1000s of people and the problem was, it had sent hundreds of emails and then it timed out. So how do I resend that without sending a duplicate to the first half right?

45:00 Maintaining the state there. Yeah, yeah. And like I don't really like it's really hard to go back to figure out everyone who got it but not Anyway, it was a huge pain. And I'm like, okay, sending a lot of emails kind of sucks. And so this one fast API mail is cool. Because email is one of those things. That's like, dreadfully slow. And this allows you to asynchronously send email messages in a super simple way. So you're not using like sendgrid or FCS or anything to at the time I was using STS at the time. Yeah, okay. Okay. But I was doing it one instead of like doing a box. And yeah, I said, This customize email to that person, this customized email that person. And like, I mean, it's fine. If I even just set the timeout, limit longer, or whatever, it would have been fine. what I ended up doing is putting that in a background queue, and just let it go. Like, that's how it should have been all it shouldn't have been as part of the request. But I learned the hard way. The first time around. I use celery for that same exact thing. I mean, that just goes right in the queue. Yeah, perfect. Yeah. So this one has an async. This makes immediate, like you said, doing bulk sending on some kind of background thing is exactly what you should do. But if you're trying to not block your processing, and you want to send an email, just one like, hey, reset my password, right? That could be a thing you could just do right away. And so here's a way to await sending emails, which is kind of cool. Yeah. If you don't really care too much about what happens to email, like, if you're not too concerned about, hey, if this doesn't get delivered, it's not a huge deal. I'd say like something like, this is fine. If it's more like, you know, there's like any sort of like workflow based on what could happen there like success, failure, that sort of thing. Like if then this that type stuff. Yeah, you want to probably look more like to charge salary, I would say, but I still think like, if you want to send like just a simple one off email, maybe it's even to yourself or something like that. I do this, like with fast API mails, I send myself notifications based on events. And like, I don't necessarily need them. Like, you know, I'm not curing cancer here. So if I don't get it, I don't care. Yeah, I've the same thing. I'll just shoot myself messages like, oh, here's the thing you should probably know about that happened. Very cool. Yeah. I have moved to sendgrid. Last month or two and really like it. That's so big. Yeah. Oh, come back to normal size. So let's see. What else have we got here? That's interesting. Then we got the obligatory utils. The catch? All right. Everything. Yeah. Well named 'helpers.Py' Exactly.

47:13 So we got socket IO stuff, plugins, pagination, one I do a to that I'll call quick attention to that, I think is our Nate in here. Not this is not an endorsement or saying I would use it, but I think I can see a real interesting use case. First, the cache one. Yeah. Maybe tell us about this cache one here. Yeah. So I haven't used this one. Exactly. But it looks like yeah, it just is probably going to probably cache at the route handler level. And it looks like it's caching the response based on the request parameters inside of Redis. Yeah. You know, what's the one thing that's interesting here that it actually does that? I haven't seen any of these examples yet? But it's certainly a fast API thing is it uses dependency injection for the cache. Yeah. Right. So they've got a vue method here, or API endpoint, I guess, called Hello. And then one of the parameters is cache of type Redis. cache back in equals the default values depends on Redis Cache, though it goes and finds the one instance of that and hands it off. And then it's just like, standard Redis key value type thing, like await gets a thing, that thing's not there a weight set the thing? No, pretty standard, but it's kind of cool. Just the simple integration. Yeah, like dependency injection, I think is a it's a pretty difficult concept. If you look at it from a theoretical standpoint, but it's just like, this object here. Is this taking this other object at runtime, you know, essentially, so it's, yeah, yeah, it's just a way to like sort of split apart sort of your dependencies, and it makes testing a whole lot easier. So you don't have to have like mocks all over the place. So you can just switch out like the Redis Cache for like in memory cache or something like that. Yeah. If you could pass in anything that has a get in a set. You're good, right? Yeah.

48:50 I think because of dependency injection, fast API, like you don't necessarily have to leverage it. But I think that if you are it does take a little like, you have to be a little bit more of a seasoned developer. I'd say that. Yeah. Some of that's just picking up flask. Yeah, I totally agree about that. And dependency injection is one of those things like, Oh, this is really cool. And it makes things simpler. And why is it so complicated? What just happened? You know, I don't think anymore. So I don't know, when you start looking at flask global objects, like Yeah, yes, yeah, that's complex. That's true. I'm thinking more of like the static languages like Java or C#, where you've got an art and art and interface one of these and then a bunch of those registered then like, which one did it actually like? What concrete type? Am I even working with? Like it can you know, people can over pattern it, I guess, alright, speaking of not over pattern, and let's check this out. So I was talking at the Python at the San Francisco Python meetup last night, and someone asked me, Hey, is there a way and fast API to just like, no, this was my office hours. Same Day, though. And also video meeting anyway. Somebody said, Can you take a database and make it like an API? Yes, this fast API-crud router. It sounds amazing, right? So basically, what you do is

50:00 You tell it your models and the schemas. And then it just creates all these API endpoints to do restful things to that table through the model. So I have a 'get/Potato', potato was the model, get/potato, that'll list them all, post a potato to slash potato, create one, delete potato, get rid of all of them, delete potatoes/ID, or delete that one, and so on. So it just turns this into basically, a series of fast API endpoints that are all the restful behaviors against your schemas. What do you think you'll see it delete all very often? No, little Bobby. Wonder if this is Gino might be leveraging something similar to this? Yeah, to me, this feels overexposed. But if it's like something simple, something internal, probably, maybe it makes sense to just go like, I just need to do that. But from JavaScript, we just turn that on. But like I said, I probably would not turn that on, because it scares me. Let's see rate limiting. There's a couple of rate limiting things that are cool here, slow API. And then what was the other fast API limiter, those are cool. And that's pretty much it for the standard. Doc's right, or standard extensions. And we've got the documentation, we've got some external resources, like some of the things that you have over at test driven podcasts you mentioned, or somehow someone linked the Python bytes thing I had with Sebastian, I believe, I'm starting to get to the point with this awesome list where it's like, I'm gonna probably have to like, curate the tutorials a little bit more, because there's so many, like new tutorials, like when I started this, there were like three or four tutorials. And now you know, there's like, hundreds of them just based on the popularity of the framework. So getting a little bit smarter with curating the tutorials like because you don't need 15 different tutorials, like showing how to build a crud app, you know, that sort of thing. I did find this fast API for flask users super helpful. Because what it does, it says you want to do this in flask. Here's the fast API version, you want to do this in flask. Here's the fast API version. And it just does like simple stuff. Like I want to write some examples. I want to create a method that does post here's what it looks like, there. Here's what it looks like and fast API and just side by side, sort of cookbook type of thing. I like that a lot. So yeah, that's a good one. All right. We're just a few moments left. I don't think we have time to go through all the tutorials. And honestly, I haven't researched them enough to talk about it. A couple of talks, which is cool. A couple of videos, which will I'm sure there's probably some more out there on the internet that could overwhelm your list at this point. Courses unite. We've got a lock on it. Yeah, I recognize a few of those names, right. Tell us about the courses. Exactly. Yeah, there's, there's three courses. And now let's talk about yours first. Yeah. So my course focuses on building just a RESTful API, but also focuses on heavily, obviously, on test driven development. But also focus on code formatting, you know, type tools like black and flake eight, and you know, stuff like that. And so I also go into CI/CD with GitHub actions, and then everything is dockerized. And then you also deploy it to Heroku. Yeah, super cool. And I saw that both you and I are also sponsors of the fast API project, and GitHub, which is pretty cool. Get your gold. I'm silver, I assume you donate a few more bucks a month, then? I guess. So I guess so. But yeah, how does that work? Here's the thing, I don't call out to like, say, oh, look how cool we are. I mean, I do see on the screen here, which sort of brought it to mind. But there's so many companies out there who are building major parts of their businesses on top of fast API and other projects. Like GitHub has such a simple way to go press this monster button, support those things and make sure they have a nice, vibrant ecosystem. People backing them, you know if we can do it, surely. Yeah. Bank of America Chase. Yeah, Microsoft, Google. Get in there. Anyway, that was more my pitch there. Yeah, I think more companies need to like sort of call that just the cost of doing business. It's like we're resting on the shoulders of all these giants. Like we have this other remote team over here that we know nothing about. And yet we're leveraging You know, this team. And not all projects are like curated or maintained by Google and Facebook, either. And so yeah, I think it's, I'm not trying to like push this in people's face, like, Hey, I'm better than you. I'm just trying to say, hey, if I can do this, then yeah, I think a lot of companies should be thinking more and more about doing stuff like this. I totally agree. I think they should definitely see, we critically depend upon these technologies. Let's make sure that we do a little bit to support them. Yeah. Because a little bit for a lot of these companies would dramatically change it right. If, if last god $2 million a year, that would fundamentally change that organization. And yet, given how many people use it, it would be nothing to the companies and like, it wouldn't even show up almost right. So I know there's a lot of complexity about how companies justify money and where it goes on the balance sheet and all that, but still, people encourage your company to do stuff like that. Alright, so this is a really cool course. I love the Docker angle of it as well. So nice. So test driven, how's that work? What's the story without test driven development? Like we're like the site? No, I mean, just like like, how's that plugin with like, fast API like are you doing like this dependency injection type stuff or

55:00 I show I show like I show both like sort of ways how to do tests like I show like how to mock everything. So if you want to like speed, like your tests up, but I don't actually go into like all the dependency injection type stuff with though ORM gets a little bit too complex, I would say, especially with how Tortoise is set up. But yeah, I showed basically two different types of tests, like you can test it sort of like integration style, where it's actually hitting the database, or like you're using monkey patch to sort of mock out sort of the actual the database layer. Yeah, that sounds typical and useful. It's also like what differs, like between our two courses is like mine, or text base, and yours are all video based. Yeah. All video based? Yes. Yeah. I mean, there's source code on GitHub that sex Not really, yours, or both, then Damn, oh, no, no, no, not really. It's all video based. So I didn't plan this ahead. I looked at like, wow, you have my two courses, which is super cool. So I have two courses on here. Modern API's with fast API, an idea is just like, let's build an API that uses by pydanttic that uses async, and await that has real live data, stuff like that, and sort of the fundamentals of the fast API world. And then the other one is for web apps with fast API. So if you had already a flask app or something like that, and you're like, I'd like to add some additional features to it, you could just plug in some API type thing to it, some RESTful API extension, and it goes, but if you're starting from scratch, you might create an API with fast API, then you're like, well, I also wanted some HTML stuff. Could I actually add like a server side HTML story around this, as well. So it shows you how to like create users submit forms, validate data, use templates, all that kind of stuff. So kind of like, you need a little bit more on the server side. Little more on the web side, not just pure API, then like that will tell you how to do that. So you're using server side templating for that, yeah, either. Jinja2 or Chameleon? Doc, I think you pick. Yeah, basically, we recreate 'Pypi.Org' on fast API. So you're not doing a single page app, and with Vue and react and Docker rising a bowl, you'll know exactly why not? I know, I know. I'm not doing it right. I'm totally doing it wrong. But I definitely would not be cool in the JavaScript world. You know, it's not that I'm super against that. But I think that there's still a lot of value to having some of the stuff on server side. And then I don't think everything has to be a spa right? single page app. Yeah, I was being sarcastic. He was that's definitely like, I know, your I know, your Yeah.

57:24 So we were talking right before this, we realize we have our three classes here of courses here that we wanted to do some kind of special for people. And a way to also to get back to fast API on tell people what we came up with, like this was not pre planned until we're like, oh, wait, why don't we you know, we're looking at these three things here, let's, let's do something. So we decided that we're going to sell these three classes as a bundle, not one off. But if you want to take all three of these classes, we'll give you 50% off the price and 50% of that 50% 50% of what you pay us, we'll go to the support fast API directly. So we're going to try to do a little fundraiser for fast API and do a little awareness for our courses. Yeah, the courses kind of build into each other too. But your core, your modern API is a facet, the I would recommend taking that first. And then sort of my course takes that to the next level. And then you want to learn how to like, hey, one of my routes to have like server side templating. So I can like serve up something to interact with API, then add the full web app? Of course on top of that. Yeah, I think so. Go, we don't have because it's your course and my courses, different platforms, all that we don't have an official way to make this happen. So they just send you an email. Yeah. and say, Hey, I like to do this bundle thing. And what's make it happen behind the scenes, right? Yeah, just shoot me a quick email, Michael @ testtrim.io and I'll, I'll do all the hard work and, you know, link all that together and send in put, they'll probably just use stripe for that. Just send it send a quick stripe invoice. And then we'll make work behind the scenes. And then Sebastian, the fast API creator, that 2% of that. So help support fast API. Yeah. Fantastic. Super cool. Yeah. Thanks for doing that together. Michael. That'd be fun. All right. There's a couple of questions in the live chat. Before we wrap this up, I guess. Let's go to this question from Joe real quick. Because I'm really happy with flask. Is there any reason for me to switch to fast API, we've covered some of the reasons I would point out before anyone out there listening to makes that decision, if Flask 2.0 is coming out in a week. Wait until that happens. And then look at what the modern flask looks like. A lot of major stuffs coming like async and await support and so on. And then compare those. Yeah, I would say that's a hard No, don't switch shred away, like, spin up an app like see if you like it, see if you enjoy it before like moving your application over to Fast API. Yeah. And then Teddy has another interesting question. Like, are we aware of any CMS like projects building on top of fast API similar to say wagtail with Django? I don't know of any. Yeah, I don't know, either. The closest that I would say is like that thing I described with full web apps with fast API, which you can get the code from the open public GitHub repo, you have to take the course to check it out. That does put like HTML views and stuff on top of it, but you're still there. It's more like what flask does from scratch. Not what Wow.

01:00:00 It all dies from like, here's your CMS. That's a very long way from what you're asking. But it's as close as I know. Yeah. wagtails like it between WordPress and sort of Django. So it adds a lot on top of Django. So yeah, if you're looking for that sort of functionality, fast API is not going to do that. I want to even look for an extension out there for that. It's not the right tool. Yeah, probably not doggedness. What's the best platform to deploy fast API? Yeah. So you can deploy it really sort of anywhere? It kind of gets into the hosting section there. So if you want to scroll down there, yeah, it's kind of we're like on the cusp of it. But we don't really have time to go too deep into it. Yeah. Yeah. I mean, if you've containerized, you can obviously deploy it wherever I deploy like to Heroku. It's very simple to deploy containerized apps, they're easy to digitalocean as an app platform, it's a platform as a service. It's similar to Heroku. Now, so yeah, I mean, really, wherever you like to do your deployments to fast API, totally find it, deploy it there, it goes pretty easily. Yeah, there's even some serverless stuff that you point out in your list, they write further down. Certainly on the infrastructures of service, nginx gunicorn, particularly running UVicorn workers. So you get the async support, which is like a special flag, you can pass to G unicorn. And then Let's Encrypt for SSL. And you called Yeah, and I run it awesome flask repo as well. And I literally copied and pasted this from flask. So it's like, I mean, all of this is just agnostic. Yeah. Yeah. Very cool. And Joe actually give a call out to that earlier saying, I just started your live and realize you're the same guy that does awesome flask lists. Awesome. Yeah, there we go. Fantastic. All right. Well, I think we're quite out of time here, Michael. But super fun, super fun stuff to talk about really helpful. I just love these awesome lists. Because not only do you learn about all these cool things like some of the plugins like fast API, SQL alchemy, but then also things that those are using. It's just such a cool exploration of all these different libraries and things that are out there, right, like beanie. For example, I didn't know about beanie, but now I discovered it even though I wasn't looking forward to that, in particular. Yeah, I know how many times I see on Reddit, like people asking, Well, hey, what should I use for off? What should I use for this? And it's like, well, I mean, yeah, I mean, here's a list. Here's a concise list of all the different things out there, it might not cover everything, because there's obviously other things out there. But it's definitely nice to like, come to something like this versus like, you know, searching PyPi with Fast Api.

01:02:21 Exactly, exactly. One of the big challenges we have in the Python space, which is kind of the opposite of some places like say, the Microsoft world where they're like, here's your ORM. Here's your web framework you go build with that have a good time is we have the exact opposite of there's 1000 flowers blooming at each level of the stack. And it's a Paradox of Choice. Did you notice as a newcomer, I don't think it feels like amazing. Look at all these choices. It feels like overwhelming I have What do I do? Yeah, right. I think awesome lists, like the one you created, are helpful to really narrow it down to a couple, go make a pick and just run with it. Blow the Ruby and Rails folks, when they come over to the Python space. They're like, well, there's more than one. There's more than one.

01:03:02 Well, which one do I use? Oh, hello, SDH. Ah, I guess? Yeah, exactly. What are you doing? Are you doing? Yeah, very cool. All right. Well, I guess we're down to the final question. Before I let you out of here. I'll see if this has changed since last time. So if you're going to write some code, what editor Do you use Python code, I suspect. So I approached this question a little different, because you asked me favorite editor. And I said idle, because I don't use idle, you know, obviously, but it has a special place in my heart because that's where I learned Python was idle. And Thani is like sort of like a between like VS code, or a PyCharm and Idle, sort of like interesting. You're going to learn like Idle like today, check out fani like, adds like some debugging, like type tools. And it's like, a lot prettier to look at past super interesting. It's like, sort of like a notebook, sort of like a proper, like, autocomplete editor. And it looks a little bit like I don't Yeah, How interesting. Yeah, boom. Okay. Yeah. I haven't thought about that one for a while. That's cool. And then don't Yeah, don't use this on a daily basis, though. So

01:04:04 I definitely use VS code on a daily basis. So I'm not coding in the idle. Like what is idle stands for integrated development and learning environment yet? Don't use that on a daily basis. Exactly. Are you scratch my architecture design diagrams? Hell, there you go. Yeah. And then notable py pi package. So I've been using for docstrings. I've been using flake eight doc strings just to pull up my doc strings. And that has helped me, you know, I use like the sort of the Google flavor of doc strings. And that has helped me adhere to that a little bit better. Yeah. I also want to give a shout out to hotwire Django, so hotwire comes from sort of the rails sort of world, but this is essentially HTML served over WebSockets. So instead of like, you know, doing, you know all this stuff with vue or react, what you do is you serve up basically templates and the templates are pre renderedio.com. That's where hardware comes from. But instead of serving up your JSON having two forms of state one on the client

01:05:00 One on the server you just like you simplify it all made. It does add complexity with WebSockets. You have to deal with that. But yeah, I like sort of that paradigm. And it feels like a little bit more like 2005 ish than 2020 ish. But yeah, I mean, it's definitely been working for the rails folks. And Basecamp. Yeah, that place is interesting. All the frameworks that they kick out. Yeah. Cool. All right, well, so if you want to, if you want to be like, hey, and DHH can go do that. That's really cool. I've heard good things about it. Awesome. Well, Michael, it's been really fun to talk about your awesome list. And I think all the stuff we touched on is going to be super helpful, final call to action, people where to get started with fast API and pick some libraries where they do. You know, obviously, I would definitely say start with the fast API documentation. It is great out of all of like the documentation out there in terms of flask and Django and whatnot, that one is by far the best, definitely start off there. After you've built like just a basic app, check out the awesome like fast API list to see how to extend it. And then, if you're looking to like, learn more on the testing and Docker type realm, check out my course and check out Michael's courses as well. Yeah, and you can do that bundle thing. I'll include the email so they can send it over and help them out. Very cool. Awesome. Yeah. Yeah. Awesome. Yeah. So thank you so much for being here. Really appreciate it. And it's been super fun to talk fast API and all the stuff around it. It's really growing, isn't it? Yeah. It's exciting. It's exciting to see just how much it's grown just in like, past like six months. Yeah, absolutely. Alright. See you later. Yeah. Well, what's yours? Thanks for having me. Appreciate it. Yep. There's, this has been another episode of talk Python. To me. Our guests in this episode was Michael Herman. And it's been brought to you by us over at talk Python training. to level up your Python. We have one of the largest catalogs of Python video courses over at talk Python. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription insight. Check it out for yourself at 'training.talk python.fm'. Be sure to subscribe to the show, open your favorite podcast app and search for Python. We should be right at the top. You can also find the iTunes feed at /iTunes, the Google Play feed at /play and the direct RSS feed at /RSS on talk python.fm. We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at 'talkpython.fm/YouTube'. This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code

Back to show page