10 tips every Flask developer should know

00:00 Are you a web developer who uses Flask? It has become the most popular Python web framework.

00:04 And even if you've used it for years, I bet we cover at least one thing that will surprise you

00:10 and make your Flask code better. Join me as I speak with Miguel Grinberg about his top 10 list

00:15 for tips and tricks in the Flask world. They're great. This is Talk Python to Me, episode 264,

00:22 recorded May 1st, 2020.

00:23 Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the

00:41 ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter

00:46 where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm

00:51 and follow the show on Twitter via at talkpython. This episode is brought to you by Sentry and

00:56 Linode. Please check out what they're offering during their segments. It really helps support

01:00 the show. Miguel, welcome back to Talk Python to Me.

01:03 Thank you, Michael. Glad to be here once again.

01:04 It's great to catch up with you. It's been a while. We used to catch up a little bit more

01:08 when you were in Portland, but a little farther away now. So it's nice to see your face and

01:12 hear how you're doing.

01:13 I'm doing good. For those that don't know, I'm in Ireland, probably not forever. I think

01:20 eventually I will return to Portland. We will go back to have lunch every once in a while.

01:25 Perfect. Perfect. I'm looking forward to it, whatever that is.

01:27 Yes. But for the time being, yes, I am living in Ireland. The plan was to travel a little bit,

01:34 which of course with the current situation, not so much or actually not at all.

01:40 It's not the best time, but you have been there for a while. And I really enjoyed my time in Europe.

01:46 I'm super happy to be in Portland right now. Don't get me wrong. But I really enjoyed living in Germany

01:51 for a year because it was so cool to just go, hey, it's two hours on the TGV to get over to France and

01:57 to Paris. Or I could just drive down to Austria or whatever. It's a different kind of experience over

02:04 there, isn't it? It's really nice. And I'm really looking forward to civilization resuming

02:10 at some point and do that for a little bit more time before we return back to the States.

02:16 Cool. Well, I'm glad it's going well for you, even if you are a little bit restricted in your

02:21 day trips and whatnot, which I'm all behind, right? We need to do this to get through this. It's such an

02:27 insane time.

02:28 Yeah. I was going to say that I feel like I've been preparing for this situation for the last

02:35 few years by working remotely.

02:38 You know, that's really interesting. I totally hear what you're saying and I agree with you because

02:42 you and I talked before you moved to Ireland and I think you were thinking, all right, well,

02:46 where I'm moving to, I might not have a job there. So let me figure out how I can start laying the

02:51 foundation so that I could work anywhere in the world. And I just happened to be hanging out

02:55 outside of Dublin, just enjoying life and seeing things, but maybe still working for

03:01 somewhere in the States or somewhere else in Europe or even doing your own thing, right?

03:05 Yes. It's a little bit of everything actually. And the situation is luckily so far has not affected

03:12 my work life. It affected pretty much everything else in many ways, but I'm working for Twilio right now

03:20 and that luckily is going well and hasn't been affected at all because I was remote before. So

03:28 everything keeps going the same way for me. A lot of the company was not remote and it is remote now.

03:34 So there's been big changes for a big part of the company, but not specifically for me and my team,

03:41 which were, you know, we were remote before.

03:43 It's cool. You know, Twilio is a great company and I'm happy to hear you're working with them.

03:48 I wonder, do you think that for people like you and me and the thousands of others out there listening

03:54 who are already on the remote side of things, it's different for me because I don't have a,

04:00 like a in-office counterpart of my company, right? Everyone I work with that works with me on stuff

04:06 is all remote. So not so much for me, but I guess for folks like in your shoes where I used to be as

04:10 well, do you think this, I guess, forced remote work experiment that we're all on, do you think

04:17 it's made it a little bit easier for you in the sense that it's like leveled the playing field,

04:22 right? It used to be like, maybe there was a meeting with five people in the room and then there was like

04:25 you and one other remote person were kind of on the side. People would like pointed stuff you couldn't

04:30 see or whatever, but now everyone has to kind of be on an equal ground. Do you think it makes remote

04:34 workers a little bit better off in a sense? I think that will be the case for teams that are

04:39 partially remote, partially in office. That is not my case. Yeah. Even though company,

04:45 like your team individually, it's a hundred percent remote. It's 100% remote. Basically what I do at

04:50 Twilio is I work on editing articles for the blog, the developer blog. My team is, you know, editors.

04:56 I work on the Python side and we have people for different languages and that's my team.

05:02 Right. You probably have to coordinate about like, Hey, we're going to have an article on this API

05:06 solving this problem. Exactly. I'll do one in JavaScript. You'll do one in Python and let's

05:10 figure out what the app is, right? We have one meeting a week to basically coordinate. And then

05:15 the rest of the time we work with external contributors, right? Also remotely. So, you know,

05:23 for our team specifically, nothing has changed, but I would imagine, or actually I should say that the

05:31 one thing that changed is that we were getting asked for advice or all this new people who are forced

05:37 to work remotely want to have, you know, tips and basically pick our brains.

05:43 Tell us how you do it, right? Tell us how you make this work.

05:46 How could you make this work, right? I think it's so interesting to watch the news where they have,

05:52 you know, like multiple people on the show or things like the daily show or stuff. I'm especially

05:58 thinking of the news shows with the news anchors where they all have had to start working from home.

06:03 And you can see like week after week, they slowly are figuring it out, right? Yes.

06:08 They had like super echoey laptop audio for their microphones and they're slowly starting to sound

06:15 like ironically, like you and I do. And I think that we sound better. I mean, obviously we do

06:20 recording and stuff, but also because we've had to live a hundred percent as with this as our professional

06:26 interaction. And so to me, like sounding good and looking good, like we both have HD cameras,

06:32 we both have good microphones that is kind of like getting dressed and looking good for business,

06:37 right? Like when you show up for a meeting and you sound horrible and echoey, people don't want to

06:41 talk to you, right? That's not a good look. There's a bunch of layers that we're all cultivating here.

06:45 So what I'm very excited to know is what's going to happen at the end of this. I think a lot more

06:51 people are realizing that it works. You can work from home and you get all that time, you know,

06:58 the commute time back. So I suspect a percentage of, you know, all the people who are now forced to work

07:06 remotely will like it and we'll decide that. Yeah. And I can really do this.

07:12 I think we're not going all the way back to the way it was. It's going to be some of these

07:17 advantages that people were unwilling to try are going to be seen as advantages are going to stick

07:21 for sure. Yeah. Yeah. How about we talk about some flask, huh? Something that you've been definitely

07:27 passionate about for, for many, many years. So we were talking before and you were on episode 48

07:35 over four years ago, we talked about building apps with flask and then you were on episode 121,

07:42 where we were talking about microservices and really with like a bit of a flask angle there as well.

07:47 So you've been a fan of flask for a long time. Yeah. I was a user of flask first and probably told the

07:54 story in the first episode, but you know, quickly I wrote my blog with flask and then not knowing what

08:01 to blog about. I decided to blog about flask at a time where, you know, I wouldn't say that it was an

08:08 obscure framework, but you know, certainly didn't have the following that has now. So my articles for some

08:16 reason were the first that, you know, outside of the frameworks on documentation and it started growing

08:22 at the same time. I decided to blog about it. Yeah. You just catch the wave at just the right time.

08:27 Exactly. But at the same time, you know, you saw the framework, you're like, no, I'm not going to do

08:31 it in Django or whatever else. I'm going to do it in flask. Right. So there's some, you know, picking

08:37 the right ideas. Yes. And part of my, I'd like to think that this was a little bit of my doing. I

08:43 showed why, you know, in many cases flask was the better choice by writing tutorials, usually in my blog

08:50 and showing actual examples where you could do things that, you know, usually are considered hard

08:56 and they're not so hard when you look at them through flask. Yeah. To me, flask, I'll compare it

09:02 to Django because that's its biggest alternative, right? There's certainly all these other new things.

09:09 There's so many new web frameworks coming. I don't know. I'd like to hear your thoughts on this actually

09:13 is there's, there's so many new cool little frameworks. You know, we got FastAPI, we have

