|
50 | 50 |
|
51 | 51 | 00:02:23 Sure. Yeah. I guess probably in this context and maybe the people listening are probably known
|
52 | 52 |
|
53 |
| -00:02:30 for Cort and Hypercorn and helping maintain the pallets libraries like Flask and Virksug. |
| 53 | +00:02:30 for Cort and Hypercorn and helping maintain the pallets libraries like Flask and Werkzeug. |
54 | 54 |
|
55 | 55 | 00:02:35 But well, outside of that, I guess in my professional career, I work as a
|
56 | 56 |
|
|
90 | 90 |
|
91 | 91 | 00:04:00 So I thought, okay, I'll start by just re-implementing the Flask API using a
|
92 | 92 |
|
93 |
| -00:04:04 synchro weight. And that's what Cort started out to be. Over the years, David and I have worked |
| 93 | +00:04:04 Async Await. And that's what Cort started out to be. Over the years, David and I have worked |
94 | 94 |
|
95 | 95 | 00:04:10 to try and merge the two together. So the very latest change that's happened a few months ago
|
96 | 96 |
|
97 | 97 | 00:04:15 is we actually based Cort on Flask now. So there's a lot of shared code now. And for a long time,
|
98 | 98 |
|
99 |
| -00:04:21 Cort was based on VerkZug. And if you're familiar with the Palettes and Flask ecosystem, Flask is |
| 99 | +00:04:21 Cort was based on Werkzeug. And if you're familiar with the Palettes and Flask ecosystem, Flask is |
100 | 100 |
|
101 |
| -00:04:26 built on VerkZug. And Cort was, but now Cort is built on Flask, which is built on VerkZug. And |
| 101 | +00:04:26 built on Werkzeug. And Cort was, but now Cort is built on Flask, which is built on Werkzeug. And |
102 | 102 |
|
103 | 103 | 00:04:30 they're very, very similar. Yeah, that's fantastic. Because the more that you can share,
|
104 | 104 |
|
105 | 105 | 00:04:34 like the more you all can just focus on features and making it better rather than
|
106 | 106 |
|
107 | 107 | 00:04:39 duplicating that effort. The other aim is that the APIs, well, the same as they can be,
|
108 | 108 |
|
109 |
| -00:04:44 other than a synchro weight. So you can take your Flask code base and move to Cort just by |
| 109 | +00:04:44 other than async await. So you can take your Flask code base and move to Cort just by |
110 | 110 |
|
111 |
| -00:04:48 adding a synchro weight. That's the dream, even closer than it's ever been to that now. |
| 111 | +00:04:48 adding async and await. That's the dream, even closer than it's ever been to that now. |
112 | 112 |
|
113 | 113 | 00:04:51 You're pretty close to be able to rename the word Flask, keeping the case sensitivity intact from
|
114 | 114 |
|
|
182 | 182 |
|
183 | 183 | 00:07:02 but then I split that out Hypercon into its own thing. And then later on now Hypercon is also a
|
184 | 184 |
|
185 |
| -00:07:07 Whiskey server. So yeah, in some respects, Hypercon is just a general purpose server for Python. |
| 185 | +00:07:07 WSGI server. So yeah, in some respects, Hypercon is just a general purpose server for Python. |
186 | 186 |
|
187 |
| -00:07:12 And so Hypercon, it lives in the same general usage basis, G-Unicorn and MicroWhiskey, UWSGI. |
| 187 | +00:07:12 And so Hypercon, it lives in the same general usage basis, G-Unicorn and MicroWSGI, UWSGI. |
188 | 188 |
|
189 | 189 | 00:07:22 Right. So I could run it in production in a kind of like a overseer mode where you can fan out
|
190 | 190 |
|
|
196 | 196 |
|
197 | 197 | 00:07:41 Yeah. I was just messing with some Docker stuff and I was running the web app, a fast API app,
|
198 | 198 |
|
199 |
| -00:07:49 NG-Unicorn using UVicorn workers. So handling the ASGI stuff that way. Is it better to use |
| 199 | +00:07:49 G-Unicorn using UVicorn workers. So handling the ASGI stuff that way. Is it better to use |
200 | 200 |
|
201 | 201 | 00:07:56 Hypercon rather than something along those lines? A little more direct maybe? Or what do you think?
|
202 | 202 |
|
|
234 | 234 |
|
235 | 235 | 00:09:22 definitely won. You know, even though there's many different web frameworks, right? If you look at
|
236 | 236 |
|
237 |
| -00:09:28 the way programming works, you look at fast API, you look at a light star, many of these things, |
| 237 | +00:09:28 the way programming works, you look at fast API, you look at a litestar, many of these things, |
238 | 238 |
|
239 | 239 | 00:09:34 it's like you've got to create a thing called app and then you say app.get and so on. Right? So
|
240 | 240 |
|
|
384 | 384 |
|
385 | 385 | 00:15:25 How do I share it with my users, stakeholders, teammates? I need to learn fast API or flask,
|
386 | 386 |
|
387 |
| -00:15:30 or maybe view or react JS. Hold on now. Those are cool technologies, and I'm sure you'd benefit from |
| 387 | +00:15:30 or maybe Vue or react JS. Hold on now. Those are cool technologies, and I'm sure you'd benefit from |
388 | 388 |
|
389 | 389 | 00:15:36 them, but maybe stay focused on the data project. Let Posit Connect handle that side of things.
|
390 | 390 |
|
|
756 | 756 |
|
757 | 757 | 00:29:23 very quickly and never touch your route instead.
|
758 | 758 |
|
759 |
| -00:29:25 Okay. Interesting. I'm starting to think about maybe if you have a sync and await |
| 759 | +00:29:25 Okay. Interesting. I'm starting to think about maybe if you have async and await |
760 | 760 |
|
761 | 761 | 00:29:30 available and your algorithm told you when the next one was coming, you could just
|
762 | 762 |
|
|
908 | 908 |
|
909 | 909 | 00:34:32 Yeah. So for this library, it supports, I've used all the documentation as data class, but it's
|
910 | 910 |
|
911 |
| -00:34:37 by dantic based at the moment. And because of the, it's not actually the typing. So there's |
| 911 | +00:34:37 Pydantic based at the moment. And because of the, it's not actually the typing. So there's |
912 | 912 |
|
913 | 913 | 00:34:41 no dependency injection or anything like that with fast API, but it uses the decorator validate
|
914 | 914 |
|
|
1110 | 1110 |
|
1111 | 1111 | 00:42:04 a background task that's not part of an actual request, but it could even still be in the web
|
1112 | 1112 |
|
1113 |
| -00:42:09 server process, right? >> I use, there's an extension called court DB, which is my preference, |
| 1113 | +00:42:09 server process, right? >> I use, there's an extension called Cort DB, which is my preference, |
1114 | 1114 |
|
1115 | 1115 | 00:42:13 because I prefer to write the SQL and go down the ORM route. And yeah, that works as you'd expect.
|
1116 | 1116 |
|
|
1206 | 1206 |
|
1207 | 1207 | 00:45:48 ban out your web app into like 10 worker processes?" And you say, "Run in five seconds."
|
1208 | 1208 |
|
1209 |
| -00:45:53 And they all run in five seconds. DEN times or those kinds of issues here. |
| 1209 | +00:45:53 And they all run in five seconds. TEN times or those kinds of issues here. |
1210 | 1210 |
|
1211 | 1211 | 00:45:59 >> So this extension supports a couple of extensions to it. So you can pass it a custom
|
1212 | 1212 |
|
|
1362 | 1362 |
|
1363 | 1363 | 00:52:11 Flask and Quart, but that's still the ultimate aim. I kind of think because of the limitations
|
1364 | 1364 |
|
1365 |
| -00:52:16 we were talking about earlier about running async code when you're deep in a sync code base, |
| 1365 | +00:52:16 we were talking about earlier about running async code when you're deep in async code base, |
1366 | 1366 |
|
1367 | 1367 | 00:52:21 I think you'll always have to make a choice with Flask where if you're going to be mostly sync,
|
1368 | 1368 |
|
|
1439 | 1439 | 00:55:19 write some Python code. [Music]
|
1440 | 1440 |
|
1441 | 1441 | 00:55:40 [ required co presence in the comment section below ]
|
1442 |
| - |
0 commit comments