#452: Top Quart (async Flask) Extensions Transcript
00:00 Have you heard of Quart? It's the fully async version of Flask created by Philip Jones,
00:05 who's working closely with the Flask team on these parallel projects. The TLDR version is
00:10 that if you want to take advantage of async and await and you're using Flask, you want to give
00:15 Quart a solid look. We've spoken to Philip previously about Quart. This time around,
00:20 he's here to share his top Quart extensions and libraries that you can adopt today.
00:25 This is Talk Python to Me, episode 452, recorded January 10th, 2024.
00:31 Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy.
00:50 Follow me on Mastodon, where I'm @mkennedy and follow the podcast using @talkpython.
00:55 both on fosstodon.org. Keep up with the show and listen to over seven years of past episodes
01:01 at talkpython.fm. We've started streaming most of our episodes live on YouTube. Subscribe to our
01:07 YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of
01:13 that episode. This episode is sponsored by Posit Connect from the makers of Shiny. Publish, share,
01:19 and deploy all of your data projects that you're creating using Python. Streamlit, Dash, Shiny,
01:25 OKFastAPI, Flask, Quattro, Reports, Dashboards, and APIs. Posit Connect supports all of them. Try
01:32 Posit Connect for free by going to talkpython.fm/Posit, P-O-S-I-T. And it's also brought to you
01:39 by us over at Talk Python Training. Did you know that we have over 250 hours of Python courses? Yeah,
01:47 that's right. Check them out at talkpython.fm/courses. Philip, welcome back to Talk Python.
01:52 Tommy. Great to have you here. Thank you. Thank you for the invite. We're going to talk about web
01:55 things. I love some web things. We're going to talk about async. I love async. And we're going to talk
02:01 about a lot of little cool things you can plug into your web apps that make them more awesome.
02:06 And we give a lot of people a lot of things to think about. So yeah, let's do it. So I guess
02:13 quickly before we get into talking about Quart, maybe a little catch up on where it's been since the
02:18 last time we spoke about that. Give folks a bit of background on yourself who don't know you.
02:23 Sure. Yeah. I guess probably in this context and maybe the people listening are probably known
02:29 for Quart and Hypercorn and helping maintain the pallets libraries like Flask and Virksuk.
02:35 But well, outside of that, I guess in my professional career, I work as a software engineer in London.
02:41 I work for a company called Curaleaf International. And quite interestingly, because it's not very well
02:47 known, we're one of the few companies that do medical cannabis in the UK. Not many people know
02:52 it's legal. Yeah. Put that aside. So I've worked there for about a year and a bit now. Before that,
02:58 worked at various other software firms. And then before that, I was actually a particle physicist
03:02 working on an experiment out in Canada in a deep mine, which was quite a good fund.
03:05 So you like your variety of your jobs, I can tell.
03:09 Yeah. Had a definite career shift.
03:10 Indeed. Just a funny sidebar, you know, cannabis was legalized here three or four years ago in Oregon.
03:17 There are more cannabis shops than there are Starbucks, than there are McDonald's. Like
03:23 I could walk to four from my house in five minutes. It's nuts. Anyway, it's very different than it was a
03:30 few years ago, for sure. It's all fine, but just different. All right. So court, like Flask,
03:35 kind of, but very interesting. It's got some other capabilities. Tell people about court. How's it
03:41 relate to Flask? There's a lot of crossover. You and David Lord are working pretty closely,
03:46 it seems like, on things these days.
03:48 I started court about, I guess, seven, maybe a bit more years ago now. And the original idea was
03:54 make Flask async. At the time, I couldn't figure out how to adapt Flask at all in that direction. So I
04:00 thought, okay, I'll start by just re-implementing the Flask API using async await. And that's what
04:05 court started out to be. Over the years, David and I have worked to try and merge the two together.
04:11 So the very latest change that's happened a few months ago is we actually based court on Flask
04:17 now. So there's a lot of shared code now. And for a long time, court was based on VirgSug. And if
04:23 you're familiar with the palettes and Flask ecosystem, Flask is built on VirgSug. And court was,
04:28 but now court is built on Flask, which is built on VirgSug. And they're very, very similar.
04:31 Yeah. Oh, that's fantastic. Because the more that you can share, like the more you all can just focus on features and making it better rather than duplicating that
04:40 effort.
04:40 The other aim is that the APIs are the same as they can be other than async await. So you
04:45 can take your Flask code base and move to court just by adding async await. That's the dream,
04:49 even closer than it's ever been to that now.
04:51 You're pretty close to be able to rename the word Flask, keeping the case sensitivity
04:56 intact from Flask to court. And it works, right?
04:59 Yeah. In simple projects, yeah. The more complicated ones, it comes down to the extensions,
05:03 which we're going to talk about.
05:05 Yeah. That's the whole topic of today, right?
05:08 Yes, exactly. But yeah, that's the aim. Our long-term aim is to actually merge the two
05:13 and be able to say async Flask. Well, it's kind of the case now where you can say async Flask is court
05:18 and we can't quite do what Django has done and put async Django as it is in Django. Ours,
05:24 you have to make a naming choice from the start. But yeah, I think it's getting as close as we can get.
05:29 Maybe we'll figure out how to merge them in the future.
05:31 Yeah. It'd be great if you could choose to use async def or just regular functions for your views
05:38 and not really think about it.
05:39 You can't do that.
05:40 Okay.
05:40 You've been able to do that for about two years, I think, trying to figure out when we merge that.
05:44 So you could use either. It's just not as performant. If your code base is going to be
05:48 mostly async, you probably want to switch to court fully because it'd be more performant
05:52 and more reliable and robust.
05:54 Sure. Why is that?
05:55 The Flask implementation will run your async code on a separate thread.
05:59 So you get all that overhead of switching between the threads, sending the information over and back,
06:04 et cetera.
06:04 Right. Does it run like an asyncio event loop on the other thread, but then
06:09 basically curry the results back and forth?
06:12 Yep.
06:13 And with court, it's running right on top of an ASCII server straight, right?
06:18 Yeah.
06:19 Yeah. That's super cool. And you might be responsible for one of the more prominent ones out there.
06:24 Tell people about, well, what is an ASCII server for people who don't know?
06:28 Why does it exist? And then, you know, the one that you got.
06:30 Yeah, sure. So historically there was the whiskey standard, which separated servers from
06:35 frameworks applications and kind of gave you a choice between how do you want to serve
06:40 and deal with concurrency and stuff? And then how do you want your API to build your apps,
06:44 the framework to be? I think it was a great choice because it made the ecosystem really,
06:48 really nice for developers. And ASCII is the same thing for async. And so court is a,
06:54 is an example of an ASCII framework and Hypercon is an ASCII server.
06:58 They originally together, much like Sanic started out as well, but then I split that out Hypercon
07:04 into its own thing. And then later on now, Hypercon is also a whiskey server. So yeah,
07:08 in some respects, Hypercon is just a general purpose server for Python.
07:12 And so Hypercon, it lives in the same general usage base as G Unicorn and MicroWSGI UWSGI,
07:22 right. So I could run it in production in a kind of like a overseer mode where you can fan out
07:27 process, worker processes and system daemon, system D, all that, that, that where it's at.
07:32 Yeah, it's exactly like that. Yeah. Yeah. And it also in the ASCII space, it's similar to UVcorn or
07:38 Daphne. That's it. Right.
07:39 I think there's another, but I've forgotten the name just now.
07:42 Yeah. I was just messing with some Docker stuff and I was running the web app, a FastAPI app,
07:48 NG Unicorn using UVicorn workers. So handling the ASGI stuff that way, is it better to use Hypercorn?
07:57 Is it rather than something along those lines, a little more direct maybe, or what do you think?
08:02 I think it's a bit of a choice. So how it differs from UV, well, UVcorn in general is quicker because
08:06 it's HTTP parser. HP1 parser is quicker. And there's a few other choices that tend to make it a bit
08:12 quicker. However, this last time I checked, UVcorn doesn't support as many extensions as Hypercorn and
08:19 it doesn't support HTTP2 or HTTP3. Now, most people don't actually serve that directly. They tend to have
08:23 a load balancer in front, but I tend to do that because it's quite exciting. So you're getting there
08:28 with Hypercorn. And then after that, it's a bit of a choice between, you know, what features do they
08:32 both have? What do you want to use? So they're fairly similar, I would say.
08:35 Sure. Okay. Somewhat. Up to you, what do you want to choose? But for people who have mental models,
08:40 maybe using UVicorn, they can check out Hypercorn, right?
08:43 Yeah. Yeah. So you wouldn't need G Unicorn because Hypercorn has the process model that G Unicorn adds to
08:48 UVicorn. And yeah, you can just switch over. It should be a one-liner because most of the time it's just
08:54 that one command line where you set this up, right? So yeah.
08:57 Yeah. Very exciting. I'm going to give it a solid look because I'm deep in that world right now,
09:02 playing with things, which is very exciting, but not the topic for today. So the topic for today is
09:07 people who are interested in doing Flask and Quart, especially Quart, what are ways you can do more,
09:15 right? So the frameworks are pretty simple, right? That's of all the different APIs out there,
09:20 the Flask API has definitely won. You know, even though there's many different web frameworks,
09:26 right? If you look at the way programming works, you look at FastAPI, you look at a Litestar,
09:33 many of these things, it's like you've got to create a thing called app and then you say app.get and so
09:38 on, right? So this style of programming is really popular. And I think it's because it's just
09:43 straightforward and simple. Opposite of Django, maybe. Not so many batteries included, but you can
09:48 add the batteries through extensions. Yeah.
09:50 Yeah, exactly. I think that's always been the trade-off between Django and Flask and perhaps
09:54 even Django and Quart if you were to go Quart is Django makes the choice of your batteries to a large
09:59 extent, whereas Quart and Flask means you have to choose basically. Yeah.
10:02 Yeah. Which is really nice if you got like, you know, like I would really rather use this graph
10:07 database for this thing. And I would really rather, you know, like you get a lot of choice, but you
10:11 have to, you're going to have to build a little bit more yourself and you've got to decide more
10:15 yourself. So, but with all these extensions, it starts to become easier to click the Lego blocks
10:20 back together. Yeah.
10:21 Yeah, exactly. Yeah.
10:22 All right. So if you go, people listening, go to court.palettesproject.com and go in there and find
10:30 the extensions. There's a great long list of extensions that we've got here that they can
10:35 choose to run, right? And how to do that and so on. But you picked out a couple that you really want
10:40 to highlight and we'll dive into them. And if there's extra time, maybe we can, you know, pick some
10:45 more out of the list and just see what we can make of them.
10:48 I think the best one to start with is the bit of discussion around an extension called
10:52 court flask patch, which is a bit of a odd name and maybe need to think of a better name
10:57 for it. But the idea behind this extension is it patches court at import time to look very
11:04 much like flask. So you can use some flask extensions directly. So this is again, the idea
11:10 to make it easier. If you are so willing to transfer from flask to court, this would allow you to
11:15 an easier step because you could add this one line and court flask patch and some of your flask
11:21 extensions would just work. Now you've changed the court.
11:24 That's awesome because there's a bunch out there. So what happens when I run this? Does it basically
11:30 say like, okay, there's a bunch of module namespaces called court this court that let's create proxies
11:36 called flask that just delegate into the court elements and expose that back. So code written
11:41 against flask dot whatever think it still exists. Yeah, exactly that. Yeah, it does slightly more because it
11:47 what it also needs to do is because a lot of the court APIs are async. It needs to wrap them in a wrapper
11:53 that allows it to be called synchronously, but it needs to do so in a nested sense. And I don't know whether
11:59 you've looked much into like nesting event loops in one another that you're getting back to the same event loop.
12:05 It's a bit of a, I think it's fair maybe to call it a bit of a hack, but it does work well enough to give you to allow you to buy that time to develop on. But that's what it has to do. Yeah.
12:17 Yeah. I really wish that Python had an ambient event loop. That was the default. This like,
12:23 get me an event loop. Oh, it doesn't exist in exception. Oh, create an event loop. Sorry, exception. It already
12:29 exists. Like, you know, there's like, it's just really tricky to figure out kind of deep down in
12:34 some library, like, well, am I in charge of this? Is it already going? And I got to be part of something
12:38 bigger. If you could just say, just async run this, you know, and just you do that. You need to make an
12:43 event loop, make it. If you don't need to make one, just put it in the one that's already there,
12:47 right? Like I really wish there was a little bit cleaner story there, but you know, we're not going to
12:52 solve that with court extensions. No, no. I mean, if they had have done that, it would have made making
12:56 Flask async a lot easier. You've probably come across the library. I think it's Greenback. Greenback. No, this is new.
13:03 So Greenback is a green like stack switcher based library that allows you to get back to the event loop when you're deep in some
13:14 sync code, which is quite nice in the sense that, you know, it allows you to do all the stuff that's
13:19 difficult, but it's not so nice in that it's kind of hidden in a way, monkey patching type stuff going on
13:25 in the background. Yeah. Yeah. Yeah. I think this is what SQLAlchemy uses to get their async await
13:31 supporting. So it's certainly, yeah, I guess popular. Yeah. Sure. Reenter asyncio or trio event loops from
13:38 synchronous code. Very nice. Cool. Okay. So Flask patch, that's pretty good if you just have some
13:45 Flask code and you're like, oh, why don't you switch to court? But hopefully nothing, nothing changes and
13:50 I'll just run this at the beginning and everything will work. How often does that, how often does it
13:54 work out to be easy like that? So it depends on what the extension does. So if the extension does its own
14:01 IO or calls certain Flask functions that we can't, this extension can't patch, then yeah, it just fails.
14:08 And yeah, so not all of them. If you go into tests, you can see an example of some of them that we test
14:14 against or I test against, sorry, just to make sure they work. Like login potentially? Yeah. So login is
14:19 probably the most popular, I think. So I don't think it works for SQLAlchemy, for example. There's a
14:25 technical example, anywhere that uses app context as a, in a contact manager in a synchronous location,
14:32 basically that's too hard to patch. So they tend to all fail, but yeah, a few do. And I hope it makes
14:37 it easier for people. I'm pretty sure it is used because I get bug reports. So some people find it
14:41 useful at least. Yeah, absolutely. It looks, looks excellent, right? So once you, once you do all the,
14:48 the magic, you can just work with the login manager and off it goes, right? Yeah, exactly that. Yeah.
14:52 Super cool. This portion of Talk Python to Me is brought to you by Posit, the makers of Shiny,
14:58 formerly RStudio, and especially Shiny for Python. Let me ask you a question. Are you building awesome
15:05 things? Of course you are. You're a developer or data scientist. That's what we do. And you should
15:10 check out Posit Connect. Posit Connect is a way for you to publish, share, and deploy all the data
15:16 products that you're building using Python. People ask me the same question all the time. Michael,
15:21 I have some cool data science project or notebook that I built. How do I share it with my users,
15:26 stakeholders, teammates? Do I need to learn FastAPI or Flask or maybe Vue or React.js? Hold on now.
15:34 Those are cool technologies, and I'm sure you'd benefit from them, but maybe stay focused on the
15:38 data project. Let Posit Connect handle that side of things. With Posit Connect, you can rapidly and
15:43 securely deploy the things you build in Python. Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask,
15:49 Quarto, ports, dashboards, and APIs. Posit Connect supports all of them. And Posit Connect comes with
15:56 all the bells and whistles to satisfy IT and other enterprise requirements. Make deployment the easiest
16:02 step in your workflow with Posit Connect. For a limited time, you can try Posit Connect for free
16:07 for three months by going to talkpython.fm/Posit. That's talkpython.fm/P-O-S-I-T. The link is in
16:15 your podcast player show notes. Thank you to the team at Posit for supporting Talk Python.
16:21 Cores. Everybody loves their cross-site origin scripting restrictions. I guess we do love it in
16:29 the sense that we're not getting our bank account stolen when we browse the web. But as a web developer,
16:35 you're like, oh, Cores again. I need to allow this thing to talk to that, but it can be a hassle.
16:41 And so I'm guessing Cores allows you to control those settings and expose them and so on?
16:47 Yeah, exactly. I think it's become more prevalent, right? Since the switch to kind of front-end
16:52 frameworks has been so popular, right? Because you end up serving them, well, typically you end up
16:56 serving them separately. But yeah, it's exactly as you described. You can put decorators on roots,
17:02 or you can put it on a blueprint or on the entire app, and you just say, this is a Cores policy for
17:06 everything. Yeah. Very similar to Flask Cores, but different API.
17:10 So you can put it on even like a blueprint and say, this whole section of code is where the APIs live.
17:15 Things can call that, but nothing else. That'd be really, that's really nice.
17:19 Yeah. Okay.
17:19 So it also has a slight web, because obviously Quart does WebSockets where it's Flask,
17:24 at least natively can't. But yeah, there's some WebSocket considerations for Quart as well,
17:29 which mostly come around to checking the origin header. But yeah, it does that as well.
17:32 Okay. So you have a route, and you just put the at route underscore Cores on it, or like you said,
17:38 a blueprint or on the whole app or however you want. But, and then what kind of arguments does it take?
17:43 What can I ask it, make it do?
17:45 Yeah. So I went for the kind of, I guess, functional kind of API for it. So you can put in like the
17:50 allow headers or what's the other one, the credentials, I forget what it's called now,
17:54 but they're all listed and all keyword arguments effectively to it. There was in the issues,
17:59 someone a couple of, maybe last year, put out a new, a suggestion for a new API for Cores libraries
18:05 that would be more intuitive, but wouldn't match the actual headers that came out. So at some point,
18:09 I hope to like look into that and offer that as well. But at the moment that you basically say
18:13 the header and then the values you want. So it's very, you have to really kind of know calls to use it.
18:17 Okay. It just basically juggles the headers and there's not a lot of abstractions in between.
18:22 No, no. So I think on the, in the readme, it shows you them all actually. So these are all the headers
18:27 you can control and it's basically the same name.
18:29 Sure. So access control, allow origin, access control, allow credentials, expose headers, max age,
18:36 all this, all these things that you might, you might want to use, right? Yeah. Very cool.
18:40 Yeah. Okay. Oh, you have types as well. So that's lovely. Are you a fan of types, type hints?
18:45 Since it came out, I've tried not to write untyped code. I think, especially in a team,
18:50 I think it makes a huge difference to the understanding of the code. So yeah, I'm a very big fan.
18:54 Yeah. I also think it makes your editors help you more. You know, if it knows what type that is
18:59 and you say dot, it'll, is this what you meant? Like, yes, actually, I didn't know that existed,
19:03 but that's what I want. Give that to me. Without types, you're kind of like, well, you know,
19:07 you could object or weird, useless stuff that you can't do anything with. All right. So cores,
19:12 if you need to do cores, there's, I guess, let me know how to do this, but I think pretty much
19:17 most of these that exist, there's probably a flask variant. So if you use flask and you're like,
19:22 oh, I need cores, but I don't use court, just flask-cores instead of court-cores.
19:27 Yeah. Yeah. I think it's quite well maintained, the flask one. So yeah, the flask cores,
19:31 it's slightly different API, but the concepts are all the same, obviously. So yeah, not very much.
19:35 Another one is auth means so many different things. Is it a session type based auth? Is it OAuth? Is it,
19:43 who knows what, YubiKeys? What are we talking here?
19:46 Yeah. Session management via a secure cookie. So it's a similar usage, if you're familiar with
19:52 flask login, but I didn't want to call it court login because it didn't really do anything with
19:56 the login. It didn't check the password or the username or an MFA or anything to do with login,
20:00 in my opinion. So I called it auth instead. But yeah, so with this extension, you tell it to log in the
20:06 user and give it some kind of identifier and it saves that information securely in a cookie for you.
20:12 And whenever the user comes back and presents the cookie, it then pulls it out and turns it into
20:17 what is called the current user. So I think it's called the current user in flask login as well. So
20:22 very similar to that. All right. So you get this auth user back. What is this auth user? It's not like
20:27 out of your database, right? It has properties. By default, it's just as a method to say whether the user is
20:33 authenticated and to return their ID. But if you customize it, if you extend it. So what I typically do in my
20:40 codebases, I extend it and I add methods to return a model from the database, for example.
20:46 Yeah, very cool. Nice. And, you know, there's a lot of fancy login off stuff, but nice session cookie.
20:53 You know, it just, this works these days. It still works really well.
20:57 It does. Yeah. Much simpler than JWTs and less likely to go wrong. I think.
21:02 It's not exactly related, but I've had a lot of websites now I've given up on passwords, but they
21:08 don't use something new or they just decided like every time you want to get to the site, you just,
21:13 we're going to email you a code and you enter it. When did that become the way we're going to log into
21:17 everything? It's driving me crazy. So some good old username password. We're going to store your ID in a
21:22 cookie. It warms, warms the heart.
21:24 I've been playing with the WebOrph and little USB keys and such recently. I quite like it. I think
21:32 it might be a bit complex still. It's a little tricky to get working, but yeah, I think that's
21:37 probably the future to be honest with you. The site just sees like, yeah, you got the right
21:40 hardware thing. Off we go. Peter knows you're there. Something like that, right? Yeah. Nice. Okay. So
21:45 people need to deal with users. This is not about storing them in the database, encrypting, hashing
21:52 their passwords or those types of algorithms. It's really just about the web browser exchange that
21:57 involves setting a cookie when you're logged in and getting it back and make sure it's not tampered with,
22:01 right? Yeah. Yeah. So what it does is it stores the value, like the here, the number two is the ID
22:08 for the user. So it stores that in the cookie in plain text, but then cryptographically signs it. So you
22:14 don't want to store anything sensitive in the cookie if you're worried about it being read,
22:18 but you can store identifiers, et cetera, and know that it hasn't been tampered with.
22:22 Yeah. That's the thing. It's not going to harm you to know that your user ID is two or 75117 or
22:29 whatever. But if it's two was to stop somebody from going, let me change that to a three and see what
22:35 happens. Oh, look, I'm an admin. How cool is that? Right. That's the problem that you're trying to
22:41 solve with secure, right? Exactly. Yeah.
22:43 Well, from my side, I baked that thing in myself, but having an extension that just does it,
22:47 that sounds better. Yeah. So the nice thing, well, the bit I took a bit of interest, I think it's
22:52 changed now with Flask Login, but a couple of the areas where I wanted to improve is it does same site
22:57 settings on the cookie by default. So it will start with the strict and then you can play around and
23:02 go down to lax if you so need. But it also has the special, it allows the special host, you know,
23:09 the double underscore host prefixes on the name and stuff like that. So although I don't think in
23:14 reality that adds that much to your security, but it's a kind of a safety net in some respects.
23:19 Yeah. Sometimes also it becomes a hassle when you're doing development because your host is local host
23:24 and you're saying it has to be on mysite.com. You're like, well, I can't log in anymore. So then you've
23:29 got to have local hosts. And then I don't know, it doesn't feel super hamper resistant to me either.
23:34 Are you familiar with SecurePy? This is an interesting project too.
23:39 Oh, it's been archived.
23:40 Oh, it's archived. Oh, sadly. Is there a new one? No, but I think it still works. I'm not sure what
23:46 been deprecated. Okay. Well, I guess that's not being used as well, that are used that much,
23:51 but it used to be a way to kind of set all those different things, I believe. Or is this different?
23:55 This is a totally different.
23:56 Yeah. I think this is, I thought you were going to say secure headers, I think. Is it called that?
24:00 Oh, I think it's just called secure what it is. Yeah. That's the one. So sorry. That was some
24:05 other random thing that we've done that was called SecurePy, but not, this thing is still alive and
24:10 supports court, which is why I brought it up amongst like lots of other frameworks. But yeah,
24:16 you were going to tell people about this. This is cool.
24:17 Yeah. Yeah. So I pretty much end up adding all of these by hand. So yeah, most of the headers you want
24:24 to add. And if you ever do a pen test, right, they're going to, if you don't have these headers by
24:28 default, there you go, that's going to be a finding straight away. So yeah, it just adds
24:31 all the ones you want really.
24:33 Right. For one of the ones that you might not think of that you should probably have,
24:37 unless you have, unless you have a really specific use case is what if somebody created a site,
24:42 you know, you had service.com and they had service.io or, you know, whatever. And they,
24:48 they bought that and then they could put your, whatever their URL is, your, just into your site
24:54 as a hundred percent width and height iframe. Right. And then they just capture all the keystrokes
24:59 like, huh, you're typing into your thing. It looks like your thing. Your data is there.
25:04 You don't want people to do that to your site or just randomly host your site and their site. So
25:08 for example, this secure thing will set X frame options to same origin. So you can't embed your site
25:14 can no longer be embedded by default. You've got to choose to let it be embedded. All those kinds of
25:18 things, right. Are really nice here. Actually got caught out by that many, many years ago. I built
25:24 a, an image photo editor in the browser. It started to get quite a lot of juice. I was like,
25:29 oh, this is great. And then I realized it was on somebody else's domain, basically in an iframe.
25:33 They're like, look at our amazing editor that we're getting Google AdWord money for or whatever.
25:38 Right. Yeah, exactly. Yeah. So a little bit of a header action will shut that stuff down,
25:44 but I mean, I didn't know to do it until I kind of dug into it more. Right. Or you find out your
25:48 site somewhere else. Yeah. I think it's like a lot of it seems to be, yeah, learned with experience,
25:54 I guess, isn't it? Or on the job. It only happens once when you see your web app in somebody else's
25:58 site embedded as an iframe, right? No, this is not going to be okay. Awesome. All right. So that was
26:04 court auth as well as the secure thing. Next, I guess, kind of related to security, maybe not exclusively,
26:12 but somewhat rate limiting. Yeah. Cause I mean, on a login route, you'd want to put a rate limiter on straight away to stop any kind of brute forcing anyway. Right.
26:19 So. Oh, absolutely. And the ability to do really nice rate limiting in ways that punish the rate
26:27 limit breaker is so much easier on async things like court, right? Because if you don't want to be
26:33 overwhelmed by them, a lot of times you just say you send them some kind of response code. I don't
26:38 know what the status code is like too many requests or something like some 400.
26:41 429.
26:42 429.
26:42 Yeah, there you go. So you can just send them back straight away, but there's no
26:45 cost for them to receive that 429. You know, they're just like super quick going. If you wanted to say
26:52 like, because maybe they're trying to guess passwords or something, you're like, let's not let them guess
26:56 so quickly. So you can like sleep and then respond to them in 10 seconds later. So it's like,
27:02 oh, well, I don't know. Is the password good or not? Why don't you wait around for a while
27:06 instead of going somewhere else? With a asyncio based website, that's await asyncio.sleep,
27:11 nearly zero cost to you, other maybe an open socket. And you can just like send them to sort of time
27:17 black holes, super easy. Whereas like a WSGI app, you're blocking a request and you can only handle
27:22 so many and all that kind of stuff. Right?
27:24 Yeah. So this one sadly doesn't do any of that fun.
27:27 It doesn't have punishment built into it. No, but tell us how it works, what it does.
27:33 I was going to say, I think there was an article today suggesting you should serve zip bonds or
27:36 something to like unpleasant requesters, but yeah, it doesn't do any of that.
27:40 Send them like a hundred gigs back.
27:42 Yeah. That would be good. That would be good actually.
27:45 Yeah. So this one implements rate limiting as it's defined, like a user would be allowed to do so
27:51 many requests in a certain time and also implements the RFC for the like headers that you're supposed to
27:58 send back when they over, when they go over the rate limits. So they know when they can, or when the client
28:03 can then request again. I see like you've made too many, rather than just saying too many requests,
28:08 try again later. You're like, and you'll be reset in five minutes or like there's a proper way to communicate that.
28:13 The thing I find really interesting about this, which I don't know if everyone does, but I'll say anyway, but
28:18 most people implement rate limiting like a leaky bucket or something like that. These are the standard algorithms.
28:24 And typically that requires you to store two variables per key per rate limit you're looking at.
28:30 But there's a, I think it's not a very well known algorithm called the generic cell rate algorithm. I
28:35 think that's right. And this allows you to store one algorithm at one variable per rate limit. And it's
28:42 really quite nice. The algorithm is very, when you, when you get it, it's really intuitive and clean. You
28:47 basically, what you store is when you expect the next request to arrive. And if the request arrives too early,
28:53 then you just rate limit it. And yeah, it's really clever, I think. So I'd like more people to know
28:57 about it basically, because it's a really nice solution.
29:00 It's a great solution. Yeah. So this, it doesn't slow them down. It just tells them that they've
29:05 gone over the limit in this particular one, right? It's not like if you expect it to be in five seconds,
29:10 you don't just sleep for four and then let it in.
29:13 No, no. So the idea is that this decorator is much less costly in terms of your compute than
29:19 your function, your handler. So this decorator will just send back a 429 very quickly and never
29:24 touch your root instead. Okay. Interesting. I'm starting to think about maybe if you have
29:29 a sink and a wait available and you, your algorithm told you when the next one was coming, you could just
29:34 sleep them until the next one's allowed potentially, if it wasn't 10 minutes, right?
29:39 That would be the client. I mean, it depends on your rate limits, but there's a good chance
29:42 the client would time out, right? So, right. It'd have to be like five seconds or, or something
29:47 real short, right? Like I don't want more than one request a second type of rate limit, not like
29:51 five per hour that then they would definitely time out. But yeah, there's a lot of, a lot of things you
29:55 can do with this. So basically the way it works for people listening is you can set it up on the app.
30:02 So the entire app itself, all the requests to it are limited, right? Or you can go and put kind of like
30:08 tenacity, you can put the decorator exactly on a particular endpoint and then set the details for
30:14 that one, right? Yep. So a bit like cause, you can do it per app, per blueprint or per route,
30:18 depending on what you need. Okay. And here you say rate limit one, and then a time delta. What's the one?
30:23 It's the count. So you might want, so for a rate of one per second, you might want to express that as
30:29 10 per 10 seconds. So it would be instead of the one, the 10, and that allows you a bit of bursting,
30:34 if you will. So, you know, that 10 can come in one second or it can be spread over. So yeah,
30:39 it allows you to express the rate limits in different ways, really.
30:42 Yeah. I think this probably bypasses the static files. Is that true?
30:47 If you do the default limits, I think that applies to static files as well. I can't remember now,
30:52 but I think that's what it does.
30:53 Yeah. Because you might have, you know, six CSS files, 20 images and so on, right? And like
30:58 one page request might blast those all back super quick.
31:01 Yeah. Yeah. You certainly want a higher limit.
31:03 Yeah. But presumably you're using something like Nginx or whatever, or maybe even a CDN. And then
31:09 all those other things I described don't actually go through the Python app, ideally.
31:14 Yeah. Yeah. I mean, it does work if you do it for the Python app as well. So up to you, I think.
31:18 Yeah.
31:18 Indeed. All right. WT forms. Next up, court WTF. What is this?
31:24 So this was, I'm tempted to say it's been a bit less popular recently with the front end frameworks
31:30 and stuff. But when you did template rendering, you'd render the form, then you do the validation
31:36 in your Python framework for that form and you pass back the errors. And basically it would,
31:40 the WTF framework would do a lot of that for you. So you could just put in like in your template,
31:47 an input box and it would do the errors and do the, like you can see here, you could do the CSRF tokens
31:53 and render all the HTML for the labels and the actual input boxes and get it all hooked up very
31:59 easily. And that's what it does. Yeah. It's a, it does all that. And the validation when it comes
32:03 to the backend as well, I think you can just do form dot validate on submit or something like that.
32:07 Yeah, there we are. And that's it. That's your whole validation. So it saves a lot of effort, really.
32:12 Yeah, that's pretty handy. And I'm guessing you're getting generally generic HTML out on the client
32:18 side so you can CSS style it up all you like.
32:21 Yeah, I think it's, I can't remember exactly. I think WTF might have hooks so you can put styling directly in, but yeah,
32:28 it's, it's pretty, yeah, pretty generic as I remember it.
32:31 Yeah. Some frameworks require explicit stuff on say the input box, like form dash control would
32:37 be bootstrap and things like that. Right. There's probably some way to set a class.
32:41 Yeah. I think there's a class name argument. I'm trying to, I may have, may have misremembered that. I think it was called class name.
32:47 Yeah, sure. Nice. Yeah. I haven't used this really, but I've used it kind of like it in
32:52 framework, other frameworks. In the end, I ended up just going back to writing my own
32:56 HTML because I felt like I was getting 60% help, but maybe 30% struggle to fight the system. You
33:04 know what I mean? And then like, all right, you know what? I just know this stuff well enough.
33:07 I'm just going to do it myself. And, and, but if you don't want to mess with it, you want to some
33:11 sort of quick development type of thing, or maybe you're not super familiar with HTML. This will
33:15 definitely help. Right. Absolutely. Yeah. I think you can also write your own HTML instead and just let
33:19 it do the Python validation part. All right. Long as it lines up. Yeah, sure.
33:23 Yeah. Yeah. I think it's just the name that matters. Like your input has to have the right name.
33:27 Yeah. Because otherwise how would it know, right? It couldn't, it couldn't know.
33:30 Yeah, exactly. The CSRF is quite easy and nice. That just puts a hidden input in with the token in,
33:35 and it's all taken care of for you. So that can be quite nice.
33:38 Yeah. Excellent. All right. Schema.
33:40 So schema.
33:41 For APIs, right?
33:43 Yeah. So it's possibly the kind of more, I'll say modern, but I'm not sure if that's the word I mean,
33:48 but yeah. So we, as an industry, we seem to have moved away from the forms of old and form data to
33:53 send in JSON all the time. Right. And a court schema is about saying, I expect this structure to arrive, validate it for me. So it's a very similar,
34:03 it's very similar to FastAPI, which I'm sure a lot of people know.
34:06 Okay. That's pretty interesting. So like you say, very much like FastAPI, it kind of brings in
34:12 some frameworks called model binding, where you can say there's an argument and it's of this type,
34:17 and then, you know, like a class, pedantic class or something along those lines. And it'll,
34:21 here's a data class and it'll take all the inputs, right? Query strings or route primers,
34:27 whatever, and parse them and map them in there. And then just give you an object and go here,
34:31 it's ready. Yeah. So for this library, it supports, I've used all the data documentation as data class,
34:36 but it's pedantic based at the moment. And because of the, it's not actually the typing. So there's no
34:41 dependency injection or anything like that with FastAPI, but it uses the decorator validate request,
34:46 and you pass it the model. And if the request that arrives can be turned into that structure and
34:52 validated as such, then your function will be called and that'd be passed in as data. If it can't,
34:57 then the client will get a 400 response.
34:59 Bad request, bad data.
35:00 Exactly. Yeah.
35:01 Okay. What's the, so validate request makes sense to me. It means like, here's your structured object
35:07 that comes in, passed in as data. What's validate response?
35:11 So it's the same concept, but going back. So if you return like a to-do class instance itself,
35:18 then there's no validation to do, right? You've already said it's the right structure,
35:21 but often you'd return a dictionary or something like that, right? And expect it to go back as
35:26 JSON. What this will do is it will say, I'll check that dictionary is of the right structure. And if it
35:32 isn't, it throws a 500 response to the client and an error that you can go and view in whatever
35:37 error monitoring tool you've got. Sure. Okay. That's excellent. So I see you have data classes
35:42 here and you said it also works with Pydantic. Yeah. So, well, actually a shout out to one of
35:46 your previous recent streams is I'm working on msgspec support at the moment, because I
35:51 actually quite like that. So msgspec is interesting. So it will support Pydantic and message
35:56 spec. So you'll be able to use Pydantic data classes, atas, msgspec stuff, or the message
36:01 spec struct. I think that's probably all of it, but yeah, quite a bit of choice.
36:04 The struct classes really, they've done some super interesting things here to make these
36:10 data classes almost better for performance than even regular and for memory and stuff
36:14 than regular Python classes. It's quite impressive. Yes, absolutely. Yeah.
36:18 Yeah. Just for people who don't know, maybe just tell them real quick what msgspec is.
36:23 They probably know data classes and Pydantic. Yeah. So much like data classes, and you can see here,
36:27 it's a nice, simple way of creating a class with various things created for you. But it also,
36:33 much like Pydantic, will do validation when you try and, if you use one of its functions to convert
36:39 raw data like a dictionary into this type. And much like Pydantic as well, it also gives the ability
36:45 to take this model and turn it into a open API JSON schema definition. And that's the final thing
36:51 Quartz schema does is once you've decorated all your routes, it will auto-generate a open API definition
36:58 for you as well. Oh, it will. Okay. Yeah. Using Swaggers/docs. I think that's really nice. A lot of APIs
37:05 just don't. They're like, we're not going to do that. Yeah. If they don't have something automated to do it.
37:09 And having typed classes representing all your inbound and outbound data, pretty easy, right?
37:15 Yeah. I mean, it really helps with myPy, right? Because instead of having like your request.data or
37:19 something like that, which is some dict that as far as myPy concerns can be anything, it must be a to-do
37:25 instance in this function now. So yeah, really helps with your type checking.
37:29 Yeah, absolutely. All right. What do we got next? Sock from Miguel Grimberg. Flask WebSockets.
37:36 This one, there is an extension for because this is one of the areas that Quart being natively
37:40 async can just do itself. So the Quart, I think I described sometimes as a superset of Flask.
37:45 Because it can do everything Flask can do.
37:47 The C++ of Flask.
37:49 Yeah, exactly.
37:51 Awesome. So WebSockets, a problem that websites generally have not been able to do. Like once
37:58 you make a request, usually there's the response and that's it. But what if the server, you want to
38:02 send more stuff to the server, everyone wants to send stuff out to you later. Like I started this job,
38:07 three seconds later, now it's done. Or this bidirectional exchange is really cool. But a lot
38:12 of times I feel like it's a little over the top. Like a lot of times I think people maybe just want push
38:18 notifications from the server and not true. Like let's have a conversation. I just need to know
38:23 when this happens. Just let me know as soon as it's done. Right. So for that, yeah, go ahead.
38:27 Server sent events, sorry, seem to be not that well known, but yeah, probably described your usage
38:32 really well. That's exactly what I was getting at. So does Quart support SSE? Does it support server sent
38:37 events? Yeah, yeah. I think there's an extension for it, but in reality, it's a very small bit of code
38:44 you need. So it's yeah. I mean, cause you, you literally return a response with a certain header
38:51 and then you just return a, well, here we go. Here's the, there's an example in the documentation
38:56 for Quart, but you just return a certain data structure and then you, you've got it. Yeah.
39:00 Yeah. So I think that's when people say they want web sockets, I think most of the time,
39:04 this is what they want. They want the client, the server to call the client sometimes, not just the
39:09 other way around. Yeah. So I'm going to go slightly off topic because it's interesting,
39:13 but it's related to this, but one of the things I implemented in Hypercorn, because I find it
39:17 really interesting is that I think two, no, it must be more like four years ago, they introduced web
39:23 sockets for HTTP two. And of course, one of the reasons you want web sockets because the cost of
39:28 opening the connection for HTTP one is, is fairly expensive. So you can keep it open and do the bi-directional.
39:32 But with HTTP two, you don't even need an extra connection anymore. You can have your web socket stream on the
39:38 same connection as all your requests as well. So it's really nice and efficient. So yeah,
39:42 I'd love to have an opportunity to make more use of it. So I find it really interesting, but
39:46 the code I write professionally at the moment doesn't quite need that level of real time interaction.
39:50 I know, I know all the stuff I built, I'm like, that would be so fun, but you know,
39:53 I just don't need that. Yeah, exactly.
39:55 I have no use case. I mean, there are apps I'm sure that do it, right? Like really complicated
40:02 single page apps like StreamYard that we're using right now. For example, this has probably got some
40:07 crazy interchange going on, but I don't write this kind of apps either. All right, let's see. So
40:13 the socket stuff, which is cool. That's like you said, built into court. That's one of the advantages
40:18 of it. But you know, you can use Miguel Grimberg's stuff to add it to Flask. SQLAlchemy, you mentioned
40:24 them before, probably outside. If you're not in the Django space, it's not the only option for sure,
40:30 but it's probably the de facto choice people when they think, I want to know our ORM for a relational
40:35 database. You probably start here, right? Yeah, I think you would. Yeah. And this is a port,
40:41 as I understand it, of the Flask, SQLAlchemy extension to work with or natively work with court. So
40:47 should match all your expectations, I think. And if you're used to it, you just use this and it works
40:54 with court and there you go. Let's see an example here. You can set up your database with a pretty
41:00 interesting nested type of construct here, like just, you know, passing rich arguments that take
41:06 more. And if you look at the code on there, just the shape of the code is kind of unique here, but
41:12 you end up with this constructed database thing and then it has the base model class and off you go,
41:19 right? Just get a session from it, do all the things. I've always had mixed feelings about
41:23 these things that you set up here that are built like into the web frameworks,
41:28 essentially that make them part of the request. Because if you're going to go and write little
41:31 scripts that also do data stuff, you want to want to have, be able to get access to the data and the
41:36 models over there as well. All those looks like it does take the app there, but I don't know if it
41:40 really needs a meaningful app. Like, I don't think that it would use it probably, but it just adds it.
41:45 No, I don't think you need to be within an app context to use the DB. I may be wrong there,
41:51 but yeah, I think you could probably use it in a script. Yeah.
41:54 Yeah. That's the only thing that concerns me about these like database helpers is like,
41:57 you know, I need to do database stuff outside of a request as well. Even potentially some of the stuff
42:02 that we're going to talk about in a minute, like it's just a background task that's not part of an
42:06 actual request, but it could even still be in the web server process, right?
42:10 I use, there's an extension called court DB, which is my preference because I prefer to write the SQL
42:16 and go down the OIM route. And yeah, that works as you'd expect. You'd still set it up and pass it
42:23 the app, which I think is true of this, but then you can just use it without an app context. It just
42:28 basically uses the app to get the configuration values. So it knows where the database is.
42:32 Interesting. And now we're on to probably the biggest one that you want to talk out,
42:37 talk about, which is quite exciting, court tasks. Yeah. So this is a very recent release that I
42:43 haven't announced anywhere else yet. This is something I think I read a post recently that said,
42:49 of free web framework, you need like five things. Like you need a database connection. You need some
42:55 kind of validation, input, output, rate limiting, authentication, and you need array to run periodic tasks.
43:01 And in the past, my way to do this was extra infrastructure. So it was cron running somewhere,
43:08 or some kind of, I think cloud watch does some kind of event generator based on a cron schedule.
43:13 And for me, that's just annoying because now I have to build extra infrastructure,
43:18 which I don't need. I'm not at that scale. Yeah. Maybe you got celery or rabbit MQ or something
43:23 like that, right? Yeah, exactly. But again, with those, you need that extra infrastructure for it to work.
43:27 Yeah. It's another server. It's another thing that could get hacked. You got to patch it.
43:31 You got to secure it. You got to know how to run it. It could go down and then
43:34 none of your background stuff works anymore. It's all, it's all a hassle, even though it has a benefit.
43:39 Yeah. So what I really want to do is make use of the, the async event loop and just run a task in
43:45 the background periodically. And obviously at some point in this one, normally on scale,
43:49 because I have so many background tasks that dominate the server and stop it doing requests.
43:53 But while I'm small and starting out, this is just makes life so much easier.
43:56 Yeah, absolutely. It totally does. And because everything's async and await, you can just set up
44:00 the task and just await the task. And it just blends in hopefully well with all the web requests, right?
44:07 Yeah. Yeah. So for court tasks, if you write your task as an async def, then it will run it in the event
44:13 loop. If you write it as a def, it will run it on a thread. So if you have synchronous code that's going
44:19 to block the event loop, like you're using traditional IO to want for one of the better phrase, then if you just
44:25 use def, they will run it on a task, won't block your event loop and you'll be fine. So yes, it's nice in that respect.
44:30 Yeah. And as long as your async pieces are fine grained enough, you probably won't know.
44:37 Yeah. Yeah. It's just if you run a whole bunch of synchronous code or something like that, you might
44:42 start to clog things up, but don't do that. Honestly, like what you find, what I find anyway on the web
44:48 most of the time is you're talking to other things, talking to a database, talking to a cache, talking to
44:52 an API, and all those things are like perfectly suited for await because it's most of the time you're
44:59 almost outside the web app. Yeah. I think the perfect one for this that I keep thinking of is
45:03 when you want to send a periodic email, like a reminder or a summary of the day, just write this
45:09 decorated task run and you have your function that just sends the emails. It's yeah, that's why it
45:14 exists for me. It makes that so much easier. Yeah, absolutely. Right. Yeah. Like you say,
45:18 just send out a quick email like, "Hey, I need to reset my password." All right, here, we're going to send
45:22 you a call on API, like SendGrid or something like that. We're going to send you, but you don't want to block
45:27 block things up. You just kick that onto the background work and off it goes.
45:31 So one of the things that people would say, all right, you guys, I know you're excited about
45:36 async, but we need durability. What about, what if the server goes down or what if another potential
45:43 issue is what if you scale, like at least the cron stuff, like what if you ban out your web app into
45:49 like 10 worker processes and you say, "Run in five seconds," and they all run in five seconds,
45:54 10 times or, you know, those kinds of issues here. So.
45:59 So this extension supports a couple of extensions to it. So you can pass it a custom store, which allows
46:07 you to store when the task last ran. And so that means if the server goes down and it misses an invocation,
46:13 then when it comes back up, it will recognize that and run the task straight away, rather than wait till the next time.
46:18 And the other thing it supports is you can decide what should happen before the task starts and what should happen after.
46:25 So this allows you to put some locking in for your second case. In both cases, the reason it's not built in to court tasks is you'll need to decide
46:33 where you store this information, where you store the lock, where do you store the. So usually a database works for that.
46:38 So yeah, so you can add it all, but you've got to choose how yourself.
46:41 That's cool that it has placeholders and ways to plug that in.
46:45 That's what I was thinking. I was right. Like instead of just storing it in memory and throwing it on the queue, put it into the database and have the task just check the database and go, okay, I'm working on it.
46:53 No one else do this. We don't want to send 10 emails to the person. I got it. Right. All that kind of stuff.
47:00 It's not a job queue, although I've been thinking about that recently. So yeah, it can't be like, it doesn't work in the sense that job will run once it will do jobs periodically.
47:10 Got it. Okay. So more of a scheduler type of thing. So I need to see if anyone's uploaded files to this location and then convert it from PNG to WebP or like safe space or
47:22 you could be like every morning, I want to send out an email to the users and say, imagine it's a to do app because everyone uses that as an example.
47:29 And say, these are your tasks for the day or something like that.
47:31 Sure. There are people who've signed up for the daily digest, send them their digest. Right.
47:36 Yeah.
47:37 Yeah.
47:37 Yeah.
47:37 Very cool. And because it's on a background thread, it's not going to harm anything. Excellent. Okay. Well, it looks pretty simple. Again, very decorator driven. Right.
47:46 Yeah. So I mean, with all of these, the extensions at least I've written, I've tried to follow the kind of flask conventions for better for worse. So yeah. Same with court. It follows flask.
47:56 Yeah. It feels like if you're already doing flask or court, you just know what to do. It's just similar. Yeah. Excellent. Well, I think we've covered all the ones we explicitly said, let's make sure we get a chance to cover those. I definitely want to encourage people to check out the court extensions page because there's quite a few more. I'll see if maybe some jump out at me here that are kind of cool. Court B trip.
48:17 We briefly mentioned court DB, which is one I maintain. So I can say a bit more about that if you're so interested.
48:23 Yeah, sure. And it's hanging out right here on your list.
48:25 So this is much like the SQLAlchemy one. It's a way to connect to a database, but unlike the SQLAlchemy way, it doesn't promote an ORM rather it just gives you connection that you can run SQL on. I don't know you can do that with SQLAlchemy. I just, I mean, typically that's not what people do.
48:43 So in this case, like the example here is you, you pass it the URL you want to connect to and it supports Postgres and SQL light at the moment. And then in the roots, you have this G dot connection object that you can make use of.
48:56 And you can make use of that in background tasks. And it's quite easy to make use of it actually in court tasks as well. It's just a little snippet you need to do. But yeah, and that's it. You get a connection that you can do whatever you want with.
49:07 Yeah. Okay. Very nice way to just have everything set up right. Like you don't have to worry about passing things around and create a transaction. Go do your things. Right. Excellent. We got court events for broadcasting server sent events and web sockets. That's pretty cool.
49:22 There is one. Yeah. Yeah. Another one that's cool is, minifying all of your elements, right? CSS JavaScript.
49:28 I've been doing that at the build stage a lot recently. There's a little snippet I can share if people want for court where you change the static function. So it will serve a G zipped version of the static file over the un-G zipped one if the client will accept it. And yeah, then if you do it build time, cause I think this one might be a mistake, but I suspect it works at runtime. So it compresses at runtime.
49:51 Sounds like it does. Yeah. It talks about doing it as a response, right? So yeah. Oh, it does have a cache though.
49:58 Ah, okay. Yeah. Well, you get similar. Yeah. Very similar to what I'm suggesting then.
50:01 Excellent. Now those are really, really handy. If people go and they want to make their website better, check out, I guess, page speed.
50:10 Lighthouse is what I was going to call it. Yeah. But they renamed it to page speed. So you can go put in and talk Python and see how we're doing, but it'll give you things like how is your site fast enough? Let's see how the desktop one's doing right. It'll give you a score. And you know, are we going to index you well, or are you going to be punished for having some kind of crappy experience in this minification stuff that we're talking about can help there. Right?
50:34 Absolutely. Yeah. Similar to your DB, your QuartDB, we have QuartMotor, which is the async database access library for MongoDB. So I suspect it's super similar. I haven't used it because I use Beanie, which is like ORM style. So kind of on top of those things.
50:50 KeyCloak is interesting. Redis also is pretty interesting. Uploads. Let's finish it out with uploads. We'll call it after that. So I haven't used this, but uploading files can always be a bit of a hassle, right?
51:02 It looks very similar to the Flask uploads one. So it's a, it's kind of a nice wrapper around how you get access to the files you've uploaded and what you do with them kind of thing. Yeah.
51:12 Yeah. That can be a little bit of a hassle, right? You got your request.files and all that. Don't know how to use this thing, but I know that people kind of struggle uploading files a lot. So that can be a thing.
51:23 I don't tend to actually write it that much come to think of it, but yeah, it's just makes it easier.
51:28 Yeah, exactly. You know, profile, profile pictures, maybe it's like that kind of stuff I'd be doing. Anyway, I guess I've wrote some code that lets you upload MP3s at one point for podcasts, but I stopped using it. So it's not top of mind anymore.
51:43 Anyway, excellent stuff here. I love just going through and seeing all these little pieces, these little building blocks you can bring together and just quickly build an app.
51:51 So thanks for being on the show and telling everyone about it.
51:54 Oh, thank you. Thank you. Yeah. Great. Hopefully opportunity to introduce some stuff that I hope people will find useful.
52:00 Yeah. And just more broadly, like thanks for working on Quart and pushing that forward.
52:03 Yeah. I mean, like I said, our aim is hopefully we'll, well, we're kind of going around in different ways of how we'd actually might merge Flask and Quart, but that's still the ultimate aim.
52:13 I kind of think because of the limitations we were talking about earlier about running async code when you're deep in async code base.
52:21 I think you'll always have to make a choice with Flask where if you're going to be mostly sync, you go Flask. If you're mostly async, you go an async Flask or whatever it's called, which at the moment it's called Quart.
52:30 We might be able to put them in the same code base perhaps. So then you can, you know, maybe mix and match because you can, you can certainly run Flask and Quart together with Hypercorn as the server and just have a, what's called the dispatcher middleware layer in between.
52:44 That says for these routes, it goes to Flask and for those routes, it goes to Quart. So yeah, there are lots of ways to do it, but it depends what you want to do really.
52:52 Yeah. That's interesting. Maybe you could even create a different app instead of app equals Flask. It's app equals async Flask. Who knows?
52:58 That's effectively what Quart is. I mean, I could, if I called it async Flask at the start.
53:03 A Flask. Yeah. It ranks higher in the alphabetical sortings.
53:08 Yeah. All right. So people are excited with Quart. Maybe it's back on their radar now that we've been talking about all these extensions. What do you tell them? How do they get started? What do they do?
53:17 Oh, I mean, you can just pip install Quart and a quick start is as simple and familiar as it's ever been for Flask. You just do app equals Quart and then app.get or app.whatever and then your function below to handle it.
53:30 Yeah. The selling point is basically if you know Flask, you know Quart, you just use the word async some of the time.
53:35 Yeah. Yeah. Yeah. I mean, even the WebSocket support, I've tried to make it as familiar as it would be if you knew Flask. So instead of using the global request, you now use the global WebSocket.
53:46 So there's WebSocket.headers and you can do WebSocket.send, send a message, that kind of stuff. So hopefully it just feels familiar.
53:52 Yeah. Fantastic. I'm sure it does. And thanks for being on the show and nice to have you back.
53:57 Thank you.
53:57 Catch you next time.
53:58 Yeah, you bet.
53:59 This has been another episode of Talk Python to Me. Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show.
54:07 This episode is sponsored by Posit Connect from the makers of Shiny. Publish, share and deploy all of your data projects that you're creating using Python.
54:16 Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards and APIs.
54:23 Posit Connect supports all of them. Try Posit Connect for free by going to talkpython.fm/posit, P-O-S-I-T.
54:30 Want to level up your Python? We have one of the largest catalogs of Python video courses over at Talk Python.
54:36 Our content ranges from true beginners to deeply advanced topics like memory and async.
54:41 And best of all, there's not a subscription in sight. Check it out for yourself at training.talkpython.fm.
54:47 Be sure to subscribe to the show, open your favorite podcast app and search for Python.
54:52 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 talkpython.fm.
55:02 We're live streaming most of our recordings these days.
55:05 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.
55:14 This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it.
55:18 Now get out there and write some Python code.
55:20 Thank you.
55:20 Thank you.
55:26 Thank you.
55:27 Thank you.
55:28 Thank you.
55:34 Thank you.
55:34 Thank you.