09:20 API star, we have Sanic and just all these, they're not all necessarily leveraging the new asyncio stuff,

09:29 but a lot of them seem to be like, Hey, these other frameworks didn't really solve my problem

09:34 because they didn't support async. So we're going to create something that maybe leverages type hints

09:38 plus async. That's kind of like flask. But what do you think about some of those? Like,

09:43 where do you see the action there? First of all, I'm very excited that the model for all these

09:48 frameworks is flask, right? They all do kind of like flask, as you said. Yeah, that is what was

09:54 really surprising to me. So if you compare flask against Django or against pyramid or against the other

09:59 frameworks and you look at their popularity, like I think flask is, we were talking neck and neck,

10:05 but I think actually, if you look at the newer projects that haven't been around for a while,

10:10 flask is pretty clearly ahead of Django in terms of popularity. It's like there's a ton of Django

10:15 apps that people are still working on. So when you ask, do you work on Django or flask? It's a lot of

10:20 times I think it means I work on a Django app that's been around a while. Not that there's anything wrong

10:24 with Django, but just in terms of that growth. But then if you look at flask as the, like the idea of it,

10:30 that all these other frameworks seem to think that this flask style, yes, slight adaptation is what they want, right? Yes. A big reason for that, I think is the,

10:41 we are moving a lot of the, the logic, the business logic and applications to the client side,

10:47 right? With all these new JavaScript based frameworks for the browser, right? So for sure,

10:53 what's left to do in the server is really the database storage related actions and maybe

10:59 authentication, surely authentication, and that's it. So if you look at a framework like Django,

11:06 you can do that really well, but it has a lot more components that you really have no use for.

11:12 And, you know, all these new frameworks modeled after it sort of give you just the API portion of

11:20 your server side part of your project. Right. It's kind of just enough server side.

11:25 Yes. Right. Yeah. I would say that it has a little less and then you can pick,

11:28 you know, the right extensions to, to make it exactly what you want.

11:31 Yeah. Right. Right. Add on. Yeah. That's a good point. I'm still a fan of having a decent amount done

11:38 on the server side. I, I don't know. I just, I like the instant, you know, I don't know. It drives me

11:45 crazy to see these pages sort of like build up as I interact with them. You know, you'll see like,

11:50 oh, you're logged out. No way. Half a second later, I'm logged in and like, you know, just that kind of

11:54 stuff. I'm not a huge fan of. You should find the right mix between, you know, server and client.

11:59 I think people are too quick to go to build everything as a single page app, react to view,

12:05 angular, you know, those types. And they, they don't think about doing it a right balance. Sometimes

12:12 you don't expect everything to be done in a single page. It feels weird. The whole page is changing,

12:19 but it's really done in react, for example, which is slow and weird. It messes with the back button

12:26 in the browser. I prefer to basically use the single page app only when you see a clear benefit.

12:33 You really need like an interactive thing. I'm building like a little dashboard I'm exploring

12:37 or something like Gmail or something like it's perfect. Right. But it shouldn't be the one hammer

12:43 you hit everything with in the web.

12:44 My blog, the blog that I wrote six, seven years ago, when I started with Flask, it's still a

12:51 traditional application server centric. And, you know, it's just fine. It has a little bit of

12:56 JavaScript sprinkle here and there to make it a little bit nicer, but you know, it's mostly server side.

13:02 And I think for a blog that works really well.

13:04 Yeah, I agree. So you're talking about the front end frameworks. Like I agree, like don't overuse

13:09 them whatnot, but sometimes they make a lot of sense. What ones do you like right now?

13:14 My preference, and this is going to generate, generate a little bit of disappointment in your

13:20 audience. I think it's a vanilla JavaScript. That is the framework or the no framework that fits my

13:27 brain the best. So I can do whatever you want in vanilla JavaScript. A few years ago, I would say

13:34 jQuery. These days you don't really need that. The jQuery was a layer that will make all the browsers

13:41 sort of uniform. And these days the browser, the browsers are pretty good at being uniform with each

13:47 other. So that's my favorite. Out of the real frameworks, React is the one that I've used the most,

13:53 but only for simple apps. What I've seen is that all these dependencies that are generated

13:59 between all the parts of the page, it's very easy to get them completely out of control as the project

14:06 grows. At least I personally find having a handle, like for example, when writing vanilla JavaScript,

14:12 having a handle of what part of the page it's related to what other part makes it for a much faster and

14:20 dynamic application. For small examples, I think React is a good model. And that is what I use.

14:26 Nice. If I had to throw my vote in for one, I'd put it on Vue. I like VJS a lot. Yeah. I like it just

14:32 quickly, just bring it in, just include a JavaScript file, you know, pull out an ID and say,

14:37 this little sub part of the page is now an app. I really like that.

14:41 Yeah. Vue will be my second choice actually. Yeah.

14:44 This portion of Talk Python to Me is brought to you by Sentry. How would you like to remove a little

14:50 stress from your life? Do you worry that users may be having difficulties or are encountering errors

14:56 with your app right now? Would you even know it until they send that support email? How much better

15:01 would it be to have the error details immediately sent to you, including the call stack and values of

15:06 local variables as well as the active user stored in the report? With Sentry, this is not only possible,

15:12 it's simple and free. In fact, we use Sentry on all the Talk Python web properties. We've actually

15:18 fixed a bug triggered by our user and had the upgrade ready to roll out as we got the support email.

15:24 That was a great email to write back. We saw your error and have already rolled out the fix.

15:28 Imagine their surprise. Surprise and delight your users today. Create your free account at

15:34 talkpython.fm/sentry and track up to 5,000 errors a month across multiple projects for free.

15:40 Flask is on the rise. I think it's on the rise in its own right. And I think it's

15:46 on the rise in the sense of its API as we talked about. So let's dive into the 10 tips that we're

15:54 going to talk about. Yes. 10 tips. Yeah. What do you got for number one here? Okay. Number one,

15:59 it's actually very specific to APIs. Okay. You do not need to use the JSONify function anymore. So this is

16:06 in recent Flask releases. For many years, if you needed to return a JSON response, you had to

16:14 call the JSONify function, which would take a dictionary or list and convert it into the actual

16:21 payload that goes out to clients. Right. So if I've got a view method and I wanted to return JSON,

16:27 I can't just say return a dictionary or return a list and have it internally serialized to JSON.

16:33 Right. That'll like not work. Not until now. So I've always done JSONify as well. Now what can I do

16:39 instead? So basically now you return a dictionary and Flask will itself say, okay, this, this goes out as

16:48 JSON. So it will JSONify the response, set the correct content type and all of that.

16:53 So when I think about this, what else has to be done to make this work? Do I need to add anything

17:00 like to the route decorator to say the response is JSON? No. Or is it enough if the client connecting

17:06 says, except type is application slash JSON, or what do I need to do? You don't need to do anything.

17:10 So this is always Flask looked at the type of your response that you're returning your view function.

17:18 There were always different behaviors depending on the type. So if it was a string, it would send it as

17:24 text. If it was a response object, it will send it as basically whatever you said in that response object

17:31 and so on. And now there's one more type. If you return a dictionary, then Flask says, okay,

17:38 this is JSON. It basically sets everything up for the response to be all done for you. So it's really

17:44 great. I'm not importing JSONify anymore. There's no need at all to import that function and then have

17:51 it in every single last line of all your view functions.

17:55 Yeah, that's really clean. I definitely like that. That's something I've really liked about the

17:59 Pyramid Web Framework is you've been able to do that the whole time. You just return some data type

18:03 and it'll serialize it. Yeah. So really glad to see this is nice and clean. And yeah, I think when I

18:09 first started doing Flask, I was like, oh, I'm going to try to return a dictionary. Oh, it doesn't like

18:13 that. Now I have to go hunt down. So ran across JSONify and I didn't realize that that had been

18:18 sort of more made more general. So you don't have to. That's great.

18:21 Yeah, it's really nice. For many years, I used the decorator specifically for that. It was

18:25 an at JSON that I even taught in many classes how to create a decorator that will take that response,

18:32 a dictionary. Absolutely. And I've created a decorator exactly like that that takes in the

