00:00 When you think of Python web micro-frameworks, Flask is definitely near the top of the list.
00:04 With almost 19,000 stars on GitHub, it's a powerful and extensible web framework.
00:10 It even powers the bandwidth-intensive audio delivery of the Talk Python to Me podcast.
00:15 In this episode number 48, we'll talk with Miguel Grinberg, who has written some amazing
00:20 Flask tutorials, books, and open-source projects. This is episode number 48, recorded February 2nd, 2016.
00:28 Developers, developers, developers, developers.
00:32 I'm a developer in many senses of the word, because I make these applications, but I also
00:37 use these verbs to make this music. I construct it line by line, just like when I'm coding another
00:42 software design. In both cases, it's about design patterns. Anyone can get the job done. It's
00:48 the execution that matters. I have many interests.
00:51 Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
00:57 ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter,
01:01 where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm,
01:06 and follow the show on Twitter via at Talk Python. This episode is brought to you by Hired and SnapCI.
01:12 Thank them for supporting the show on Twitter via at Hired underscore HQ and at Snap underscore CI.
01:20 Hey everyone, I have a couple of news items before we get to Miguel. First, Miguel has generously
01:26 agreed to give away an e-book copy of his Flask web development book published by O'Reilly. To be
01:32 eligible, just become a friend of the show at talkpython.fm, and I'll randomly select a winner
01:37 during the week. It's been two weeks since the Kickstarter to launch my Python online training
01:42 adventure kicked off. I have a few updates you might be interested in. The project is funded and well
01:48 underway. The Kickstarter is over $14,000 and going strong. I launched a new website,
01:53 training.talkpython.fm. Check it out. You can see the next set of courses I'm working on after the
01:59 Kickstarter closes. Just click on courses in the nav bar. Once again, thanks to everyone who backed
02:05 the project so far. If you want to get access to my course, Python Jumpstart, by building 10 apps
02:09 for over half off at $29, hurry over to talkpython.fm/course and back the Kickstarter before it
02:17 closes in the next two weeks. Now, let's get on to an excellent conversation with Miguel.
02:22 Miguel, welcome to the show.
02:25 Thank you. Glad to be here.
02:27 You have a lot of stuff going on. This is going to be a fun conversation.
02:30 I hope so. I'll try to make it fun.
02:32 Yeah, yeah. We're going to focus this around Flask and look at all the different things you have going
02:37 on kind of in that space. Yeah?
02:39 Mm-hmm. Sounds good.
02:40 Okay, cool. Now, before we get into the details, let's talk about how you got started in programming
02:46 Python and all that stuff. What's your story?
02:48 Yeah. So, I first got into programming in the probably mid-80s, 1980s, with a TI-99 computer.
02:57 You can Google it, if you don't know what that is. But it used to be a very cool computer in the age
03:02 where, you know, computers were really new and most people didn't have them in their homes. And I
03:07 started writing games in BASIC on a TI-99 computer. Eventually, that seemed slow, so I decided to learn
03:15 the second language you can program on that machine. There were only two, and that was assembly language.
03:20 And I started writing games in assembly.
03:22 My gosh. So, you took, like, a real easy sort of gentle introduction to game programming, yeah?
03:27 Yeah. Those were the two steps you had on, you know, on the TI machine.
03:32 That is a big step.
03:33 Right? There was no other thing. And BASIC was slow, so, you know, what was the other choice,
03:38 right? If you needed speed, assembly was the answer. So, yeah, I wrote a Tron lifecycle game
03:45 on assembly language on a TI-99 computer.
03:48 That's cool. Did you release it?
03:50 I released it to friends only back in that day. So, yeah, not commercially.
03:56 Yeah, I mean, that basically predates the web, right? So, what do you release it to in some
04:00 sense? BBSs maybe, right?
04:01 Right. There were BBSs in those days, right?
04:04 Yeah.
04:04 Yeah.
04:05 That may be aging us.
04:06 Yeah.
04:06 I think I can still tell the actual connection speed based on the sound the modem made when
04:12 it connected.
04:12 Right.
04:15 Yeah, that was...
04:16 Yeah. So, my first board speed, the BBS speed was 1200.
04:20 Oh, yeah.
04:21 You can put an age to me, you know, by knowing that, right?
04:25 Yeah, I'm just a little younger. I came in at the 9,600 days.
04:28 Yeah, I'm old.
04:29 Okay. So, you got into BASIC and then assembly, and then where'd it go from there?
04:36 So, and then, so this was, I was a teenager, so before college. So, then in college, I learned,
04:43 you know, the languages that you normally learn in college, at least in those days, Pascal,
04:48 C, C++, Smalltalk, basically get a job. So, I'm from Argentina, and one of the things that's
04:54 great about college in Argentina is that you can do it at night and work full-time while you
04:59 study. So, I was lucky to have found a job, a programming job, you know, from the early days
05:05 in my college time. I had basically both sides, the academic side and the, you know, having to do
05:12 something production-wise, having to get something that works and that makes money all at the same
05:17 time. So, it was pretty good.
05:18 Yeah, that's a really cool opportunity to have a chance to write, like, professional code or
05:23 whatever you want to think of it as a student, because a lot of people come out of college
05:26 and they're like, now let me have, try to go find some experience so I can get a job,
05:31 right? Which is, it's a kind of tough place to be.
05:33 Right. So, thanks to the TI-99, I had some experience. I could get a job without having a
05:39 college degree. So, you know, I basically, those two complemented and, you know, allowed me to
05:45 have a, you know, a full experience from early on in my life. So, then Python came much, much later.
05:52 Maybe eight, nine years ago, I was working at a company where we had a really large C++ code base
05:59 that was really painful to test. This code base was exposed as a DLL, a C++ API on Windows. So,
06:07 I decided to create a Python wrapper so that the testers could write tests more efficiently.
06:13 Right. They didn't have to write it in C++ and all that stuff. Yeah.
06:17 Exactly. Right. And compile it and test it and crash and then do it all over again. Right. So,
06:22 I decided to create a, the Python wrapper and basically I got hooked. I really liked it. So,
06:28 it started from there.
06:29 Interesting. So, you're working in C++ and you made these wrappers and I guess the thought process
06:34 went something like, why don't I just keep working over here? Why do I have to go back to those
06:37 compilers and headers and libs and all that stuff, right?
06:40 Right. So, exactly. And in the same way, I studied and worked at the same time when I'm working,
06:47 even now, I always have lots of side projects that I do just for fun. So, at those times,
06:53 you know, eight, nine years ago, doing stuff on the web seemed to be the right thing.
06:57 Yeah. Excellent.
06:58 Okay. So, what can I do with Python for the web? You know, that led to, well, you guessed it, Flask.
07:05 Yeah. So, you have a lot going on with Flask. Why did you pick Flask over the other options? And,
07:09 you know, given the timing, it might've been, well, there were not many other choices,
07:12 but Django was probably around at that point, yeah?
07:14 Django was there. Bottle was there, believe it or not. I did look at Bottle at the time. So,
07:20 basically, this was a, this is a funny story. I started, it was sort of a friendly competition
07:25 with my wife. My wife, who is not a technical person, she was blogging and she was having,
07:31 you know, pretty good success with her blog. And she was always teasing me that she was doing
07:35 something technical and I was behind. I had to basically start blogging. Basically, that was
07:40 the dare that she put in front of me. So, I said, if I'm going to blog, I'm going to blog on my terms.
07:45 So, I had to write my blog engine.
07:47 Of course.
07:48 Right? I'm not going to use WordPress or, you know, one of those.
07:52 No, no, no. That has PHP in it.
07:54 Exactly. Right. So, I went and looked at Django and Django seemed overkill for a little blog
07:59 that I wanted to write. I looked at Bottle and Bottle seemed too little. Right? I think that
08:04 there were some things like writing more than one file. It wasn't clear how you would do it. You
08:08 will have to start inventing things. So, I settled with Flask. You know, Flask was right in the middle
08:13 and it seemed like the right balance.
08:15 Yeah. I think, you know, I think finding that balance sort of depends on your experience,
08:20 how you like to code, how much hand-holding you like it in some sense. Right? Absolutely.
08:26 I personally love to write my HTML just so and my CSS and have lots of control over the
08:32 URLs and everything. And so, these micro frameworks like Flask and Pyramid, I'm a huge fan of.
08:38 Yes. I completely agree with that. With that, I micromanage my code. I really like to write
08:44 myself and be aware of everything that's going on, make it very clear and make it very me. Yeah.
08:49 Flask seemed to be the right balance of not having to deal with all the pain of HTTP requests
08:55 and responses. And, you know, Flask abstracts you from dealing with that. But at the same time,
09:01 it doesn't hand-hold me and I can do what I want, which is, you know, it was a requirement for me.
09:06 You know, we had Armin Ronecker on show, I think it was 13, one of the earlier shows and sort of dug
09:13 down into a lot of the pieces of Flask. But maybe, you know, that's a long time ago. Maybe you could give
09:18 people like a high-level look at just what the moving parts of Flask are and kind of like how
09:22 you, how much work is it to get a website up and running? Right. There isn't really much. So,
09:28 Flask is very small. You can go read the code and you will probably understand most of it,
09:32 you know, in your first read. It's, you know, super clear code. It's code that I could write,
09:37 the kind of code that I wish I could write, actually, because it's so clear. And basically,
09:42 the main thing that Flask does for you is to abstract you from the interface with a web server.
09:48 You don't have to think about parsing HTTP requests or formatting the responses. Basically,
09:55 you get a decorator that allows you to associate a function that you have to write with an HTTP request.
10:02 That's basically pretty much, you know, the big thing that Flask has for, you know, for web development.
10:09 And then you write your application. You supposedly need to know how to write it.
10:14 Right. Sure. So, I'm trying to remember, like, the Hello World app on Flask is probably five,
10:19 eight lines?
10:20 I think it's, yeah, seven lines, if I remember correctly.
10:23 Seven lines, yeah. At least I got the interval right.
10:25 Yes. So, you have seven lines, four of which are boilerplate. So, your Flask, your typical Flask
10:32 boilerplate is four lines, four lines of code. And then you write your functions. You write typically
10:37 one per HTTP endpoint that you want to support. And in the function, you do any processing you need to
10:44 do and then return your response, which usually is, I mean, if you're doing a web application,
10:50 it's a string containing HTML that you can generate yourself or through a template engine.
10:55 Right. And the default is Jinja 2, right?
10:58 Jinja 2 comes with Flask. It doesn't need to, really. You can use any template you want. And
11:04 this is a theme with Flask. For any X feature, you can use any package that does X. Flask really
11:12 doesn't care much about the stack that you use. So, yes, Jinja comes integrated. There's a very
11:19 light integration. And that helps you with generating the HTML. So, you write your HTML in files and put
11:26 placeholders for the dynamic components. And then you generate those, you know, dynamic parts in your
11:31 function logic.
11:32 Right. And do you pass just like a dictionary off to the...
11:35 Correct. Yes. And then Jinja 2, that's the replacement.
11:38 Yeah. And then the view engine will put it together, right?
11:41 Yeah.
11:41 Exactly.
11:42 So, really, for a beginner, I mean, being able to get, you know, the Hello World thing with seven
11:47 lines and then start hacking it and make it do more things, most beginners can get it right away,
11:52 which is fantastic, right?
11:54 Yeah, it is quite easy. I'm also a fan of Pyramid. I like Pyramid a lot, but that step from zero to
12:01 kind of, I've got something I'm ready to start working with is much bigger than it is in Flask.
12:07 I think to a large degree because of the packaging, you've got to kind of deploy or set up your website
12:12 as a package.
12:13 Right. Honestly, I see Pyramid more closer to Django than to Flask.
12:20 Yeah. Yeah. I agree. I think Flask is much smaller, but I think one of the sort of superpowers of Flask is
12:27 it's super small, but there's so many things you can plug into it, including a number of your open
12:33 source projects, right?
12:34 Yes. I have written a number of things that you can add to Flask, which are all optional. And that's a
12:41 big thing, right? In Flask, as I said before, you pick your components. So, yes, I've written stuff to
12:47 do WebSockets in Flask. That's actually the one that my most popular extension so that you can do
12:52 WebSocket and does it in a way that is very Flask friendly, not the typical WebSocket thing that you
12:59 see. But basically, the WebSocket connection is represented by a function that runs forever,
13:04 or at least through the life of the connection. And in this extension that I built, you handle events.
13:11 And these are short events that are built on top of the Socket.io protocol.
13:16 Yeah. Okay. Very cool.
13:18 So, it has a good side and a bad side. The good side is that, you know, if you're familiar with
13:22 HTTP routes, it's very easy for you to start doing WebSocket because with this extension,
13:28 you do it more or less in the same way. The bad side is that, you know, they're not the same. So,
13:32 a lot of people get confused about, I mean, that they think that they can do whatever they can do
13:36 with HTTP requests. And the fact that the extension makes it simple doesn't mean that,
13:42 you know, you do have a request context, which you don't when you're doing WebSockets, right?
13:47 Yeah. Right. Interesting. So, that is something I wanted to ask you about while we're still down
13:51 in the details of Flask and so on. And frameworks like Pyramid, they will pass a request object that
13:58 has the request, the response, the headers, all that kind of stuff into your view methods. Or if
14:02 you're using Pyramid handlers, it'll pass it to your class and you store it for later. Those kinds
14:06 of things. Flask doesn't do that. It uses these sort of contexts that are ambient to your code. And
14:13 those are really cool. Can you talk about that a bit? Maybe how that works?
14:16 I can. So, this is possibly the only aspect of Flask that can be thought of somewhat magical.
14:23 It's only magical because a lot of people don't understand it. Once you understand it, of course,
14:27 there's no magic. But yes, the idea is that if Flask didn't do what it does with the request objects
14:33 and, you know, other variables that are request specific, you will have, for each of your handler
14:40 functions, you will have to receive a bunch of arguments. The request, and then you need
14:46 to return the response, but you may need the session, and sometimes you don't need them. So,
14:51 the way Flask handles that is that it makes those available as context variables. They're present
14:57 in every request. You don't get them as argument. You see them as global variables. And I said they're
15:03 magical because even though they look like global variables, they're not. They're really thread-specific
15:09 global variables. So, if you have a production web server running multiple threads, each thread will see,
15:15 look at this, for example, the request global variable, and it will see a different one. It
15:19 will see the one that applies to that thread. That's a little bit magic that a lot of people
15:24 get confused about. But other than that, basically, you know that when you get into a request handler,
15:29 you have access to the request as a variable called request. You have the session as a variable
15:35 called session. There's a couple more. And then extensions can add more things using the same
15:41 idea. So, for example, if you use Flask...
15:43 Do they maybe just pile on top of the same pieces?
15:46 Yes. They use the same...
15:48 Like the shared global context?
15:50 Correct. So, for example, Flask Login, which is an extension to do authentication,
15:54 has a current user. So, you know, that's always there if you are in a request. I think it's a very
16:00 clean way to have those things out of the way if you don't need them and then handy when you do.
16:05 I really like that.
16:06 Yeah.
16:07 I enjoy, you know, not having those as arguments in my functions.
16:10 Yeah. It's definitely nice and clean. Yeah. That's cool. So, let's take a moment and talk
16:15 about your blog. So, you said it starts by you writing your own blog engine because you're not
16:20 going to be ruled by one of these pre-built ones, right?
16:24 Correct. Yeah. That's not my way. So, I wrote the engine and, you know, okay, so I'm done. I have a
16:31 blog now and my wife was still saying, well, you're not blogging. So, I had to start writing.
16:37 There's no... It doesn't matter if it runs. There has to be a post on it, right?
16:40 Right. So, right there with all the Flask experience of building the blog in my mind,
16:46 what made more sense was to blog about Flask. So, I started writing articles about writing,
16:51 you know, a complete application, you know, using Flask and that was how this mega tutorial was born.
16:59 This is a 17-part, very detailed Flask tutorial. It's starting to age a little bit. It's been written...
17:07 I started maybe four years ago and I wrote it during a period of a year and a half.
17:12 So, yeah, that basically covers a bunch of areas. For example, I'm really proud that I have very good
17:19 coverage for internationalization. Not very many people talk about, so you can learn how to do that
17:25 with Flask. Ajax, which is more common now with single-page apps. That was basically a source of
17:32 not only a way to teach what I learned, but also to, I mean, for myself to learn, because it pushed me to
17:38 learn more things, right? I wanted to do something more... I didn't want it to look as a Flask beginner,
17:44 which I was at the time.
17:45 Yeah, that's so true. At the time, but then you go through teaching this stuff and like, well, if I'm going to talk
17:51 about this, I got to know all the little details. And maybe if you were going to write an app,
17:55 you might only learn just enough to get the app working. But if you're going to try to teach it,
18:00 you got to dig deeper.
18:01 Exactly. I always say that teaching is the best way to learn.
18:04 Yeah, it absolutely is. It absolutely is.
18:06 I learn by teaching.
18:07 Yeah, I think one of the ways that I think of it, sort of conceptualize it, is if you were,
18:12 say, a consultant and you went to work at a place and they say, you need to solve this problem.
18:16 If you know one way to solve that problem, that's probably good enough, right? You're ready for
18:21 your job. But if you're going to go teach other people and there happens to be three ways to solve
18:26 it, not only do you need to know the three ways, you need to know when to use which, what are the
18:30 trade-offs, all that. Those are the kind of details you would just not bother with unless you have to
18:34 teach it. So that's great.
18:35 Yeah, correct.
18:36 This episode is brought to you by Hired. Hired is a two-sided curated marketplace that connects
18:52 the world's knowledge workers to the best opportunities. Each offer you receive has
18:56 salary and equity presented right up front and you can view the offers to accept or reject them before
19:01 you even talk to the company. Typically, candidates receive five or more offers within the first week
19:06 and there are no obligations ever. Sounds awesome, doesn't it? Well, did I mention the signing bonus?
19:11 Everyone who accepts a job from Hired gets a $1,000 signing bonus. And as Talk Python listeners,
19:16 it gets way sweeter. Use the link Hired.com slash Talk Python to me and Hired will double the signing
19:22 bonus to $2,000. Opportunity is knocking. Visit Hired.com slash Talk Python to me and answer the call.
19:29 At the time at work, still in the C++ domain, we were starting to do some things with REST APIs.
19:41 I also got an interest sort of in parallel when I got tired of writing mega tutorial articles.
19:46 I will take a vacation from that and write about REST.
19:49 Right. So you basically have two really large areas on your blog. And one is this Flask mega
19:55 tutorial? And that'd be a good place for if my listeners are out there and like, hey, I'm getting
19:59 into Python. Maybe web apps are cool. Maybe Flask is cool. How should I get started? Your tutorial is a
20:04 good place?
20:04 I think it's a good place. There are warnings in the proper places in the tutorial where things
20:09 got a little bit out of date. I'm going to give you just one example. Back then, I thought using
20:14 OpenID for authentication was a cool idea. So OAuth wasn't that...
20:19 We were told OpenID was cool. We were told.
20:22 Yes, we were told. And it looked...
20:24 It was cool.
20:25 I went with that. And of course, today, it's kind of an old thing.
20:29 Yeah, that's right.
20:30 One day, I'm probably going to go refresh that portion of the article, that chapter. But yeah,
20:35 right now, you can still implement it. But of course, if you're doing anything for real,
20:39 you will not do what I did back then.
20:41 Sure. You could say... You can log with OpenID and your users would say, what's OpenID?
20:45 Exactly. Right. I mean, probably there's one or two providers that still support it. And
20:50 it's decreasing very quickly. So yeah.
20:53 Okay, cool. So the Flask tutorial sounds great. And then the other thing you focused on a lot
20:58 was REST APIs. Yeah?
21:01 Yeah. This was mind-blowing when I learned about REST. It seemed great. And I said, well, why
21:09 didn't I think of this? It seemed like a very clear way to organize and do the separation
21:14 of concerns between the client and the server and write more richer client applications. I
21:19 really made an effort to learn. If you go Google REST, you're going to find there's a lot of
21:24 discussions about what's RESTful, what's not RESTful, people who are very angry at others because
21:31 they're calling something REST and they think it's not.
21:35 So let me see if I got it right. If I have a service, like a website and it returns something,
21:40 so if it returns like JSON over HTTP, it's a REST service, right?
21:44 Wrong.
21:46 Just kidding.
21:47 Oh, you're teasing.
21:49 I'm going to start some kind of Rastafarian war.
21:52 Yeah, don't worry.
21:54 So the REST ideas are great, but even if you go read the paper by Roy Fielding, it seems like he's
22:02 saying simple things, but hidden behind those very sparse words, there are very complex ideas
22:09 that you really have to think and make sure you understand. I did try to get to the bottom of it.
22:15 I'm really not one of the angry people who think that you should call REST things that are 100% pure REST.
22:23 I think REST has ideas that are very good. Even if you implement some of them, you're still winning.
22:28 And I'm not going to complain if you call it REST, right? Because everybody does.
22:32 Yeah, absolutely. I think that REST as a black and white concept was much stronger several years ago.
22:39 And now people see it as a spectrum and they're like, you know, let's adopt HTTP, JSON sort of APIs
22:47 so we can talk to both iPhones, web apps, and other... It's almost a practical drive to adopt something like REST.
22:56 Yeah, I think that it's a collection of ideas and some ideas are very easy to grasp and, you know,
23:02 almost everybody say, yeah, this is great. The idea of having resources, right? Everybody gets that.
23:07 And how to use get post, put, and delete, that makes perfect sense. So almost everybody get that.
23:13 But if you start thinking about hypermedia, for example, which I think it has only five or six
23:19 words in the original paper by fielding, it's like it's mentioned in passing, right? I mean,
23:26 not everybody or almost nobody get what you gain by implementing hypermedia. And for many projects,
23:33 it doesn't make sense. Right. But for some, it does. So I wanted to understand it, even if I don't always
23:39 agree that it is a good idea, I wanted to understand what it meant and what you could do. And I even did
23:45 a one of my PyCon talks, the one I did last year, I showed, you know, a fully implemented hypermedia enabled
23:52 REST API, which was a pretty fun project to do. Another way that forced me to learn something,
23:59 you know, to keep learning. I had to implement that in a way that the few hundred people that
24:03 were there and then the people who watch it on YouTube won't put my fingers at me saying,
24:08 yeah, that's wrong.
24:08 Yeah, that's cool. And I have seen that talk. That was, that was a good one. And the title is,
24:13 "Is your REST API RESTful?" which I think is a clever title, right?
24:18 Right. Right. Yeah. I mean, it plays on this continuously ongoing discussion between the
24:23 people who want your REST to be called REST and, you know, the people who say, "Well, okay,
24:28 it's a REST API," whatever, right? I didn't implement all the items in the list, but still REST.
24:34 Yeah. So one of the principles of REST is to sort of embrace the HTTP-ness of the transport, right?
24:42 Like you said, use the verbs and the URIs and all those kinds of things, right?
24:46 This is very interesting because if you go read the paper that, you know, the fielding paper,
24:52 he almost briefly mentions HTTP and the message there is that you could implement REST over
25:00 other transports. So if you go by that document, there's nothing that says that you should use
25:06 GET requests for this or that or POST requests because that's HTTP specific. When you go and implement
25:13 REST, you're supposed to map the ideas of REST into the transport that you're using. So, you know,
25:19 all these rules that say that you should use... I think part of the reason that HTTP gets so tied
25:25 up with REST is it's the only practical choice for a broad reach on the internet. That's correct. So,
25:32 to my knowledge, nobody is doing REST over something that is not HTTP. I'm sort of a little bit disappointed
25:40 that fielding or one of his colleagues didn't write something more specific to HTTP because I think
25:48 that's the source of all the confusion. It's that mapping, how you map what fielding said in that
25:55 original paper to the HTTP protocol, which allows you to do the same thing in many different ways
26:00 ways in a lot of cases. Right. So... Yeah, it's unfortunate. I think you even mentioned this in
26:06 your talk that there's not like a reference implementation client server that you could go
26:10 look at, right? Right. And there is one because really it's very difficult to make something that
26:16 complies with every little thing that is mentioned in the original REST documentation. And some things,
26:22 you have to do the mapping, right? So they're not clearly specified so that you can find out how to
26:27 implement that with HTTP. So yeah, it's very interesting how the technology developed around
26:32 it. And I think REST took off because at least some parts of it, as I said before, are very easy to grasp,
26:39 and they're very powerful. Right. And if you look at the alternatives, they were like XML soap
26:44 web services with WS star specifications, making it even more complicated and all that kind of stuff, right?
26:50 Right. It's like, yeah, I mean, you have boilerplate and you need to learn a lot of things. I mean,
26:55 it's the same thing that goes on with FLASC. FLASC, you can pick up really quick and REST,
27:00 at least a portion of it, you can pick up really quick too.
27:02 Yeah, I think REST is one of those things you can pick up quickly, but it takes a long time to master.
27:07 Yes. If you wanted to get all the advantages of REST, definitely it takes a long time. I hope I did a
27:13 good job on that talk because I really tried to explain in a very simple language what each of the six
27:19 up characteristics of REST mean and how they benefit you.
27:23 I was still waiting for a picture on stateless.
27:24 Yes.
27:25 Because you had pictures with it, you're like, this one I can't do in a picture, it's stateless. What
27:29 does that look like?
27:30 I started with the idea of making pictures for everything, but yeah, no. It would have been pretty
27:37 hard to do stateless. Yeah.
27:38 Yeah, well, I didn't have an idea. But yeah, the ones that I did pictures, I think the pictures in
27:43 some of them, they do help drive the point home. I mean, especially caching and those things you
27:48 normally don't think about. Yeah.
27:50 And they are kind of important. I think they're important, especially if you're doing something
27:53 big, right? If you're doing a REST API for controlling your garage door on a Raspberry Pi,
28:00 you probably don't care about caching. Yeah.
28:04 But if you're getting paid to do a REST API, you should probably care about it.
28:08 Yeah, you definitely should. So all of these posts and articles sort of led you to your next
28:14 endeavor, which was your book, right? So you wrote all these articles and O'Reilly reached out to you
28:19 and said, "Hey, that stuff's cool. You want to write a book?" That's actually pretty much how it went. Yeah. This editor from O'Reilly, she was basically looking
28:29 for Python content and she ended up on my blog at the time. At some point, she came to Portland for
28:37 a conference and we met. And basically after that meeting, yeah, she said, "Well, send a proposal.
28:43 We really like to have a book on Flask." And it-
28:46 Nice. Yeah. And I looked through it so much. I haven't made it all the way through, but I really
28:52 like it. I think it has a really nice practical style. It's not too verbose. It doesn't go into too
28:58 many details, but it doesn't feel like you're skipping over so much. I think it's a really
29:02 nice book. Do you maybe want to kind of talk about the theme? And you have this one kind of
29:06 major app that you build up throughout this book, right? Yeah. So it's probably a typical
29:11 book for learning a framework. I decided to write it in a kind of a tutorial way. Basically,
29:20 each chapter builds on the previous one. And by the end of the book, you have a complete application,
29:25 which is sort of a Twitter kind of clone. I decided to do it that way because people learn,
29:32 in my experience, it's easier to learn, you know, gradually. And if each chapter starts with a new
29:40 project, you have, you know, you lose your context. So you have to sort of start over.
29:46 Doing it that way also allowed me to do something that I think it's also very original, which is how I
29:51 have the code for the book on GitHub. And people tell me I'm crazy because it's a lot of work. But
29:58 basically, what I did is I engineered the history. I mean, using get rebases, I engineered the history of
30:05 the repository to be, you know, one commit per hit point, basically, there are a few in each chapter. But
30:13 each time you reach a point where you can go test something, there's a commit there. If I need to make
30:18 a fix, I need to insert it in the right place in the history. So it's I developed a few tools to help me
30:24 with that so that I don't make mistakes. Right? Because it's crazy. I agree. I'm kind of crazy.
30:29 Well, it's really cool from a reader perspective. So basically, you start out the book saying,
30:35 look, you need to know get welcome to the 21st century. And you're a programmer. So you got to
30:39 know get. And here's how you get the code, right? You check this out, the you check out the repository,
30:45 but then you go to tags, right, that are basically save points. Correct. Yeah. So you have spread
30:51 through the book. At any point where you are ready to try something, it tells you, okay, now you will get
30:55 commit tag seven a, you know, they're named with the chapter number and then a letter. And so you get
31:02 that. And if you want to see what changed from the previous tag, you can do a diff, which is awesome.
31:08 Even on the GitHub website, you can diff one commit and see exactly that these are pretty small incremental
31:15 changes. So if you want to find out how I did authentication, for example, you find the commit
31:20 that does it and diff it against the previous one. And you see all the changes, not just, you know,
31:25 the big stuff, every little thing, including template changes, every little detail is there. So if you
31:31 want to learn with a lot of detail, what you need to do to add that feature, you can find it in the diff.
31:36 Yeah, I think it's a really, really nice way to do it instead of having a zip file with,
31:40 you know, chapter one, chapter two, chapter three in it, right?
31:43 Right. I started that way. And it seemed wrong. Right. And it's also difficult to maintain. So,
31:48 yeah. So, you know, overall, I mean, people criticize the book. Some people did so far in
31:53 the almost two years it's been out. Nobody criticized the the Git organization, right? The repository with
32:00 the code. Interesting. That, you know, it's almost unanimous. You know, people like it. They seem to like
32:05 it a lot. Yeah, yeah, that's really cool. And so, you know, as far as I made it, I really like the book.
32:09 It's tough to do stuff in public, out on the internet and other places like it. You can't
32:13 please everybody. So you just do the best you can. Right. Yeah, exactly. I mean, it's obviously
32:17 it's going to resonate with some people and it's not going to with some others. And that's fine. Right.
32:23 And these days, I mean, back in those days, this was the only book. But now it's not the only book.
32:28 There are like five or six or seven. So there's plenty of choice. It's a great ecosystem.
32:34 Yeah, it is a great ecosystem. Yeah. And like I was saying, I think that's some of the power of
32:38 a flask itself. It's kind of mirrored in the books. So your work on your blog led to your book. Your
32:43 work on your book led to some videos that you did. Right. So these as these things go, you do some
32:49 minor thing and it just snowballs over time if you keep at it in ways you don't expect, maybe. Right.
32:54 Yeah. In ways I did not expect. That's actually true. The book went out, did really well. So O'Reilly
32:58 was super happy with it. And they asked me to do webcasts, which I did a couple. But then I said,
33:05 well, maybe, you know, we should do more flask content. So they asked me to think about if I
33:10 wanted to do a video tutorial, basically a video version of the book. And that didn't seem right to
33:16 me. Right. Repeat the thing. I mean, I don't know. I was kind of like, I wrote it down. Why do I need
33:22 to do this? Yeah. I mean, it's kind of actually boring for me. Right. To do it all over again,
33:27 you know, in a video. Yeah. Sure. Instead, I decided to think about what else could I do in
33:32 video format. So one thing that some people found the book was too easy and some people found that the
33:38 book was too hard. Right. Both sets of people were right. Right. Because each is the same person.
33:43 It's a relative statement. That's right. Right. I decided to write a introductory flask course on video,
33:49 which started at a much lower. So the book is kind of for intermediate. You need to know your way in
33:55 Python to really take advantage of it. So this is much more basic. And the being on video, my screen,
34:04 you can see my screen as I do the exercises. For a lot of people that visual beginners find the visual
34:10 component very inviting. Right. That's how they avoid messing up. If they're reading it from a book,
34:15 Yeah. They don't see my terminal. They don't know what I type. So seeing, you know, the very basic steps
34:21 to build a web application being played in front of them. I thought it was a good idea. Yeah. I think
34:26 these video tutorials where you're doing screen sharing and especially when people are new, they can
34:31 watch. I think it's really, I feel almost like, you know, the blood pressure goes down, the stress goes
34:37 down. It's just like this thing that seemed hard. I saw, I saw that guy build it up and I saw all the
34:44 steps. None of them were hard. None of them were confusing. Exactly. Started from here, went to there,
34:49 and I can do that. Why did I think this was hard? But of course, if you're like running through the
34:53 docs and you don't know where to start, it's a whole different type of thing. So that sounds really cool,
34:57 really helpful.
34:59 SnapCI is a continuous delivery tool from ThoughtWorks that lets you reliably test and deploy your code
35:17 through multi-stage pipelines in the cloud without the hassle of managing hardware. Automate and visualize
35:23 your deployments with ease and make pushing to production an effortless item on your to-do list.
35:28 Snap also supports Docker and M browser debugging, and they integrate with AWS and Heroku. Thanks
35:35 SnapCI for sponsoring this episode by trying them with no obligation for 30 days by going to snap.ci/talkpython.
35:51 So that was video one? That was video one. Complete beginner with only a little experience in Python.
35:56 You will do that. That will give you the basis. You will know how to write simple applications with
36:01 Flask, and then you can go to the book. Hopefully at that time the book will make sense if it didn't before.
36:06 And then the second video that I did was specifically on REST APIs. And this is because when I was writing
36:12 the book, I was in a constant fight with my O'Reilly friendly fight, I should say. She's awesome. But a constant
36:19 fight regarding page count. They wanted a relatively small-ish book. And I tend to put a lot of detail. I
36:27 want to make sure things are clear, so I write a lot. So one of the things that suffered in the book was the
36:34 chapter on REST APIs. It's much smaller than I thought it should be. So I decided to expand on that on the video.
36:40 And because I wanted it also to be fun for me, that video has also APIs for Raspberry Pi. So I have my
36:48 Pi on screen showing you cool stuff you can do with the camera. It was a blast to do it. I enjoyed it very much.
36:55 Oh, that's really cool. Yeah. It's tough when you're starting out, or you're teaching people who are
37:00 starting out, to make something that's interesting and engaging. And so if you can do things like that,
37:05 like grab the Raspberry Pi and show how you're controlling the camera. And even though the code
37:09 might not be super complex, it feels like you're learning more than just a loop or a print statement or something.
37:14 Right. You bring up a good point. I don't think that video is for advanced users. It's probably
37:20 still in the intermediate level, but it is dedicated to REST APIs. I think that there's a lot more to say
37:27 about APIs than what you get from the book. So it was a good thing. And being able to show how to
37:32 implement APIs on devices like the Raspberry Pi, I think that was great. And that will be something
37:38 more difficult to do in book format, I think. I mean, especially playing with the camera. I was in part of the
37:43 video. I show how to do a time lapse. There's an API to trigger a time lapse. So I have the camera
37:48 pointed at myself doing the class, doing the course. And then I play the time lapse. It's pretty cool.
37:57 It was really fun. Yeah. Really nice. Really nice. So we have time for a few more questions. One thing I
38:04 did want to talk to you about while we were together is your open source projects. But I kind of feel like
38:11 maybe the way to do it is to give people a sense of what you've done, what's out there,
38:14 and maybe some other time we'll come talk in depth about them. Yeah. So I'll tell, I'll say,
38:20 I'll say one of your projects and you give me like the elevator pitch one to two sentences. Like,
38:24 what is this? How's that work? Sounds good. All right. Flask Socket IO. I briefly mentioned
38:29 that before. It allows you to do WebSocket applications with Flask. It makes it super easy. Right. That's the,
38:36 the continuously running function with events. Correct. Great. And then Flask Migrate.
38:39 Flask Migrate allows you to do database migrations using Alembic, which is the migration engine for
38:46 SQLAlchemy. So this extension makes it very, very easy to implement migrations in Flask. Okay.
38:52 Interesting. I'll have to check that out. Flask HTTP auth. For REST APIs to do authentication.
38:58 Again, decorator based. Like OAuth, that kind of stuff? This is not OAuth. This is a basic and digest
39:03 authentication for an API. So if you're doing a straight API, say you don't have a web application,
39:09 so you cannot do OAuth, which requires the web so that the user logs in. So you implement token-based
39:15 authentication, for example. This will give you decorators that basically prevent you from having
39:21 to deal with the headers 100%. So you can do everything in Python land. Right. You could deal with
39:26 with them yourself, but why would you want to, right? Exactly. Yeah, exactly. Yeah. Python Socket.io.
39:32 Python Socket.io is one of my two non-Flask specific projects. This is the engine to Flask Socket.io,
39:39 the one that I mentioned before. So Python Socket.io is a general purpose Socket.io server. So you can do
39:45 socket applications for any framework or just a plain, you know, no framework, just the Socket.io server.
39:53 Since we're talking about it, I would like to invite anyone who wishes to write a wrapper for
39:58 other frameworks. I maintain the one for Flask. But if there are any, anyone interesting in supporting
40:05 Python Socket.io in Django, Pyramid, Bottle, whatever else, I would be more than happy to help. I see. So
40:11 so that would be the core. That's the core, correct. That you would use to build that and not have to
40:16 basically maintain it. Yeah. Yeah. It has no relation with Flask. Yeah. Okay. Awesome. It's
40:20 Python pure framework. Sure. Okay. Flask Moment. Oh, Flask Moment. Flask Moment allows you to use Moment.js
40:28 on the client to render. For example, you can do this very cool three seconds ago, three minutes ago,
40:36 timestamps that are very friendly. With this extension, you can implement those in Jinja templates. So the
40:44 template generates the JavaScript code that then runs on the client to use Moment.js. Yeah, that's
40:49 really nice. And Moment.js is live, right? So like, if it said five seconds ago, then it would say six,
40:53 and then seven and so on. Is that right? Yeah, it's awesome. Yes. The way I implement it is, it's
40:59 optional. You can request not to do that. For some things, it doesn't make sense. But this extension will
41:04 allow you to do that. If you want to say, keep updating, you send refresh equals true in the template.
41:09 And that's all it takes. Yeah. And then it updates on its own. Yeah, that's really cool. So you render
41:14 the page, you look at it says 30 seconds ago, go grab a coffee. And then it says two and a half minutes
41:19 ago, right? It's beautiful. Yeah, it changes. It's really nice. Yeah, flask page down page down. So
41:25 if you use the stack overflow, the little editor where you write your, your answers, that automatically
41:33 updates below, you see the render representation, you type mark down, and you see it update immediately. So
41:39 this is an open source project. It's a JavaScript library. So flask page down allows you to use that
41:45 in your applications. And again, implement it, sort of, you think you're doing it in the server,
41:51 but you do it in the Jinja template. And all the extension does is generates the JavaScript that
41:56 then runs on the client. But at least you can have control of it from the server side. So that's what
42:02 it does. Yeah, okay. Yeah, that's really cool. It's coming to a climax with the open source
42:06 project. The last one is actually called climax.
42:08 climax is, this was a really fun one. I implemented it like in a weekend, two weeks ago, to be honest.
42:18 So I really like click, I mean, Runikers command line, decorator based command line parser. But
42:25 there's one thing that I don't like. Yeah, it's cool. And we talked about that on his show when he was on,
42:29 and we talked about his work with click. So, right. So it's another one of those things that I think,
42:34 damn, I should have thought of that, right? I hate the guy because he thought of it.
42:38 But anyway, one thing that I don't like is Armin's distaste of our parts, right? He doesn't like our
42:45 parts. And for some things that I'm doing, it will be useful for me to be able to integrate with existing
42:52 applications that use our parts. So I created climax as a clone. It's a blatant copy of Armin's click,
43:01 but as engine, it uses our parts. So that allows you, for example, you could take a tool like say,
43:09 Alembic, which uses an art parts, a parser for its command line, and import it into a bigger command
43:16 that you own, and offer, you know, Alembic's set of options as a subcommand, because it nicely
43:22 integrates and you can compose bigger parsers by taking, you know, our parts, parsers from different
43:27 sources. Okay, that's really cool. Yeah, yeah, very nice. Okay. So I'll try to have links to all
43:32 that stuff on and everything else we talked to on the episode page. Cool. Okay, so let me ask you two
43:39 more questions before we wrap it up. So last week or two weeks ago, you wrote climax. What editor did you
43:46 use to write it? I use Vim with the Python mode plugin. That's my always go to editor. Okay,
43:54 I'm gonna be honest, I know probably, I would say, five to six keys in Vim. And it makes me super
44:03 proactive, even though I know very little about it. I don't use any of the advanced things. But Python
44:08 mode makes it really cool. I also like PyCharm. When I need to debug something really complex, I tend to go
44:14 go to PyCharm, but more for the debugger than the editor. Yeah, okay, cool. Yeah, the debugger in
44:18 there is pretty sweet. So the other question is, there's 60,000 or however many packages on PyPI.
44:25 What ones would you recommend people check out that maybe they haven't heard of? So, you know,
44:30 they probably heard of requests, maybe Flask. But you know, what else? What else should people go check
44:35 out that is maybe not well known yet that you want to tell them about? One package that I really,
44:41 really like, speaking of debuggers, I started my career working on Windows long ago. So I'm used to
44:47 Visual Studio and the Visual Studio debugger, which is really, really good. So I'm used to interactive
44:52 debugging more than GDB or, you know, console type debugging. So there's a package called PUDB.
44:59 I'm not sure how popular it is. This is an interactive debugger, but it works in text mode.
45:05 Say you are debugging something on a remote server or maybe on an AWS instance, you know, something that
45:11 you can only get through a shell. You can pop this thing. So pip install PUDB. And then it works like
45:17 PDB, the command line Python debugger, but it brings up a GUI, text mode GUI. And it's really, really decent
45:24 to work. And it runs anywhere, right? Because it's text. I go to that debugger a lot when I'm
45:30 debugging, you know, remote sites. It's extremely useful. Yeah, that's cool. You're SSHed somewhere.
45:35 There you go, right? You don't want to install. There's no way really to reasonably install PyCharm out
45:39 there anyway, right? So... Right, exactly. You can't. So it doesn't work for that. I mean,
45:43 you may be able to set up remote debugging, but it's a hassle. If you need to debug something... Yeah,
45:48 exactly. Just put the PUDB package and, you know, you're good to go. It's, you know, super easy to use.
45:54 Yeah, okay. Oh, good recommendation. All right. So I guess, you know, people should go check out your book,
46:01 check out your blog. What else should they be up to now that they've heard all about what you're up to?
46:05 They're definitely invited to contact me, to interact, tweet me, questions. You know, I spend a lot of time
46:13 answering questions, whether it is Stack Overflow or Twitter or comments on my blog. Probably spend,
46:21 you know, on average, I'd say an hour a day responding to questions. And I enjoy that. That's another source,
46:27 another motivation for me to learn and stay, you know, current on things. I'm really a person that I'd
46:33 like to be engaged. And so I invite everyone, you know, to send me questions, problems, ideas.
46:39 Awesome.
46:39 Yeah. And yeah, we'll all learn together.
46:42 Yeah. Very cool. PyCon this year is coming to Portland.
46:46 Yay.
46:46 Your hometown, my hometown.
46:48 Yeah, I can still be my bad.
46:49 Yay.
46:50 I love that.
46:50 Are you going to make it?
46:51 Yes, definitely. I have my ticket.
46:53 That's awesome. Are you going to make it?
46:54 Yes. I'm going to be there. I think I sent four proposals. So we'll see what happens. I hope I get to talk.
46:59 Excellent. Yeah. Good luck with that.
47:01 I've been doing tutorials, the last two PyCons. And this year, I'm doing, I guess,
47:05 an advanced tutorial. I hope I get it. It's to address the question that there's a common
47:09 misconception that Flask does not scale.
47:12 Interesting. Okay.
47:13 I created a tutorial dedicated specifically to address all those concerns and show how to scale
47:18 Flask in three hours.
47:20 All right. That sounds really cool. Like a really good follow on to your other ones. So
47:23 that'll be great. I'll see you in Portland.
47:25 Mm-hmm. Yeah.
47:25 Thanks for being on the show.
47:26 Yeah. It was a pleasure. Thank you for inviting me.
47:29 This has been another episode of Talk Python to Me. Today's guest was Miguel Grinberg. And this
47:34 episode has been sponsored by Hired and SnapCI. Thank you guys for supporting the show. Hired
47:40 wants to help you find your next big thing. Visit Hired.com/Talk Python To Me to get five or more offers
47:46 with salary and equity presented right up front and a special listener signing bonus of $2,000.
47:51 SnapCI is modern continuous integration and delivery. Build, test, and deploy your code directly from
47:58 GitHub, all in your browser with debugging, Docker, and parallelism included. Try them for free at
48:03 snap.ci/talkpython. Do check out the video course I'm building. The Kickstarter is open until March 18th,
48:11 and you'll find all the details at talkpython.fm/course. You can find the links from this show at
48:17 talkpython.fm/episodes/show/48. Be sure to subscribe to the show. Open your favorite podcatcher and search
48:25 for Python. It should be right at the top. You can also find the iTunes and direct RSS feeds in the
48:30 footer of the website. Our theme music is Developers, Developers, Developers by Corey Smith, who goes by
48:36 Smix. You can hear the entire song on talkpython.fm. Once again, this is your host, Michael Kennedy.
48:42 Thank you so much for listening. Smix, take us out of here.