18:38 decorator, you specify the Jinja template and you return a dictionary and then it'll like send that,

18:42 it'll render template with that dictionary as well. I'd love to see those kinds of things built more

18:47 into Flask. I mean, I know this one's no longer relevant, but there's a couple of things like that

18:51 that would be kind of cool, I think. Yeah, very nice. Okay. So no more JSONify

18:55 API is a little bit less coderad. It just makes it cleaner. I love it. All right. Number two.

19:00 Number two is do not store sensitive information in your user session. I see this a lot. It's so

19:07 convenient. You have, you know, from Flask import session and then a session works like a dictionary

19:13 and it's so tempting to write any kind of information there that, you know, in the next request from the

19:20 same client, you can recover. It's preserved per client, right? So...

19:25 Right. Like if you log in, you could put like the user ID in there. And so then the next request comes in,

19:29 you could pull them back.

19:30 So you certainly put the user ID. So it's very important to remember that unless you configure

19:37 Flask in a non-default way, those sessions are not encrypted and they are sent in cookies to clients.

19:46 So the client is storing all that information that you put in the session dictionary. So you should

19:52 definitely never store information that you do not want to be public.

19:58 at least the user could go in there and see it or they could go in and they could mess with it,

20:04 right? They could tamper with the cookies and whatnot, right? You definitely don't want that.

20:08 So that's actually a good point. They could not, clients cannot modify it. The cookie is a secure

20:14 cookie. It has the content. It's not clear text, but it's also not encrypted. It's in base 64 encoding,

20:20 which is very simple to...

20:21 It's like visually encrypted, but that's all.

20:24 It's visually encrypted, right? So it's base 64 encoded, but there's also a crypto signature

20:29 in the cookie.

20:30 I see. Okay. So it's tamper proof.

20:32 Correct. If you make any changes in the client and then try to send that cookie again to the server,

20:37 Flask will say, no, this is not, the signature is incorrect and it'll throw it away. So that's not

20:43 a problem. So it's safe against tampering, but it's really not safe against seeing what the

20:49 information is. So never store cookies or, I'm sorry, secrets, passwords, you know,

20:55 nothing of that sort.

20:56 Yeah. So I've never used the session feature of Flask. I've always just said, I want to store a

21:04 cookie. And it just has like one piece of identifying information to like carry on that session. And then

21:10 I'll go back to the database to get the rest, everything else, right?

21:13 Okay.

21:13 Should I not be using this? Like, should I be using session? Should I look more into it?

21:17 Session is actually very convenient and Flask has a plugin architecture. You can install different

21:23 types of sessions. The default is the cookie or secure cookie based session that I just described,

21:29 but there's an extension called Flask session, which provides sessions that are stored server side.

21:36 So this extension provides a number of storage mechanisms. You can store them in files,

21:41 pretty much in the style of PHP. If you've seen how those are stored, you can store them in a database,

21:47 right?

21:47 Through SQL Alchemist, for example.

21:49 Probably Redis. Yeah.

21:50 There's a Redis backend as well. So Flask session will be, you will have to do that if,

21:56 if you want to store sensitive information in your session and then you will be safe,

22:00 right? Because the only thing that will go on the session cookie in that setup will be the session

22:05 ID, but all the information will be safely stored in the server.

22:09 Okay. Yeah. That sounds like a pretty good thing. And the server side bit is nice, right? So you can

22:15 store those things, but not actually send them. And even if it's not because it's sensitive,

22:19 maybe it's not reasonably serializable or it's not, maybe it's just a lot of data, right? You don't

22:26 want to send like cookies are limited in how big they can be. And you don't want to exchange like

22:30 huge cookies anyway.

22:31 They need to be there. They are encoded to JSON before the base 64 encoding is applied. So the,

22:38 whatever you store in the session needs to be JSON compatible. So a string, a number,

22:42 a list of, or a dictionary. So yes, definitely there are some limitations.

22:47 Cool. All right. What's number three?

22:49 Kind of related.

22:50 Oh, before we move off this one though, I want to do say one thing really quick,

22:53 maybe a 2.5, 2.7, something like that. You're talking about exchanging these cookies. And I was

23:02 kind of thinking, well, okay. So the user really needs to be careful about like, it'll be on their

23:06 file system somewhere as a stored cookie. They can go to their dev tools and look at their cookies and

23:11 whatnot, but it's kind of safe to the world. That's making a really big assumption that that

23:15 connection is encrypted.

23:16 Right. Yes. And actually these 10, maybe we should have an 11th tip, which is always use HTTPS.

23:24 Yeah. Yeah. That was going to be my 2.5 is like, let's encrypt, right?

23:28 Yeah. You always have to have encrypted servers when you deploy for production. Even if you think that

23:34 you have nothing that's sensitive in this day and age, there's really no reason to risk it because

23:42 you can get a free SSL certificate from Let's Encrypt.

23:45 It's incredibly easy to set it up for Let's Encrypt.

23:47 It's very easy to set it up.

23:49 Yeah. I had resisted it because I was like, I don't really want to learn how, I already have this other

23:52 SSL certificate I bought. It's like good for three years, but I don't want, and then I finally just

23:57 said, all right, I'm going to find out, like, I'll just get Let's Encrypt working just so I don't think

24:01 about renewing this other one. And it was like 10 minutes later. I'm like, oh, that was really easy.

24:05 Yes.

24:06 That was learning. You know, the second time it's even quicker.

24:08 Yes. And the certificates last, you know, they're short-lived. They last for three months,

24:12 but you set it up so that they automatically renew. And it's something that you never need to think

24:18 about. They basically, they just work. So yes, absolutely. You always have to have SSL encryption

24:23 on your sites deployed to production.

24:27 Yeah. Two more aspects to that. Obviously this, we think of privacy when they think encryption,

24:31 but SEO, Google is taking into account whether a page is secure or not as well these days. And

24:40 they're also taking into account performance. One of the really nice ways to get performance these

24:45 days is to just do HTTP2, right? And I'm pretty sure that only runs over SSL.

24:50 I'm not so sure about that. Maybe.

24:51 You know? Okay. I can't remember. I feel like I tried to set it up before. I don't know. I think

24:56 I'll mess around while we're talking and figure it out.

24:58 We should definitely figure it out. And in general, I've found that you can add all the HTTP2

25:04 solutions, you know, outside of your web application. I don't find that I need to worry

25:10 too much about that within Flask, for example. You put a reverse proxy in front that will take care of

25:17 that. That's actually the same idea that I'll apply to the encryption. In general, I prefer to

25:22 leave that to tools that, you know, that do that well, do it in native language, not in Python.

25:28 It's way faster and more efficient. So all those things are good to have, but luckily they haven't

25:34 changed, at least for me, how I write my web applications in Python and Flask.

25:39 Yeah. Same. Yeah. I'm doing HTTP2 for my stuff. And it's like, most of that is around serving the

25:45 CSS and the images and the JavaScript through Nginx. And like, that's even before you talk Python,

25:49 right? Okay. So let me read something really quick and you interpret it for me. This is from

25:53 SSL.com. It says, browsers distinguish between clear text HTTP2 and HTTP2 over encrypted TLS as two

26:01 different protocols. As of this writing, none of the major browsers support H2C, which is a clear text

26:07 version, which means TLS encryption is mandatory. So the protocol specifies a non-encrypted version,

26:13 but apparently the browsers... None of the browsers do it. Right. At least as of 2000, November,

26:19 2018. Right. So maybe they have, but I'm surprised if they'd be... I don't see why they would. Right.

26:25 Exactly. So I think theoretically you don't need SSL, but in practice you need SSL. So one more reason,

26:31 I guess there. Cool. All right. More secrets. Number three. Okay. Another secret related one.

26:37 You should use a .env or .env file to store your secrets. I'm sure if I go search GitHub for the

26:47 standard names that people assign to AWS secrets or even Twilio passwords, you know, all those things.

26:55 All these things.

26:56 I'm sure I can collect a bunch of them, right? That people put in source code and then they forget.

27:01 Yeah. And that's fine until it's not. It's fine because you're like, oh, we're never going to open

27:06 source this. And then somebody does and they don't realize it. And then bad stuff happens.

27:09 S3 buckets are exposed and so on. Right. So you should get used to never write a password or a

27:18 secret on an API key directly in the code, even if you're doing it for a quick test, because it happened

27:24 to me many times. I think that I'm going to do a quick test, but then that evolves. And eventually

27:29 I said, oh, this is a good thing to show in a gist. And then off it goes to GitHub. So never do it.

27:35 And then you'll be safe. What you need to do instead is to replace in the place where you are

27:42 going to write the password or secret, just read an environment variable and then get used to always

27:47 have the secrets that you use in your applications in environment variables.

27:51 Right. That's helpful for things like Docker as well. It helped you create these more isolated

27:57 reproducible elements. So that totally makes sense. And I've heard put them in environment variables,

28:02 but what's the story with the .env file? How's that relate?

28:05 The problem is that people find it annoying to have to set environment variables because when you set an

28:11 environment variable, the life of that environment variable is the session, right? If you close your

28:16 terminal window, let's say we're talking about development, right? So at the end of the day,

28:21 you turn off your machine. The next day, all those environment variables are gone, right? So my

28:26 recommendation and something that works really well with Flask is that you put all your environment

28:32 variables in the .env file and then Flask in recent releases, if the package python.env is installed,

28:41 we'll just import all those variables when you run the application.

28:45 And it basically sets them as if into the environment. Like if you ask for them from the

28:50 environment dictionary, they'll be there.

28:52 They'll be there in the same way as if you had set them by hand on your terminal before running

28:57 Flask run.

28:58 Okay. What's the name of this package?

29:00 Python-.env. D-O-T-E-M-V.

29:02 Yeah. Yeah.

29:03 There you go.

29:03 Cool. I'll put it in the show notes.

29:05 So even if you don't use Flask, this package makes it so simple to import a .env file. You just

29:12 need to call a function load.env. That's it.

29:15 And then after you call that, all the variables that you stored in the .env file will be in your

29:21 environment.

29:21 So I totally agree with this, but I always wonder what people use to persist and version and keep

29:29 those types of things.

29:31 Where do you store the stuff?

29:33 So if you got a new computer or you got a new team member, how do you get them this information?

29:37 I'm going to tell you what I do. Some people may like it. Some I'm guessing won't. But what I do is I

29:42 create a .env template. I usually call it .env-template or something very clearly that you can see that it is an

29:51 example of how your .env file should be structured. And in that template file, I write the variables,

29:59 the equal sign, and then I leave it empty. So when you're installing your application in a new machine,

30:06 you copy the .env-template to .env, and then you fill out your secrets. And yes, it is annoying,

30:13 but it's only the first time when you're installing a new application. That's the only time you have to do

30:18 it. And then it works. Second to that, you have to put the .env file in your gitignore file,

30:25 because you, of course, don't want to commit that on purpose or by mistake to source control.

30:31 Right. That kind of defeats the purpose, right?

30:33 Of course.

30:33 I think that might be a default in GitHub if you pick the Python ignore template. I can't remember,

30:39 but I think so.

30:40 No, actually, I wouldn't say that. That was my complaint. I don't believe it is.

30:44 Oh, it's just .env, not .env?

30:46 Right. I don't think they have .env, even though it's actually fairly standard. Many technologies and

30:53 many languages and frameworks use it, but I don't believe it is. I'd like to see it there by default.

30:58 Yeah. Well, you know that these gitignore templates are like projects on GitHub, right? So like

31:06 github.com/github slash gitignore is the project where those are kept. We could do a PR,

31:12 see what they think.

31:12 We should do a PR, definitely.

31:14 We should do a PR, yeah.

31:15 This portion of Talk Python to Me is brought to you by Linode. Whether you're working on a personal

31:21 project or managing your enterprise's infrastructure, Linode has the pricing, support, and scale that

31:27 you need to take your project to the next level. With 11 data centers worldwide, including their

31:32 newest data center in Sydney, Australia, enterprise-grade hardware, S3-compatible storage, and the

31:38 next-generation network, Linode delivers the performance that you expect at a price that

31:43 you don't. Get started on Linode today with a $20 credit, and you get access to native SSD

31:48 storage, a 40 gigabit network, industry-leading processors, their revamped cloud manager at

31:54 cloud.linode.com, root access to your server, along with their newest API and a Python CLI.

32:00 Just visit talkpython.fm/Linode when creating a new Linode account, and you'll automatically

32:06 get $20 credit for your next project. Oh, and one last thing, they're hiring. Go to

32:10 linode.com slash careers to find out more. Let them know that we sent you.

32:14 Good advice. Another thing that I've seen, this is not the same, it's the same vein, but it's not the

32:21 same thing, is, and this honestly sounds better, but also pretty good, is usually we're using virtual

32:27 environments for web apps and any meaningful app, right? So the virtual environment you create has an

32:34 activate script, you can set environment variables there. So anytime you activate the virtual environment,

32:40 it's always got its environment variables set. It's kind of the same, you create a new one,

32:44 you got to reset them, but similar.

32:46 Yes, it's a little bit more difficult to remember to do it when you do a new installation.

32:50 Yeah.

32:51 But yes, definitely a good readme pointing you to do it should help and you achieve the same result.

32:56 I think the one difference is like the .env template explicitly kind of reminds you that

33:02 there's some kind of thing I've got to do, whereas the virtual environment is like magic. Like it's good

33:07 when it's set and it's working, but there's no indicator that this is a step you need to do.

33:11 Yes, that is a good point because when you call the load.env function from this Python.env package,

33:17 if there's no .env file in the file system, it'll print a warning. So you will see a warning in the

33:23 console.

33:24 Nice. That's good. Perfect. All right. What's number four?

33:27 So this is not specific to Flask, but for many years, people who use Windows, they're sort of

33:33 treated like second class citizens, right? Because most tutorials I've written for Bash and, you know,

33:40 Unix based.

33:41 Dot space VMV bin activate. Like, wait a minute, that doesn't work.

33:45 The dot doesn't work. The bin doesn't work. What is all this?

33:48 Right. And then the forward slashes versus the backward slashes that you use on Windows.

33:52 So in recent years, there's also Chromebooks, which are another group of people, the users of Chromebooks,

33:58 who sort of felt at a disadvantage because you have a perfectly fine machine where you should be able to

34:04 write, develop code, write Python. But for many years, it was not possible or it required hacks on the

34:12 device itself. So these days, both Windows and Chromebooks both have Linux emulation solutions.

34:20 They're not the same, but the end result is that you get a Linux prompt where you get Bash or C shell

34:27 or your favorite shell that you'd like. And then basically you can run Ubuntu Linux in your Windows or

34:34 Chromebook machine.

34:35 Yeah. Nice.

34:36 So I don't use Windows so much now, but I have a Chromebook. I can do pretty much anything I do on my

34:42 Mac laptop on the officially supported Linux emulation on the Chromebook.

34:48 So definitely take a look at the WSL, the Windows subsystem for Linux, if you're on Windows or the

34:55 Linux files support, if you're on Chrome OS, because on both, you can run the Ubuntu or other

35:03 distributions. That's the default, but you can use a different one if you like. And you can run Python,

35:08 you know, recent versions of Python, Flask, and all of that works exactly like it would on a

35:14 Unix or POSIX type OS. So you will be able to follow tutorials using the standard instructions

35:22 that you see for Unix.

35:24 Yeah, that's cool. And the Windows subsystem for Linux 2 was just released not long ago,

35:29 which is a big improvement, I understand.

35:30 It's actually an improvement in performance and it's actually more directly, it's less of a VM

35:36 or virtual machine solution.

35:38 Right. It's kind of more linked between the different two environments and apps and whatnot. Yeah.

35:43 Like you can open Explorer from your Linux and to get your file system, stuff like that. But I think

35:48 actually the Chromebook story is bigger because one of the important places people might want to use

35:54 both Chromebooks or rephrase that they have a Chromebook as their only option and they want to learn Python

35:59 or programming is in the educational space.

36:03 Oh, yes.

36:03 So many kids have Chromebooks. My daughter has a Chromebook from her school and if they wanted to do Python,

36:09 they could maybe do some online thing, maybe? Or the answer was no, you don't do Python, right?

36:14 It's actually hard to even an SSH connection to a remote server. You can, but it's tricky. It's not

36:21 immediately obvious how to do it. But now you can run your own local Ubuntu distribution in the Chromebook.

36:28 Nice. Cool. That's a big deal.

36:30 And it's all official. It doesn't require any hacks. It's all sanctioned by Google and developed by Google as well.

36:36 Cool. And shout out to the folks over at Canonical for releasing Ubuntu 20.04 LCS.

36:42 Yes.

36:43 The first LCS release.

36:44 Yeah. In two years. So it was super awesome. And it comes with Python 3.8 as the default and Python 2 is not even installed.

36:51 So the Python story is better there. And obviously just the new Ubuntu is nice. Cool. All right. Number five.

36:56 Number five. So this is the thorny one. A lot of people to this day don't understand the contexts in Flask.

37:04 Most people don't see this, but they only learn about it when they get an error. And there's actually two different errors.

37:11 And they're so similar that people think there's only one. And the two errors are you're working outside of the application context. That's number one. And then the second one is you're working outside of the request context.

37:24 And I suspect this is where people are going just statically saying Flask.request.property. But that's not set.

37:32 Right.

37:32 Because they're outside the context. Yeah.

37:34 This comes all from the philosophy of Flask, which is to make all these variables, let's call them variables, that are global in nature to be magically available.

37:44 So you import, for example, current app or your import request, and then you just use it as if it was a global variable. It's actually, there's a little bit of magic underneath these imports, but you use them as global variables.

37:57 And if you use them in the wrong place, then you get the error.

38:01 Right. So once the context is created, these are what, thread local storage, basically?

38:06 Yes. The implementation is based on thread local storage. So they basically belong to a thread.

38:12 Right. And that's the request coming in through like micro WSGI or something like that. Sets that and then the rest of your app just has it.

38:17 Correct. So the interesting thing is that people don't realize that these are very different.

38:23 If you get the, you're working outside of the application context error, that means that some piece of code wants to know what the application is.

38:34 And all you need to do is set the application context yourself.

38:39 If you look in the Flask official documentation, it shows how to do it. It's a single line.

38:44 There's even a context manager to do this.

38:46 So you set the context and then your code will work and you solve the problem. That's it.

38:52 Yeah.

38:52 The issue is when you get the other one and people confuse the two.

38:55 But if you get, you're working outside of the request context, that typically means that you have a bug in your application.

39:01 You're trying to get information about a request and there's no request, which means that you're running this code.

39:07 Right. Maybe you kicked off a thread or something weird thing like that.

39:11 Yeah.

39:11 You're doing it in a place where there's no information about the client.

39:15 So you know nothing about a client or a request.

39:18 I see.

39:19 That indicates that you have a bug and people find crazy ways to fix that basically to avoid the error.

39:26 And one that I see a lot is that Flask has this way to create a test request for unit tests.

39:33 Right.

39:34 If you create a test request, then you can invoke request dot something and it will work.

39:40 But the information that you get is all fake.

39:43 So, I mean, the fact remains, you're probably doing something in a place where you shouldn't be doing it.

39:49 So, application context, if you get the error, you set the context and you're good to go, it's perfectly fine.

39:55 Request context, you need to look at your code, you probably have a bug.

39:59 You're doing it wrong.

40:00 You're doing it wrong.

40:01 Cool.

40:01 All right.

40:01 What's number six?

40:02 Number six is still related to this topic.

40:06 I've seen many, many applications that have, for example, they have Celery workers or any other type of auxiliary processes, maybe cron jobs, you know, all those things.

40:18 So, let's say you have a web application written to Flask and you're using Flask SQLAlchemy for your database.

40:27 So, when you go write the Celery side or the cron job, what do you do?

40:33 You create all the models using Flask SQLAlchemy.

40:37 And that extension has a very nice way of managing your connection.

40:42 You don't have to worry about it, actually.

40:43 Right.

40:44 Create the engine, create the connection, create the table, all that.

40:46 Yeah, right.

40:47 All of that is done.

40:48 You don't do any of that, right?

40:50 When people start coding their Celery workers or cron jobs, they say, well, okay, I'm going to have to do all of this myself.

40:57 They create their SQLAlchemy engine and they have to figure out crazy ways to get the models which are written to inherit from db.model, which is a Flask SQLAlchemy class, you know, to inherit from the base, you know, the declarative base from SQLAlchemy.

41:13 And they invent a lot of crazy ways to make that work.

41:16 And the fact is that you don't have to.

41:19 You can create a Flask instance and instantiate Flask SQLAlchemy and then not start a server.

41:26 And you can use the database just fine.

41:29 Right.

41:29 If you just don't call Flask.run, you're kind of everything set up anyway, huh?

41:32 Don't run the server, but create a Flask instance in the Celery worker, in the cron job, it doesn't matter.

41:38 Just create, call the create app function to make it an application, configure it exactly like you configure it for the server, but then don't start the server.

41:48 Yeah.

41:49 And then that gives you access to using all the extensions.

41:52 You can use the database through Flask SQLAlchemy just fine.

41:55 There's absolutely no problem.

41:57 Another big one is sending emails.

41:59 So if you use the Flask mail extension, it's exactly the same thing.

42:03 You can send an email from a Celery worker.

42:05 You don't have to look for a different library.

42:08 You can just create a Flask application instance, configure it, and then Flask mail will work just fine.

42:13 Yeah.

42:14 And well, sending email is exactly why you would do this on another thread or in a background.

42:19 Because if you're sending one email, fine.

42:22 It's probably okay.

42:23 It's not ideal, but it's fine.

42:25 But I ran into this thing where I had thousands of people sign up to get notified when I posted a new office hour.

42:33 Because I have free office hours for people to take my courses.

42:36 They can drop in on Zoom and chat and whatnot.

42:39 When that started to grow, I remember hitting it.

42:41 And it literally timed out the request, trying to send the emails.

42:45 And then it was halfway through sending the emails or some percent through.

42:49 But I didn't know how far.

42:51 So I didn't know how to go back and send the rest of the emails.

42:53 I'm like, well, the other rest of the people are just not getting sent because I'm going to email the first half again.

42:58 Right?

42:58 It's just like, it's not a thing you do as part of a request.

43:01 It's really sad that similar stories happened to me.

43:05 And yes, that's actually a good reason to send the emails to a background job.

43:11 And then it can take as long as it needs.

43:13 But yes, you would need to create the Flask application instance.

43:17 You will need to set the application context.

43:20 Because in a particular case of both Flask SQLAlchemy and Flask Mail, they need an application context because they need to get the configuration.

43:30 That's all they need.

43:31 That's actually, they don't really care about Flask itself.

43:34 But they have the configuration variables in app.config.

43:40 So you need to set the application context.

43:42 So they need the first part.

43:43 They need the app part.

43:44 Yeah.

43:44 Right.

43:45 They just need to know where the app is.

43:46 So only so that they can get to the configuration.

43:49 And then they can know what the database is or what the email server is.

43:52 So definitely do it that way.

43:54 And then you can have a consistent way of working with database or emails between the server and your auxiliary processes.

44:01 Yeah.

44:02 That's great, great advice.

44:03 Now when I'm doing something like email, even if I'm just sending one, it's on a background job.

44:07 It's not part of the request.

44:09 It should always be.

44:09 And people don't realize this, but sending an email is actually very slow.

44:13 It takes a few seconds if you're lucky.

44:15 Right.

44:15 Well, and it also depends on things you don't control, right?

44:18 Like you probably control your database somewhat.

44:20 But this is like some external mail server that's then talking to some other thing.

44:24 Yeah.

44:24 Yes.

44:24 And, you know, many servers introduce artificial delays for security purposes.

44:29 There's a lot of tricks that many servers implement.

44:32 The end story is that sending an email takes two, three seconds at least.

44:36 Yeah.

44:36 Just one.

44:37 At least.

44:37 Yeah.

44:38 So it should never be done in the server, you know, in the foreground of a server route.

44:42 Right.

44:43 Absolutely.

44:43 All right.

44:44 Number seven.

44:45 This one I kind of nudged you to cover.

44:47 Yeah.

44:47 This is a good.

44:49 Because I'm a fan of it.

44:49 But yeah, tell us about this one.

44:51 I'll jump in as well a bit if you want.

44:52 You surely know this one better than me because I found out a few days ago when you pointed this out.

44:58 But secure.py is a project that provides a lot of security settings around how you configure your cookies, your HTTP headers, in your requests, actually in your responses.

45:14 Not only for Flask, but for a lot of frameworks.

45:16 A really long list of frameworks.

45:19 Yeah.

45:19 This is one of the things I really like about this project.

45:21 It's because if I go learn how to do secure headers in Pyramid, then I go write my Flask API.

45:28 I've got to like rethink, okay, well, what does this default to?

45:31 And then how do I do it?

45:32 And what's cool about this is it's like literally one line, one piece of middleware or callback.

45:37 And you've got all these things added.

45:40 And it works for Flask, Pyramid, Django.

45:43 Like Starlette and...

45:45 The newer frameworks, right?

45:46 The AsyncIO frameworks.

45:47 Right.

45:48 All the core, which we'll talk about, Responder.

45:51 Like it has support for all.

45:52 So you just do the one thing for that framework, the one line, and then you're good.

45:56 All right.

45:57 So tell us about like why do we care about these things?

45:58 What is this?

45:59 There is a number of things that the default configuration for Flask and for all the other frameworks, they don't do.

46:06 And the reason why many of these things are not set by default is that they don't make sense during development.

46:12 I mean, that's one of the reasons.

46:14 Yeah.

46:15 Yeah.

46:15 Like strict transport security, for example.

46:17 Right.

46:18 Like you don't want to run SSL to just run localhost, right?

46:20 Exactly.

46:21 That would be an unnecessary complication.

46:24 Or setting the secure bit on your session cookie.

46:28 That's another thing that you will not do when you're working on your application, but that you definitely need to do when you deploy the application for production.

46:37 Right.

46:37 If I have that right, that means I'm only allowing the server and the browser to exchange that cookie if it's an SSL request.

46:45 So maybe I type the domain name, but I don't put HTTPS at the beginning and it does a HTTP and then an HTTP redirect to the S.

46:52 It's a very clever hack that some people exploit.

46:55 The browser will send your cookies unless told otherwise, regardless of you going to the site via HTTP or HTTPS.

47:05 The browser doesn't care.

47:07 Unless you tell the browser that the cookie should only be sent on the secure connection.

47:12 So the default is not set.

47:14 So cookies in Flask are not secure.

47:16 What people do is they call your site with HTTP and that basically forces the cookie to go from the client to the server on an encrypted connection.

47:26 Right.

47:27 And it can be intercepted.

47:29 Right.

47:29 And then probably your server will say, well, I don't have HTTP.

47:33 It'll do a redirect to the same URL.

47:36 But it's too late.

47:37 It's too late.

47:38 The cookie's been exchanged.

47:39 Yeah.

47:39 Time that's too late.

47:40 Exactly.

47:40 The cookie has been, you know, traveling the network, you know, unencrypted.

47:44 Yeah.

47:45 Yeah.

47:45 Definitely.

47:45 This is a good way if you don't want to think about security.

47:48 And, you know, ideally most people, they're not security experts.

47:53 So this is a good way to make sure that you have the baseline of your security protections all in place.

48:00 Yeah.

48:00 So some other things that it does is it prevents your site from being embedded in an iframe in another site automatically.

48:08 Right.

48:09 So people can't spoof yours, like wrap it with something else.

48:12 Yeah.

48:12 It turns on strict transport security, things like that.

48:15 Yeah.

48:15 The list of things that they do is actually way more than what I would have done myself or what I do myself by hand.

48:22 It's definitely worth checking.

48:23 It comes from the OWASP, like, which is a web security group.

48:27 It comes from their recommendations and it just automatically adds it.

48:30 And I imagine if there's a new recommendation, it'll just pick it up when you pip install upgrade this and you'll get the newer ones, which I think is nice, like kind of like versions your security.

48:39 So, yeah, it's really easy to use and I dig it.

48:41 So even if you're a do-it-yourselfer, it's a good place to learn all these things.

48:47 As I mentioned, there are many in that list of things that they do that, you know, they were not on my radar.

48:52 At all.

48:52 Yeah.

48:53 Yeah.

48:53 Like the iframe one was not on my radar.

48:55 Yeah.

48:56 Me neither.

48:56 Right.

48:57 Yeah.

48:57 So very good project.

48:58 Yeah.

48:59 Cool.

48:59 All right.

48:59 Number eight.

49:00 Number eight.

49:00 So HTTPY is a very nice project.

49:04 So we're used to see when we look at tutorials, people use curl to show how to send a request on the command line.

49:13 And curl has a somewhat unfriendly structure, especially when you need to send API requests that have JSON.

49:22 JSON payload.

49:23 So what I've been using for the last few years is this Python project called HTTPY, HTTPIE.

49:32 And that is a much friendlier command line HTTP client for mostly for API use.

49:39 Yeah.

49:39 I love this package so much.

49:42 It's one of the first things I install in a new server.

49:44 It is so much better than curl.

49:47 I almost never install packages in the global Python.

49:52 I always create virtual environments.

49:54 But HTTPY is in my global Python because I always use it even if I'm not working in a Python project.

50:02 So I always want to have a copy of it readily available on my command line.

50:07 So, for example, if you need to send headers, there's a syntax where you just use header name, colon, and then the value after you put the URL.

50:15 If you want to send JSON variables instead of the colon, you use an equal sign.

50:20 And there's a number of shortcuts that you can use to create an HTTP request very easily.

50:27 And not only get requests.

50:29 You post and put and all the harder ones as well.

50:32 Yeah. So once you install this, probably in your semi-global namespace with a --user type of thing, then you have two commands on your terminal.

50:40 You have HTTP and HTTPS.

50:42 And then you just give it a URL or whatever.

50:45 It's really nice.

50:46 Right. It's actually the method and then the URL.

50:48 So you can say post and then the URL.

50:50 And then you add your headers and your variables and off you go.

50:53 Yeah. And one of the things I really love about this is the response is color coded like a code editor.

51:00 All right. So you get like syntax highlighting on your responses and on your headers, cookie values and everything.

51:06 It's great.

51:06 It's very nice. And I rarely use code anymore now.

51:09 Yeah. Same. Love it.

51:11 All right. Number nine.

51:12 I talked about these new frameworks coming along because Flask and Django and Pyramid and so on don't inherently support AsyncIO.

51:21 And a lot of them are growing to do that.

51:22 But a lot of people want to use AsyncIO with Flask.

51:27 I think you had Philip Jones on your podcast at some point to talk about this.

51:33 Yeah, absolutely.

51:34 He went and created from scratch a clone of all the Flask classes and methods within those classes.

51:43 So basically he created a full clone of all the Flask APIs.

51:47 And that project is called Quart.

51:50 Nice.

51:50 The difference with Flask is that it runs on AsyncIO.

51:53 So you can create Async view functions.

51:56 I believe at this point he has even added some support for some Flask extensions.

52:02 It's almost entirely compatible with the extension system as well, he said.

52:06 So I don't think it's 100%, but most of the common extensions will still work with Quart, which is pretty cool.

52:12 The common extensions that don't do any blocking work, then yeah, they will work on Quart.

52:19 So it's definitely something interesting.

52:21 He's actually involved in this effort that's starting to add AsyncIO support to Flask as well.

52:29 There's a pull request, a first pull request.

52:31 I don't recall if it was merged already, but it's close to be merged to add the first shy implementation of AsyncIO support within Flask.

52:42 He's involved with that effort.

52:44 Otherwise, if you want to have full support for AsyncIO today using a very familiar Flask and all the Flask features,

52:52 then Quart is actually a very good choice.

52:56 Yeah, it's a super good one.

52:57 All you have to do is replace the word Flask with Quart.

53:00 If it's lowercase Flask, it's lowercase Quart.

53:02 If it's uppercase Flask, it's uppercase Quart.

53:04 And then you have the API.

53:05 You do have to get the zen of AsyncIO and Async and await and all that, which is a different way of thinking,

53:13 but it's super awesome once you get it.

53:15 Yeah, very, very nice stuff.

53:17 I guess that'll just kick you down the path to go, okay, well, now I need to figure out how to do Async SQLAlchemy or Async Redis or Async FileIO.

53:26 Right.

53:26 I mean, it's like a, it's a layers of exploration to take full advantage of it, but it's very,

53:31 it's a very cool framework.

53:31 And I'd love to see it part of Flask just proper, not have these two projects.

53:35 It's going to take some time to redesign Flask to be fully AsyncIO compatible.

53:42 But yeah, the first steps are there and Quart for now is a great option.

53:47 If you really, this is interesting.

53:49 It used to be that you would think from the side of standard Python and AsyncIO will have

53:56 very few libraries that you could work with.

53:58 Now there are starting to be libraries that you want to use that only support AsyncIO.

54:04 You have a Flask application and you want to use some AsyncIO library.

54:09 So going to Quart will be a good option in that case.

54:13 And you talked about building kind of microservice-y type of things as well.

54:17 And in that world, you're waiting a lot on external systems.

54:20 And when you're mostly waiting on other things, AsyncIO is like, it's like pure magic, right?

54:25 It really shines.

54:25 Yes.

54:26 That is actually the use case.

54:27 The only one, if you ask me, that really makes sense because you can scale your little service,

54:34 tens of thousands of clients.

54:36 And since most of them are, you know, most of the time waiting, it can do that like nothing else.

54:42 It's really, really nice.

54:44 Yeah.

54:44 Super cool.

54:45 All right.

54:46 You have the last one, semi-last one.

54:49 Number 10 here is something in the same vein, but not the same.

54:53 Tell us about it.

54:53 So number 10 is, so let's say you like asynchronous programming.

54:59 You're not ready to go full-blown AsyncIO.

55:02 And you have a Flask application.

55:05 You want to take advantage of asynchronous programming.

55:08 What can you do?

55:09 What a lot of people seem to have forgotten is that there were many Async frameworks that existed from before AsyncIO.

55:18 And there are a couple of them that continue to be supported.

55:23 And they still run really well.

55:25 And Flask supports them, always supported them.

55:28 And the two that I have experience with are G-event and event-let.

55:34 And these frameworks are, they have a different philosophy compared to AsyncIO.

55:41 AsyncIO wants to make it very explicit that you are writing asynchronous code.

55:47 You even have new language keywords, Async await.

55:52 So both G-event and event-let look at this from a different side.

55:57 They try to make normal code that you're familiar with become asynchronous under the hood.

56:03 So you write the code in the way you've always done it.

56:06 And they implement or re-implement all the blocking functions in the Python standard library using asynchronous functions.

56:15 They use the same interfaces.

56:17 So these frameworks are intentionally supported by Flask.

56:21 So Flask recognizes if it's running under these frameworks.

56:25 Both are based on a package called Greenlet, which is the core technology that makes this possible.

56:31 It's a native code extension or plugin for Python that you install with pip.

56:36 And if you're running under Greenlets, then Flask makes everything work the same as if you were working with normal threads.

56:44 I personally have been using both G-event and event-let for many years on Flask applications with very little problem.

56:52 Cool. All right.

56:53 Well, that's one I didn't know about.

56:54 So that's very nice.

56:55 That's another option.

56:55 I bet it'll work great with Pyramid as well.

56:58 Yeah, probably.

56:59 You get a new implementation of sockets and threads and all those blocking functions in the standard library.

57:06 that are asynchronous.

57:07 And you call them in the same way.

57:09 Yeah, so it's way below the layer.

57:11 Yeah, like the framework wouldn't even know, right?

57:13 Right.

57:14 So you can use Flask.

57:15 You can use requests.

57:16 You know, all those libraries that do threading, networking, all those automatically become asynchronous by installing this library and using it as a server.

57:25 Very cool.

57:26 All right.

57:26 Well, that's the awesome one.

57:27 I'm going to look into that.

57:28 Now, that's our 10.

57:30 I wanted to throw just really quick and let you just riff on this one because I feel like this one is so in the wheelhouse of Flask.

57:36 And yet, I don't nearly see it spoken about enough.

57:39 Blueprints.

57:40 Blueprints.

57:41 That is a good point.

57:42 When you're building an API, you probably, if you're doing microservices, you probably use a full application for each service.

57:52 When you're building something a little bigger than that, than a microservice, you would like to structure your application in a way that's modular.

58:01 Right.

58:01 You don't want like a 3,000 line app.py file.

58:05 Right.

58:06 Probably.

58:06 Definitely don't want that.

58:07 I don't want one.

58:08 So, Flask has this concept of blueprints, which a lot of people think there's something very complex or magical or sophisticated.

58:19 And it's really a very simple idea, which is to partition the application in different modules or packages.

58:26 And you create a blueprint, which is like a mini application that then you plug into the Flask application.

58:34 So, you create all these application subsets, which can be a collection of routes, templates, and static files.

58:41 You build these bundles.

58:43 You call them blueprints.

58:45 Each one can be a module or a package.

58:47 And then those by themselves, they do nothing.

58:51 But at some point, when you create your Flask application, you can plug them into the application.

58:58 And then at that point, they become active.

59:01 And then you can get all of those working together to form the application.

59:06 That's pretty cool.

59:06 I really like it.

59:07 So, if you had like a site and you had, let's say, seven or eight view methods that had to do with account management, right?

59:14 You would have maybe have an account module.

59:16 And there you'd have your view methods.

59:17 And instead of trying to somehow reverse past the app itself that you've created, but then also bring that back into the app.py.

59:26 It's sort of circular.

59:27 You create the blueprint.

59:28 And then you put, say, at blueprint.route instead of app.route.

59:33 And otherwise, it's basically the same.

59:35 And then you've got a much nicer participant.

59:37 It's like an application.

59:38 Yeah.

59:39 Definitely, most applications that I build, they have at least two blueprints.

59:43 One that I call main, which is the core logic.

59:46 And then one that's called auth that performs all the authentication, right?

59:50 And one nice thing about working in this modular way is that if you wrote an auth blueprint, very likely you can take it from one project to the next.

01:00:01 Oh, yeah.

01:00:01 That's a good point.

01:00:02 You can make it into a Python package that you can install with pip.

01:00:04 Some extensions, some Flask extensions are actually blueprints.

01:00:08 I hadn't really thought about it that way.

01:00:09 That's cool.

01:00:10 Because then you just go from your package.blueprint.

01:00:13 You just go app.registerroute, the package.blueprint, and boom.

01:00:18 It's good.

01:00:18 That's a really interesting way to modulize it.

01:00:21 Yeah.

01:00:21 The one that I've used does this is Flask Bootstrap, which gives you access to some nice helpers to deal with the markup and the JavaScript required to do and the forms for the bootstrap framework for the client side.

01:00:34 And that's a blueprint.

01:00:37 So when you register the extension, the extension, the only thing it does is it registers the blueprint with your application.

01:00:42 So it plugs into your application and then off it goes.

01:00:45 So it's actually a nice way to develop extensions for Flask or your own reusable packages that you want to use in your own solutions.

01:00:55 So many uses for blueprints.

01:00:56 Very cool.

01:00:57 All right, Miguel.

01:00:58 We're pretty much out of time, I think, at this point.

01:01:00 So those were really, really interesting.

01:01:03 And I think people will get a lot out of those ideas.

01:01:06 I'm sure most people, at least one of those is new to them, right?

01:01:09 Hopefully one or two.

01:01:10 Yes.

01:01:11 Yeah.

01:01:11 Very cool.

01:01:12 I know there was one new to me.

01:01:13 Secure the Pi was new to me.

01:01:15 So I got something out of it, too.

01:01:17 Me as well.

01:01:18 Awesome.

01:01:19 All right.

01:01:19 So really quick, last two questions.

01:01:21 If you're going to write some Python code, what editor are you using these days?

01:01:25 I use three editors.

01:01:26 So I use PyCharm sometimes.

01:01:28 I use Visual Studio Code sometimes.

01:01:30 And I use Vim sometimes.

01:01:32 You have to pick one.

01:01:33 You have to pick one.

01:01:35 And this is also, I'm sure it's going to disappoint a lot of people.

01:01:38 I think my favorite is Vim.

01:01:41 Okay.

01:01:42 And the reason is that I work a lot on remote servers.

01:01:46 And it's really inconvenient to set up one of the larger IDEs to work remotely.

01:01:52 It's sort of an annoyance.

01:01:53 I just want to SSH into a box and then drop my config file for Vim.

01:01:58 And then it works exactly like it works locally.

01:02:01 And Vim is our learning curve.

01:02:04 But once you learn it, it's actually very efficient.

01:02:07 And it has Python plugins that give you some of the things that you get on the more elaborate IDEs.

01:02:15 So I have to think that Vim is my favorite.

01:02:17 Also, a lot of people...

01:02:19 Somebody made you choose.

01:02:20 Yeah.

01:02:20 Yeah.

01:02:20 A lot of people don't like that when I do my tutorials, my tutorial videos, I use Vim.

01:02:27 The reason why I use Vim there is not because I like it.

01:02:30 It's because I know that's the least likely editor that people following my tutorials will be using.

01:02:37 And I want to force them to think about how to translate what I do instead of just copying every keystroke that I make.

01:02:44 So I use the editor that I think it's the least likely to be known by my students.

01:02:51 Well, interesting philosophy.

01:02:53 So since you brought up Vim, I have a Vim joke for you.

01:02:55 Okay.

01:02:56 How do you generate a random string?

01:02:59 You get a first-year computer science student to open Vim, and then you ask them to quit.

01:03:04 To quit.

01:03:04 Yeah.

01:03:07 It's funny.

01:03:09 So I did two videos that are actually very popular, showing how to set up a Flask application with PyCharm.

01:03:16 And then I did another one with a VS Code.

01:03:18 I'm going to do the same with Vim.

01:03:21 Yeah, you should.

01:03:22 It's going to be very fun.

01:03:24 It's probably going to generate a lot of hate as well, but I'll take it.

01:03:28 Yeah.

01:03:28 Why are the comments disabled on YouTube for this one?

01:03:30 I don't know.

01:03:30 I think people will be surprised because, of course, the very first thing that I'm going to show is how to quit, of course.

01:03:38 But, you know, you don't have to learn a lot of things to be productive with Vim.

01:03:43 Yeah, very cool.

01:03:43 All right.

01:03:44 And the notable PyPI package?

01:03:45 This isn't a PYPI.

01:03:47 Tmux is a package that I use a lot with Python and, in general, when I work on the command line.

01:03:53 Okay.

01:03:54 What does it do?

01:03:54 It's a terminal multiplexer.

01:03:56 A lot of people ask me when they see my videos.

01:03:58 This is another one that I get very often.

01:04:01 They see me, you know, happily punching keystrokes.

01:04:04 And suddenly, the screen divides into two.

01:04:07 And I get two terminals instead of one.

01:04:09 People don't understand what happened.

01:04:11 And this is Tmux.

01:04:12 Tmux is a very nice package.

01:04:14 There are actually packages on PYPI that allow you to talk to Tmux and make it even more integrated into your Python workflows.

01:04:24 But the package is a native utility that you install with, you know, it comes with Ubuntu.

01:04:29 There are Ubuntu packages or on the Mac with Brew.

01:04:32 On Windows and Chromebooks, you can use.

01:04:34 It runs perfectly well on the Linux emulation systems.

01:04:37 And basically allows you to create multiple terminals in the physical space of one.

01:04:44 And one thing that is very nice, if you have it installed in a remote server, is that when you exit the server, those terminals remain.

01:04:52 When you SSH back into the server the next day, all the terminals are there exactly how you left them.

01:04:59 I see.

01:04:59 So whatever you're up to is still around.

01:05:01 It saves all the terminals.

01:05:02 Yes.

01:05:03 Yeah.

01:05:03 Very cool.

01:05:04 So that will be my nice package to mention.

01:05:06 Yeah.

01:05:06 That's a great one.

01:05:08 All right.

01:05:09 Final call to action.

01:05:09 People may have been working on Flask for a while.

01:05:11 They want to apply some of these tips.

01:05:13 What do you tell them?

01:05:14 Something that's very important to me.

01:05:16 I had a lot of great stories that were a result of me sharing, you know, when I started on my blog and then conferences.

01:05:25 Who knows when we're going to do conferences again.

01:05:27 So sharing is, I think, what helped me get to where I am.

01:05:32 Having a job that I love.

01:05:34 My recommendation would be that using these tips or all the tips that you get from other sources.

01:05:40 And when you come up with a solution, share it.

01:05:43 You may think that it's something that everybody else will, you know, could easily come up with.

01:05:50 All right.

01:05:50 They already know it.

01:05:51 I don't need to talk about this.

01:05:52 I don't need to talk about it.

01:05:53 Well, you actually do.

01:05:55 There's always going to be someone who's, you know, on the same path you are, but it's, you know, a few steps behind that will benefit.

01:06:04 And you will help them progress in the same way that you are making progress.

01:06:08 So you should definitely start writing a blog or videos or tweets, you know, however, in whichever way you are comfortable.

01:06:16 But start sharing.

01:06:18 And what's going to happen is that all that value of work that you're sharing over time is going to speak for yourself.

01:06:25 So you will not have to take so much effort in showing yourself to prospective employers or contracting user groups, conferences when you apply to a conference.

01:06:38 All of that thing that you produce a little bit at a time is going to speak for you.

01:06:44 And it's going to be your best advocate.

01:06:46 That's what worked for me.

01:06:47 So I think everyone should.

01:06:49 Yeah, definitely.

01:06:49 And I think also it's a great way to learn, even if you don't totally know, because people will say, why are you doing that?

01:06:53 Why don't you use this package?

01:06:54 Or you could actually do this other extension or like, well, the reason I didn't do that, I didn't know.

01:06:59 But now I know.

01:07:00 Right.

01:07:00 Thanks for telling me.

01:07:01 Right.

01:07:01 Next time I'll do something different.

01:07:02 Right.

01:07:03 So, yeah, it's great.

01:07:04 All right.

01:07:05 Really great to catch up with you.

01:07:06 Thanks for coming on and sharing all these tips.

01:07:08 I think people will find them very useful.

01:07:10 Thank you so much for having me.

01:07:11 Bye.

01:07:11 Bye.

01:07:12 Bye-bye.

01:07:12 This has been another episode of Talk Python to Me.

01:07:16 Our guest on this episode was Miguel Grinberg, and it's been brought to you by Sentry and Linode.

01:07:20 Take some stress out of your life.

01:07:23 Get notified immediately about errors in your web applications with Sentry.

01:07:27 Just visit talkpython.fm/sentry and get started for free.

01:07:32 Start your next Python project on Linode's state-of-the-art cloud service.

01:07:36 Just visit talkpython.fm/Linode, L-I-N-O-D-E.

01:07:41 You'll automatically get a $20 credit when you create a new account.

01:07:44 Want to level up your Python?

01:07:46 If you're just getting started, try my Python Jumpstart by Building 10 Apps course.

01:07:51 Or, if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python.

01:07:59 And, of course, if you're interested in more than one of these, be sure to check out our Everything Bundle.

01:08:04 It's like a subscription that never expires.

01:08:06 Be sure to subscribe to the show.

01:08:08 Open your favorite podcatcher and search for Python.

01:08:10 We should be right at the top.

01:08:11 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.

01:08:21 This is your host, Michael Kennedy.

01:08:23 Thanks so much for listening.

01:08:24 I really appreciate it.

01:08:25 Now get out there and write some Python code.

01:08:27 I'll see you next time.