#129: Falcon: The bare-metal Python web framework Transcript

00:00 Full-featured web frameworks are great, but sometimes living closer to the network layer

00:04 is exactly the thing you need. This week, you'll meet Kurt Griffiths and John Varbenak,

00:08 who work on the Falcon Web Framework. It's a bare-metal Python web API framework for building

00:14 very fast application backends and microservices. How bare-metal? Well, other frameworks like the

00:20 HUG REST framework are even built upon Falcon. This is Talk Python to Me, episode 129, recorded

00:26 July 17, 2017.

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

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

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

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

01:03 Rollbar. That's right. Welcome to Linode, who has joined Talk Python to Me as a major sponsor.

01:09 Be sure to check out what both of them are offering during their segments. It really helps support

01:13 the show. Kurt, John, welcome to Talk Python.

01:16 Hi. Thanks for having us.

01:18 Yeah. It's great to have you guys here. I love talking about web frameworks, and yours looks

01:23 very, very interesting. So I'm super excited to share it with all the listeners. But before

01:27 we do, let's start with your stories. Kurt, how did you get into programming Python?

01:30 Well, so just programming in general, I got started way back in the day in sixth grade. I was in

01:37 my math class, and they had a, I think it was probably a Commodore or a Pet, one of those old

01:45 crafty machines. And someone, one of my classmates just came in one day and said, hey, check this

01:50 out. And he brought up the basic terminal, and he typed in this little program. And all

01:54 it did was convert dollars to, I think it was to yen. Nothing fancy, but like I'd never seen

01:59 someone program before like that. And they just kind of sparked my interest. And I thought,

02:04 that's so cool. You can like type incantations into the keyboard and the computer will do something

02:10 for you. So that's kind of how I got started.

02:13 Yeah, that's really nice. And it probably didn't seem like unachieable. You're like, how did you

02:17 do that? Oh, that's all? Well, that seems pretty easy. I could do this, right?

02:20 Yeah, exactly. It was very approachable. And I think probably a lot of people got introduced

02:24 to that, to computing. So this was back before a lot of people had computers at home. And

02:29 some of their first interactions with them were like at school. So yeah, I went home and I did

02:35 a little research. I found out that not long after that, my dad brought home an old surplus

02:39 IBM XT from work. And I found out it had basic on it. And so I saved up my allowance for a few months.

02:46 And much to the astonishment of my sister, thought I was wasting all my money. I spent it all on a

02:52 programming book. And then kind of the rest is history.

02:54 That's awesome. What was the first language? What was that book on?

02:59 Yeah, basic was first language. I went on from that to, I think it was C++. And I've kind of,

03:06 I've learned a lot of languages on the way. So I've actually been doing Python probably for about

03:11 about five years now.

03:13 Nice. How'd you get introduced to Python?

03:14 So that was after I came on board to Rackspace. And we were doing some projects there. And we'll

03:21 probably talk about this a little bit later. But I was actually doing a lot of C++ at the time. And

03:27 we had done some C++ on the server, but that's not very fun, I have to admit. So we were looking for

03:34 something a little more friendly for that environment, something a little more easier to work with.

03:38 And kind of settled on Python. A lot of other people were using Python at Rackspace. And so it was kind

03:44 of a natural choice. And I started doing some Python things.

03:47 Yeah, yeah, that's cool. Did you miss the curly braces? And the semicolons?

03:51 It took some getting used to that I must admit. But now I have the opposite problem. I go back and I

03:56 keep forgetting the curly braces.

03:58 Yeah, I hear you. I've made a new rule for myself. I'm going to try to write JavaScript with no curly

04:02 braces. If it's willing to add it, I'm willing to not write it.

04:05 Yeah, there you go.

04:07 How about you, John?

04:08 Yeah, so I actually got started programming whenever I was a little kid. My father was an electrical

04:16 engineer for Cisco Systems. And whenever I was seven, he introduced me to DOS and BASIC. And

04:26 quickly kind of outgrew that and then ended up in Borland's Turbo C++. So that was my first taste of a

04:34 real language, I like to say.

04:35 Yeah, yeah. C++ is a good language.

04:37 Yeah, especially back in those days. It was, you know, the days of, you know, no stack overflow and

04:45 spending a bunch of time in the Barnes and Nobles or borders, you know, in the programming language aisle.

04:51 Back when you had to earn your knowledge?

04:53 Yes, yes.

04:54 That's right. So how'd you get to Python?

04:56 So interestingly enough, I've been getting involved in a lot of Linux work. This would have been, what,

05:04 2012-ish. And at the time, I was having to do a bunch of build scripts and whatnot in using Gradle.

05:12 And I kind of got really tired of doing a lot of that. And I was like, well, a lot of people use

05:17 Python. So I started getting interested in that just from a scripting perspective. And then I think it

05:23 was App Showdown or something or whatever it was called back then. And I thought, well, let's try to

05:29 write an app. And I think that was the worst Python I've ever written in my life. But it got me

05:34 very interested in it.

05:35 Oh, yeah. That's really, really cool. All right. So what do you guys do day to day? Kurt,

05:40 I'm guessing from the background, you might be at Rackspace right now?

05:44 Yep. So I've been at Rackspace about nine years. I'm actually going to be leaving pretty soon here

05:49 to kind of work on some startup ideas. So I've done a lot of stuff at Rackspace. Most recently,

05:54 I've been working on sort of, well, what we call managed security at Rackspace. So we provide a lot

06:02 security services for customers. We take vendor products and we kind of wrap them up and glue

06:06 them together and make them easier to use and provide a 24-7 SOC that's staffed by security

06:12 analysts that kind of watches our customers' servers, make sure that we kind of keep the

06:17 bad guys out. So I've been working in the security space probably for about three years now.

06:22 Yeah, that's really cool. So what kind of stuff can you guys do to keep hackers out? Like for me, I

06:29 make sure I patch my code straight away, you know, as soon as any security updates come out,

06:34 try to follow the best practices and stuff. But beyond like simple guidance, right? Like can you,

06:41 how do you detect these things?

06:42 Yeah. I mean, there's certainly just the basic stuff that you need to do, the patching,

06:46 et cetera, that you mentioned. The Center for Internet Security publishes a number of hardening

06:51 guidelines. A lot of people follow, especially if they need to get PCI compliance or something like

06:56 that. So you kind of do, you do your basics. Beyond that, the attackers have become so sophisticated

07:03 these days that like, it's really not when they're going to get in, but I mean, it's not really,

07:08 not really if they're going to get in, but when.

07:10 Not if, but when.

07:11 So, so that kind of falls into how do you monitor constantly? How do you react quickly

07:17 when you would detect an anomaly and you've got to get in there and diagnose it and find

07:21 out, well, maybe it's just, you know, you change something in your application. So it's fine.

07:26 It's just behaving a little differently. Sometimes maybe, yeah, someone's in there and you need

07:31 to kind of throw down the, the firewalls and, and get them out. So it's a combination of

07:37 kind of the hardening, the patching, but also the constant 24 seven vigilance and having a

07:43 response plan in place. So you can react quickly and resolve the issues.

07:48 Yeah. I'm sure you have some, pretty amazing stories, but let's stay focused on Falcon.

07:53 John, how about you? What do you do day to day?

07:55 So I actually work in a rack space managed security as well. I'm relatively new to the team.

08:01 I previously came from EMC and then previous to that, I actually was in a different part of rack

08:08 space. So kind of jumping around the industry a little bit.

08:12 You live in the cloud.

08:13 Yeah, pretty much. I think, a lot of what I do day to day is help, build some of the

08:21 utilities that we use internally to manage security. So helping in delivery of some of the, some of the

08:28 products and helping isolate what, and how we're, how we're using our tooling. So, yeah,

08:35 it sounds cool. Like I said, I'm sure you guys probably have awesome stories that would be really

08:39 fun to dig into, but let's talk about your web framework Falcon. It looks, looks really neat.

08:44 Kurt, you want to tell us what is Falcon?

08:46 Well, so just basically it's a little Python web framework for building microservices,

08:52 proxies, application backends, those sorts of things with a particular emphasis on, on low latency,

08:58 high scale use cases.

09:00 Yeah. So one of the ways you describe it as a bare metal Python web framework. So yeah,

09:05 that kind of gives you a sense, right? It's not, it's not Django with its admin backend and,

09:09 and that it's, it's something way more low level and closer to the network, right?

09:14 Yeah, definitely. So it's a relatively thin layer on top of whiskey. so there's not a lot between

09:21 you and your web server. And it also tries to kind of embrace HTTP versus paving over it. So you have

09:29 direct access to everything that's going on.

09:31 Yeah, that's cool. Headers, requests, response, all of that codes, all those things are super

09:36 natural in there. Yeah. Yeah. So people listening to whiskey, web service gateway interface,

09:40 like the standard that almost every Python web framework implements to be a Python web framework

09:47 and plug into the high performance web servers. So you have a nice little, problem for people to

09:54 solve math problem on your homepage. You said you've been unburdening cloud apps for over 4.5,

10:01 three times 10 to the next second centuries. So you've been around about 4.5 years or so. Is that right?

10:07 Yeah, that's about right. I kind of stole that from ours. Technica used to have a little thing in,

10:12 in kind of the early days when they're getting started, they used to have a little thing on their

10:16 website. so I have to give them credit for that. Yeah, it's nice. Yeah. So why don't you guys

10:22 both tell me, Johnny first, what's your relationship to the product? Like, or to the project? Like,

10:28 did you both start it together? Someone, one of you started first, I'll come along later.

10:33 I got involved in Falcon a little bit further into its, into its history. I suppose, my initial

10:40 use was purely as a user. I, was using it to, to solve several scaling problems from just like a

10:49 general sense from a performance standpoint. But overall, I kind of, what attracted me to Falcon was

10:55 the kind of non-opinionated ideas, being able to have like a flexible base that I could build upon

11:02 and, you know, reuse over and over almost like a framework for frameworks, if that sort of makes

11:09 sense. Yeah. That is interesting. I think there's people who learn web development or do web development

11:15 are kind of in two camps. They either like all this flexibility and like, I'm going to pick this

11:20 ORM or this data access layer and this caching layer. I'm going to plug this together like that.

11:25 Or they want just, it's kind of slotted together like this style or Django, right?

11:31 The interesting thing about Falcon is that it kind of, in some ways, like a lot of frameworks are very,

11:39 have a very opinionated way of approaching things, which is, you know, both good and bad. I think,

11:45 Kurt and I like to talk about how Falcon is kind of in the middle of a spectrum of frameworks. You know,

11:52 all of them have different and important purposes, but yeah, some, in some cases, it depends on your,

11:58 either your own personal opinions or, or the problem you're trying to solve. But in the case of

12:06 Falcon, it just seemed like to, to jive with the way that I thought, the way that I approached problems.

12:12 And fast forward a couple years later, then became a maintainer. So yeah, that's cool.

12:18 Wait a minute. I'm working on, I'm creating this thing. I was just using it. What's going on here?

12:23 How'd I get here?

12:24 Yeah, exactly.

12:26 So Kurt, what was the original idea behind creating Falcon?

12:32 Well, that's an interesting story. So Falcon was actually based on an experimental framework

12:37 that I had developed four plus years ago. So at the time my team and I were tasked with building a cloud

12:44 backup product for Rackspace. And the way this would work is you would have these headless agents that

12:50 would sit on the cloud servers. They would do the heavy lifting, the backup encryption,

12:54 uploading to cloud files, which is Rackspace's version of OpenStack Swift. And you need some way to kind of

13:01 command and control the agent, right? So it needed to be able to talk back to this sort of monolithic

13:06 web application that had the control panel there, had some of the control logic, the settings, you know,

13:12 what you should back up, et cetera, how often you should do it. So we needed some simple messaging

13:18 mechanism for those two things to talk, the agent and the control plane.

13:23 So we started looking at some different ways to do that based on some previous experience.

13:27 We were kind of biased towards using the REST architectural style for that messaging service.

13:32 As I mentioned earlier, so I had played around with Node, JS, but that wasn't really a, it was still pretty new at the

13:40 time and not a lot of people were using it at Rackspace. But Python seemed to be more of a natural fit.

13:45 So I started just kind of looking around, you know, I'm kind of a firm believer in using the best tool for the job.

13:51 I just kind of looked at some of the different frameworks. Flask seemed kind of like a natural fit.

13:55 It's a little bit lighter weight than Django. Looked like it might be a good way to go.

13:59 So I just kind of built like a very basic kind of hello world app, like as you do, and just benchmarked it.

14:06 So the thing with this, we had some very stringent latency requirements, because one of the things that you would do

14:14 through the control panel is actually go browse your remote machines, their file systems and choose what you want to back up, right?

14:20 And so that message passing had to be semi real time. We wanted it to be as responsive as possible.

14:26 So I kind of had an idea of a budget of response time. I don't remember exactly. It was certainly under 200 milliseconds, probably more

14:37 120, around there. Ideally, we want to get it down.

14:41 Does that count ping time?

14:42 Yes, overall.

14:42 So you need it under 200 milliseconds for it to feel real time. That's just the nature of humans, which means that your app, you don't have much left over for just for your app to turn around the request.

14:53 Honestly, at the end of the day, you have like 40, 30, 20 milliseconds to turn around a request, because a lot of the time is just eaten up with traversing the internet. So yeah, so I didn't have a big budget for the latency there.

15:06 And I benchmarked just a simple Falcon app. And it was much higher than I expected. I honestly, I don't recall the exact time. But I thought, you know, that's kind of weird. Let me just try just a straight up raw whiskey app.

15:20 You know, so I looked up the PEP 333 and wrote up just a simple, simple app there that didn't do anything. And there was actually a huge gap between that, you know, the response time there, and just with like a Falcon hello app. And I thought, that's weird. You know, what is Falcon doing? I mean, what is, what is, it's taking so long, right?

15:41 I have to kind of confess a sin here. I used to do a lot of Ruby as well, Ruby on Rails stuff. And I remember this Sinatra framework, right, which is kind of one of the early projects to explore this micro framework concept. So I did the same thing over there. I did a basic, like, just raw rack app. And then I benchmarked Sinatra. And just the difference between those wasn't actually that great.

16:06 And so I just had the hypothesis that, you know, there's probably stuff that's, I could probably make a thinner framework than Flask that would give me enough, enough to work with it. I don't have to just code directly to the whiskey interface, but it's still, you know, fast enough for my, for my needs.

16:23 Right. You just need a few abstractions. You need body, you need the verb, you need the headers, and you need JSON serialization or something like that, right?

16:33 Exactly. So it just started out very simple, kind of as this experiment, very pragmatic. And I ended up building this little framework, and we put that service into production, and it worked really well for us. And so I decided we probably should make this real. And so we started the Falcon Project, started inviting people from the community to try it out and contribute. And then that's where, that's kind of where it came from.

16:57 Yeah. Okay, that makes a lot of sense. Definitely in the benchmarks, which we'll talk about performance later. It's faster than many of the other sort of well-known frameworks.

17:06 Yeah, definitely. And kind of going back to what John was saying, it's there when you need it. Not everybody needs it. So it just kind of depends on what your use case is.

17:14 Yeah, for sure. So John, maybe this is an interesting time to do like a compare and contrast. What's this framework? Like, how is it different and special than let's say Flask, Django, Pyramid, these types of frameworks?

17:26 Inherently, the more pragmatic approach, I believe, for Falcon is kind of the benefit. But to like what I was saying earlier, a lot of this does tend to be very much of a spectrum and kind of a part of the, you can almost think of the wider community of frameworks.

17:46 The direct benefits. Yes, you've got performance, but sometimes performance is not always the most important thing. I heard someone say once, and I firmly believe this, that in a lot of cases, time to market is more important. So you can have the most performant app in the world. But if you don't get the job done, then...

18:06 We'd all just be optimizing our stuff in assembly and making it go really fast.

18:09 Yeah.

18:10 Yeah.

18:10 I think, you know, there are some interesting differences. A lot of them do come around the kind of more either heavier or opinionated type, say, almost workflows.

18:22 The benefit that Falcon has given me personally, and one of the reasons I got very interested into it, is that especially when you're building internal tooling, often cases you need a certain level of flexibility that oftentimes opinionated frameworks don't give you.

18:39 So, like, they might be great for the top, you know, for like 80% of your work, and then it's a real burden to try to get through.

18:46 It doesn't mean that those frameworks aren't any, you know, worse or, you know, better. It's just a different tool for the job. So, to like what Kurt was saying, trying to focus on the right tool.

18:58 Yeah, absolutely.

18:59 What we've seen in talking with users is it's really become sort of a complementary framework to what people are doing. You'll have someone who has a large sort of monolithic Django app, and they have a really hot endpoint.

19:12 Maybe they're using Django REST framework, which is a great framework, but for this one endpoint, it's just killing their servers.

19:18 So, they carve that piece out, write it in Falcon. It lets them make the performance trade-offs that they want to make, and then, you know, they keep the rest in Django, and then they are able to partition that one piece off into a microservice, and that works well for people.

19:32 So, that's just one example of how it works alongside these other frameworks.

19:37 Yeah, that's a much better answer than saying, let's rewrite it and go. Let's rewrite it and C++. Let's rewrite it and, you know, name your other language and technology that has its own problems, right?

19:48 I think that's something very important to kind of go along with that. A lot of people, they do focus on those initial numbers.

19:54 Those numbers may look great, but, you know, real-world numbers are often much different than benchmark numbers.

20:00 And at the end of the day, a lot of this, especially in today's world, it's about how you can scale your app after the fact.

20:08 Like, you may only have a couple thousand requests a second, you know, out of the gate.

20:12 But whether or not you can, you've architected your system or your application to be able to scale to 100,000 or a million or whatever, that's usually the most important.

20:24 Because in this day and age, hardware is scalable.

20:28 Yeah, for sure.

20:29 And you definitely, you know, the benchmarks, they're often doing something very, very lightweight inside, like reading a value off the query string and returning it back as JSON or something.

20:40 And I think maybe the way to think of it is more like this is the overhead this framework adds to your app.

20:46 But that's not your app.

20:48 You know what I mean?

20:49 Like, your app is actually the talking to the database, the logic, this other service it calls, et cetera, et cetera, right?

20:54 Yeah.

20:55 I mean, if you recall the little story I told, I mean, kind of the core idea around Falcon is our promise to you is we will remove the bottleneck in the framework.

21:05 Your performance bottleneck will not be in the framework.

21:08 Everything outside of that is kind of up to you, right?

21:10 And it depends on all the things you're doing.

21:12 That's still your problem, yeah.

21:13 Yeah.

21:13 So, but at least you don't have to worry about that piece.

21:16 Yeah, it's really cool.

21:16 I definitely want to talk a lot about the performance, but a little bit later.

21:20 Falcon is mostly for building APIs, if I understand it right.

21:26 Is it possible to build like Jinja 2 or Chameleon-based UI type things, or is it really just focused on APIs?

21:35 You can.

21:36 I know several of our users have actually asked how to do these types of things, and it's actually not that hard to plug in a Jinja 2 rendering system into,

21:46 into your resources for Falcon.

21:49 Is it really well designed for that?

21:52 Not really.

21:53 You could easily build something around Falcon to do it.

21:56 Often cases, I think the majority of our use cases are mainly around APIs, but it doesn't mean you couldn't.

22:03 Sure.

22:04 And I think it's kind of cool to have a framework focused only on APIs, because you know what?

22:08 It's really probably super good at that, right?

22:10 Compared to trying to fit it into all these other models.

22:14 One of the things that I was talking with the user, this was quite a ways ago, maybe in December,

22:19 and they were actually building effectively a little ORM on top of Falcon, just to kind of give you an idea of what the scope of how much somebody was able to change it,

22:30 which is, you know, that's awesome that they're able to do that.

22:33 I would imagine it would be a little bit more work than what people would often want to do.

22:38 Maybe another framework is a little bit more well-suited for it, but in their case, they wanted the flexibility and control.

22:44 Sure.

22:45 Yeah, so probably people that would do that sort of thing are kind of your control freaks, right?

22:50 They want to tweak everything.

22:52 Control freaks in the developer space, never.

22:54 We're happy to accommodate them.

22:57 Yeah, that's cool.

22:58 We want to do it.

22:59 This portion of Talk Python To Me is brought to you by Linode.

23:05 Are you looking for bulletproof hosting that is fast, simple, and incredibly affordable?

23:08 Look past that bookstore and check out Linode at talkpython.fm/Linode.

23:14 That's L-I-N-O-D-E.

23:16 Plans start at just $5 a month for a dedicated server with a gig of RAM.

23:20 They have 10 data centers across the globe, so no matter where you are, there's a data center near you.

23:25 Whether you want to run your Python web app, host a private Git server, or even a file server,

23:30 you'll get native SSDs on all the machines, a 40 gigabit network, 24-7 friendly support,

23:36 even on holidays, and a seven-day money-back guarantee.

23:39 Want a dedicated server for free for the next four months?

23:42 Use the coupon code python17 at talkpython.fm/Linode.

23:50 You guys had said that it's almost like a meta framework in some sense.

23:54 It's like low enough that you could actually build other frameworks kind of on top of it in a sense.

23:58 Does that sort of land in that space, this example?

24:01 Yeah, definitely.

24:02 We've seen a couple people do it.

24:05 Hug is probably one of the better known frameworks that's actually built on top of Falcon.

24:09 Interesting.

24:09 Hug is built on top of Falcon.

24:11 I was going to ask you about Hug and Django REST Framework and API Star.

24:15 Those three, well, API Star and Hug feel like the newcomers that are also trying to be API-focused only,

24:23 whereas Django REST Framework is more extending Django than kind of being a new thing, I think.

24:29 Yeah, I mean, I think the Django REST Framework is trying to just be an easy on-ramp to APIs when you're already doing your work in Django.

24:37 So it's a natural place there.

24:39 I think Tom's done some good work with that.

24:41 And, you know, you look at Hug, API Star, those sorts of things.

24:45 They're trying to kind of ease the burden of API development.

24:48 When you kind of do that, you necessarily have to be more opinionated.

24:52 We've mentioned this earlier, Falcon tries to be a little more low-level, less opinionated.

24:58 But you can certainly build these kinds of things on top of it.

25:00 Yeah, that's really cool, actually.

25:01 And it's interesting to hear about the Hug relationship.

25:04 So speaking of the philosophy, you had three basic driving points for your philosophy to be light, fast, and explicit, right?

25:12 The light, we've kind of touched on a little bit, being fairly low-level.

25:16 But there's a couple things that we haven't mentioned, some of the benefits that gives you.

25:21 One is that you have a smaller code base, so it's easier to make a reliable framework.

25:27 When something blows up, it's easy, somewhat straightforward to find the problem and fix it quickly, which becomes very important in large-scale deployments.

25:39 When you're serving many, many thousands of requests, you have hundreds of servers, you need to be able to diagnose problems very quickly.

25:47 So that helps as well.

25:48 And it also helps just optimize it.

25:52 It makes it easier to do that as well.

25:54 Yeah.

25:54 One of the ways to optimize code to make it go really fast is to just not run code.

25:57 That's right.

25:59 Right.

25:59 This part would be slow.

26:00 Let's just not do that in our framework.

26:02 Do less work.

26:02 Yeah.

26:03 That's the name of the game.

26:04 What else?

26:06 So fast, and we touched on that a bit before as well.

26:09 We try to be one of the fastest frameworks.

26:11 I don't think we necessarily claim to be the fastest framework for all benchmarks in all scenarios,

26:18 but we try to be up there at the top.

26:21 And again, make sure that you don't have to worry about, you don't have to spend time looking for the bottleneck in the framework.

26:27 You are in control of making those performance tradeoffs outside of that piece.

26:32 Yeah, for sure.

26:33 And the third was explicit, right?

26:35 Like, keep the magic out.

26:36 You can do a lot of clever things with thread local storage and inversion of control and things like that.

26:43 I mean, we do a little bit of IOC, but we try to make it painfully obvious, like, where the data is coming from, where it's going, how to set the data, all those sorts of things.

26:55 Because again, especially in large-scale deployments, when you're trying to debug an issue, you don't want it to be doing something surprising.

27:04 Yeah, absolutely.

27:06 The more obvious, the better there.

27:07 So kind of the opposite of Ruby on Rails or these other frameworks that have lots of conventions and stuff just happening, you kind of got to know it, right?

27:15 Like anything, there's a tradeoff.

27:16 Like, you get a lot of power from that, but there is kind of a lot of magic and kind of a steep learning curve there.

27:23 Sure. So, John, what do you guys do for, like, reliability and testing?

27:28 Do you have, like, continuous integration set up, things like that?

27:31 We do all of our testing via Travis at the moment.

27:34 Well, everything except for, I would say, our performance benchmark testing.

27:40 But we actually, we test against all of the major versions of Python at the moment.

27:46 And that would be currently all the way from 2.6 to 3.6 at the moment.

27:51 Yeah, that's great. That's quite the span.

27:53 We also, we do claim support for the both versions of PyPy.

27:59 And we had a Jython job in there, but I think we were running into a few problems with the Jython.

28:05 But beyond that, we actually, we mentioned Hug earlier, and we do have, like, an integration test with them, which is very helpful.

28:16 So, I think we do run quite a few automated tests against Falcon.

28:21 And we try to make sure and maintain backwards compatibility at all costs.

28:28 Yeah, that's something I really think is highly important in the web space.

28:33 Because you see a new update come out, you pip install, upgrade, push that to the server.

28:40 If that breaks something, that's, you don't want to be caught out.

28:44 Why is the website down? Oh, my gosh, this is really upsetting.

28:47 Just a quick thought on that.

28:48 Like, one of the, this kind of came about because in some of our extremely high-scale cloud services that we build at Rackspace,

28:57 we were relying on some web frameworks that would tend to break in subtle ways, you know, just in minor version releases.

29:06 So, we felt that pain very keenly, and we wanted to be very careful about that.

29:11 So, that's kind of core to our change management philosophy around Falcon,

29:15 that we go to great lengths not to break stuff without a major version rev.

29:21 Yeah, absolutely.

29:22 John, it seems like the philosophy ties into that as well.

29:25 Like, the less code you have, the more lightweight, the more explicit, the easier it is to test and not break things.

29:31 Definitely.

29:32 And even when we do add in more substantial features, like, we have a feature coming in for 1.3 around media content type handling.

29:42 So, it'll handle serialization, deserialization, all of that.

29:45 But all of that is 100% optional.

29:49 And it's very important that it is that way and that it does not impact, you know, request times from a performance perspective.

29:59 And, like, we go to great lengths to make sure that things are architected in a way that somebody can feel comfortable just upgrading to the next minor version and not worry about breakages.

30:12 Yeah, absolutely.

30:13 I think that's great.

30:14 And unless you turn on that feature, it's not going to affect you, right?

30:17 Or in this case, it's there.

30:19 It's just you have to start using it.

30:22 Right.

30:22 But it's how the feature was designed so that, you know, it doesn't impact you unless you use it.

30:27 Yeah, that makes a lot of sense.

30:28 So, Kurt, I have a challenge for you.

30:32 It's a little bit difficult to describe code in an audio format.

30:37 So, don't go too much into detail.

30:39 But give us a sense of what it's like to program for this.

30:42 Like, if I want an API that exposes, like, customers or whatever, I can get a customer and create a customer.

30:49 Like, what does the code that I put together to do that look like?

30:53 I typically start out thinking, because I'm kind of a REST geek.

30:57 So, I start thinking about the resources.

30:59 So, I'll think about, okay, we need to define a customer, a resource that represents a customer.

31:05 And then maybe a resource that represents a list of those customers.

31:08 We'll just think about that.

31:09 So, in Falcon, you represent a resource with just a plain Python class.

31:14 Nothing super special about it, except that in that class, you have what we call responder methods.

31:20 And these are just methods that have a well-known name.

31:24 It starts with on and then underscore and then the name of the HTTP method that you want to respond to.

31:30 So, this resource responds to get requests, post requests, etc.

31:34 So, you create a method for each one of those.

31:36 Within that method, in that class, you'll receive request and response objects.

31:42 And so, this isn't too dissimilar from, like, maybe a web ob sort of a workflow where you get requests and response objects that you deal with.

31:48 It is a little bit different in that we hand you a response object.

31:52 So, you're not constructing it yourself and returning it.

31:55 You, like, fill it out.

31:56 Yeah.

31:56 So, like in Flask, you'll say, you know, you'll instantiate some kind of response and return it.

32:02 We'll pass in a pre-instantiated response, which actually saves you some work for the use cases that Falcon is designed for.

32:10 You're typically not returning different types of responses for different types of, like, say, JSON versus HTML.

32:17 Your negotiation is done a little bit differently.

32:21 But, so, you pull the information you need out of the request, do what you need to do.

32:26 You may use, like, SQLAlchemy to go talk to the backend, pull out a response, and then you fill out HTTP.

32:32 You've got the status code.

32:34 You've got the headers, things like that.

32:36 And because this is a class and you instantiate it up front, you can pass in, like, a database connection or whatever, anything like that.

32:42 There's no magic thread storage or anything like that.

32:45 Yeah, that makes testing super easy because it shows you right where to pass in the mock stuff later or other test fake things.

32:52 So, it's just straight up kind of normal Python class instantiation.

32:57 So, once you have that filled out, then you need to wire that up to a route.

33:02 So, a route is simply a mapping between a URL and your resource.

33:08 So, you'll have a place in your code.

33:12 You probably have a setup file that goes through and instantiates your resource class, passes in the database connection, whatever you need to do there.

33:21 And then you instantiate an API object, which is a whiskey app.

33:27 And then on that object, you can call, like, .add route, and you pass in the URL you want and then the resource.

33:34 And something else that's a little bit different is that from some of the other frameworks is that we don't use decorators.

33:41 We have you in stench.

33:43 You set up the routes in a central location.

33:45 Part of that is philosophical.

33:47 I mean, we talk about Python being somewhat unopinionated.

33:51 But in a few places, we are a little opinionated.

33:53 We just find that having everything in one spot makes it easier to kind of reason about your API namespace versus having it sprinkled around with decorators all over.

34:02 But that's just a little bit of a philosophical difference.

34:06 Yeah, I got to say, I kind of like that as well.

34:07 Like, you can go to one place near the app startup and go, okay, these are the routes.

34:12 This is where they go.

34:14 It makes a lot of sense.

34:15 And it just makes things a little easier.

34:17 Again, it's very clear where things are coming from, where they're going.

34:20 Because decorators can be a little bit.

34:23 I love decorators.

34:24 We use them for some things.

34:25 But sometimes they can be a little magical.

34:27 Probably the other thing to point out here is that you don't specify what verbs you're mapping to that URL.

34:33 So we are a little bit opinionated around encouraging the REST architectural style, which means you kind of think about resources.

34:39 And each resource is kind of responsible for deciding what methods it's going to respond to.

34:46 And so if you don't implement a method, Falcon will just return a method not found for you.

34:52 And it's as simple as that.

34:53 Right.

34:53 Okay.

34:54 Interesting.

34:56 So I might say in my example, slash users, users, customers, slash users, let's say.

35:02 And then that maps to a user resource class.

35:06 And there might be an on get and an on post, but no on patch.

35:10 And so would patch come back as 404 or a different status code?

35:15 It would come back as a method not found.

35:17 So you found the resource.

35:20 You had like something exists at the other end of that URI.

35:26 It just doesn't support the method that you requested.

35:28 Right.

35:29 I see.

35:29 So this is, again, this kind of goes back to the spirit of HTTP and REST and kind of a, we've read probably way too many RFCs.

35:40 And so some of that comes out through some of our design choices.

35:43 Is there a place I can make a return a teapot?

35:45 Yes, actually.

35:46 We have, just for the heck of it, I don't, you know, a couple of years back, we implemented a bunch of 700 errors just for fun.

35:53 So they're in there.

35:55 Hey, everyone.

35:57 This is Michael.

35:57 Let me tell you about Datadog.

35:59 They're sponsoring this episode.

36:00 Performance and bottlenecks don't exist just in your application code.

36:04 Modern applications are systems built upon systems.

36:07 And Datadog lets you view the system as a whole.

36:10 Let's say you have a Python web app running Flask.

36:12 It's built upon MongoDB and hosted and scaled out on a set of Ubuntu servers running Nginx and Microwisgi.

36:18 Add Datadog and you can view and monitor and even get alerts across all of these systems.

36:23 Datadog has a great getting started tutorial that takes just a few moments.

36:27 And if you complete it, they'll send you a sweet Datadog t-shirt for free.

36:30 Don't hesitate.

36:31 Visit talkpython.fm/Datadog and see what you've been missing.

36:35 That's talkpython.fm/Datadog.

36:38 John, there's a bunch of different add-ons and templates.

36:41 So like the philosophy of having it very small and very compact is cool.

36:45 But then a bunch of people have created like add-on extensions for this, right?

36:49 Yeah.

36:49 Yeah.

36:50 You want to highlight some of those?

36:51 Definitely.

36:51 So there's the interesting thing about the community and kind of how some of the add-ons occur is that a lot of this comes out of a desire for, in some cases, for people's needs or someone has a specific, let's say they're trying to deal with authorization or serialization.

37:13 Or they have some very opinionated way of deciding, you know, how to deal with specifications or whatever the case may be.

37:19 Falcon does allow for a lot of flexibility and control around those kinds of things.

37:25 So you can easily extend or wrap aspects of Falcon.

37:29 One of the interesting things that we did discover, you know, through the number of people who were writing effectively serialization and validation add-ons for Falcon,

37:42 we ended up taking a lot of that community feedback and, you know, compiling that into the features that, you know, the media content type handling that's going to be coming in one or three.

37:52 Right.

37:53 That's the thing you guys were just talking about.

37:54 Yeah.

37:55 That like content negotiation stuff that you were just talking about.

37:57 Yeah.

37:58 So like there's a lot of frameworks have very opinionated ways of looking at it.

38:04 Myself, like I've used quite a few different methods depending on the needs.

38:09 And, you know, for whether it be, you know, EMC, Rackspace, personal projects, whatever it may be,

38:16 you know, everyone has a little bit different ways of handling data or validating it.

38:21 And so trying to find a uniform and generic enough approach for everyone took quite a long time.

38:30 But some of that didn't occur until a lot of our community members started writing their own implementations.

38:37 So it's very cool to see kind of how that evolved from that.

38:41 You know, it started as an add-on and now it's become something that's going to be baked into the framework and the next release.

38:47 So you had like five or six examples of people trying to solve the problem.

38:50 You're like, I think we can put it all together like this, huh?

38:52 Yeah.

38:53 Most definitely.

38:54 We try to, you know, we're trying to be careful because we want to leave space for people to go and innovate and do these sort of third-party add-ons.

39:02 And we don't want to be too opinionated.

39:04 But in cases like these where we've seen a lot of, you know, it's pretty much something everybody needs.

39:10 We're moving towards a place where we think we're going to start creating some basic, just a basic way to get started out of the box.

39:17 And completely optional and still allow room for other people to build more sophisticated solutions.

39:23 But just to give somebody, people something to get started with.

39:26 Yeah, of course.

39:26 So are you thinking these are like extra packages that you can pull in?

39:32 Or are they going straight into Falcon, the package?

39:35 There are all, I believe all of these are usually directly on PyPI.

39:40 Some people have like just avoided that step and they just build them into their almost pseudo frameworks.

39:47 That's it on top.

39:48 I know for several smaller projects that I've done, I've had a very specific problem and I built middleware to solve the problem.

39:57 And they were never, it was never upstreamed or anything like that.

40:01 But it was great to solve the problem for the business need and it was carried around.

40:05 But there's no sense in upstreaming a lot of that.

40:08 So, but I think most of our contributors have just pushed up a PyPI package with that starts with like Falcon dash and then whatever, whatever they wanted it to be.

40:19 Yep.

40:19 Yeah.

40:20 That makes sense.

40:20 Falcon Forbes is a great example, a common use case, right?

40:23 For APIs, being able to access them from like single page apps and things.

40:27 And so we had someone who's contributed a few patches to Python say, hey, should I just build this out and should we make it part of the framework or not?

40:35 And he just ended up kind of maintaining it separately.

40:37 And I think that's great.

40:39 You know, I think that's kind of what open source community is all about.

40:42 For the stuff that we pull in, I think one of the deciding factors for us is what dependencies it brings with it because we don't want to like force extra stuff on the operators if we don't, that they have to kind of manage.

40:56 And also the more dependencies you bring in, the more likelihood that they might cause bugs or problems.

41:02 So we try to keep our dependency list super short.

41:06 So if it's something like JSON, like the built-in media handling helpers that John was talking about that are going to be in the next release, like, you know, they just use the standard library JSON.

41:17 Yeah.

41:17 So they don't bring much baggage with them.

41:19 And it's very basic stuff.

41:20 So it doesn't bring a lot of baggage with it.

41:23 You know, you start looking at some other things, it starts to be kind of heavy pretty quickly.

41:28 So we might, you know, we're kind of exploring our options, trying to still kind of experiment with how we want to do this.

41:34 I think over time we'll probably have a few projects under the falconry work that we maintain.

41:40 But we want to make sure we don't stomp on anybody's efforts to kind of do something really interesting out there in the community.

41:47 Sure.

41:47 Yeah.

41:48 Maybe have like some cookie cutter template type things that will bring in these additional libraries and like make it easy to get started, but not make it part of the project itself.

41:56 People don't want them.

41:57 Definitely.

41:58 We've actually talked about that a bit.

41:59 And I know I've been playing with a few things on the side.

42:03 I haven't actually pushed up anything yet.

42:04 But we've had several discussions, especially since PyCon, around how we can make that adoption and like building of projects a little bit easier on the community.

42:17 And so hopefully we'll have a better answer around that, you know, in a bit.

42:24 Yeah.

42:24 Sounds good.

42:26 So, John, let's talk about hosting.

42:28 You can run falcon, obviously, on CPython.

42:31 As far back as 2.6 and as far forward as 3.6.

42:36 So that's really great.

42:37 It also runs on PyPy, right?

42:39 It does.

42:40 Both PyPy, you know, to, I guess, PyPy 2 and PyPy 3.

42:45 From like a, how Falcon can be deployed is a very interesting, in a lot of cases, it just kind of comes down to what your needs are.

42:56 Because some people, like there are still performance differences between 2.7 and 3.5, 3.6, 3.7.

43:05 A lot of those performance differences in Python have started dwindling.

43:09 But there are still differences, especially with PyPy 3.0.

43:14 There's still some performance disadvantages.

43:16 So like if you needed top performance for whatever you're doing, maybe it's not quite there or ready for you yet.

43:25 In a lot of cases, while I generally deploy with PyPy, a lot of people that I, you know, talk with, they're more than happy with 3.5 or 3.6.

43:37 Right.

43:37 Straight CPython 3.5 or 3.6.

43:39 Yeah.

43:39 Yeah.

43:40 And I guess that comes back to the, like, how much of it is the framework that you're worried about versus how much of it is your internal code and the stuff you're doing internally?

43:49 How much can it leverage the speedups of PyPy versus does that thing you're using have some kind of C speedups anyway?

43:56 And so it would lose those or whatever, right?

43:59 A lot of the performance problems that we see are not necessarily in the Python directly.

44:06 I mean, there's a lot of speed advantages you can get by using PyPy.

44:09 And I highly recommend people using it.

44:12 One of the difficulties that we see, especially in recent times, is dealing with the WSGI servers themselves.

44:19 And I know this is something that really came up over in discussions at PyCon between the Django REST framework.

44:28 So that'd be Tom Christie, Falcon, and Flask.

44:31 And we were all talking about how to deal with some of the bottlenecks we see in the WSGI servers.

44:36 Like, I personally do play with G Unicorn, and I think it's great.

44:40 But there are certain bottlenecks in the WSGI servers currently.

44:45 And, yeah.

44:47 It does, like, you can sometimes squeeze out more performance out of using, like, UWSGI or MicroWSGI.

44:53 But, yeah.

44:54 We run into quite a few problems right now on that.

44:57 Well, and then there's the whole async side of the story that doesn't even fit with WSGI or the HTTP2 thing.

45:04 And there's a lot of room for those to get better.

45:07 Most definitely.

45:08 And that's actually what Tom Christie from Django REST framework and API Star, like, that's a lot of the work that, you know, he's exploring right now.

45:18 And Uveacorn is to try to deal with this kind of compatibility between async and G Unicorn and trying to resolve some of these WSGI-ish philosophies.

45:30 So it's very fascinating.

45:32 I imagine that the story around this will radically change in the next year, which makes me very excited.

45:37 Yeah, me too.

45:38 I think it's definitely a place where there's a lot of flowers blooming.

45:41 And somebody's going to crack this problem, and we'll just agree on it.

45:45 And it'll be like WSGI.

45:46 Of course you use that.

45:47 What I really like about Tom's approach is kind of up to this point, a lot of the attempts to crack this have been monolithic.

45:54 Like, someone will have a web framework, but then they'll build in, you know, an async web server.

46:00 And it's kind of hard to just use their web server, and it's fairly opinionated.

46:05 But building an async worker type for G Unicorn, exploring sort of a way of creating a de facto interface for that.

46:15 Nobody's really interested in doing like a WSGI 2.0.

46:18 But, you know, we need something to kind of code against so people stop implementing it every 10 different ways.

46:25 That's right.

46:26 So, yeah, we're following his work closely.

46:27 I'm hoping to contribute once we get a little bit more time here.

46:30 And we'll kind of see how it goes.

46:32 Yeah, that'd be great.

46:33 It'd be really cool to see something come out of that.

46:36 So, another thing around this performance and ways to host and run and work with Falcon is you guys also do something interesting with Cython, right, Kurt?

46:45 Interesting thing with Cython.

46:46 Cython, if you're not kind of familiar with it, it translates your Python code to CPython code and then compiles it for you just kind of automagically.

46:57 And if you want, you can add additional annotations to your Python code that will basically give hints to Cython.

47:06 So, you can say, hey, this is an int or treat this as an actual array and it's going to be a fixed size or things like that.

47:12 And then that allows Cython to do even more optimizations on it.

47:16 But you can simply compile any Python code.

47:19 You can run it through Cython.

47:21 It'll compile it for you and you get just the measurements I've seen in around 10, 20% decrease in your CPU cycles just by doing that.

47:30 That's cool.

47:30 And that's not compiling your code running on Falcon, but compiling Falcon itself once you've installed it, right?

47:36 That's right.

47:37 So, in the setup.py file, it just detects Cython if you've installed it.

47:42 So, it's an optional dependency.

47:44 If it's there, then it'll just use the build extension from Cython to pull in all the Falcons.

47:51 You could certainly do the exact same thing with your own code.

47:54 It's not terribly difficult.

47:56 It's kind of a nice, easy way to get a little bit of an extra performance boost if you are sort of invested in CPython.

48:04 If you can move to PyPy, then you'll see a much greater increase.

48:08 But not everybody can do that.

48:09 Right.

48:10 That probably depends somewhat on, yeah, it depends on the libraries that runs inside your methods.

48:15 Yeah.

48:15 Cool.

48:16 So, while we're on the topic, let's talk about performance.

48:19 You guys have some benchmark numbers that you put up there.

48:21 And I just, I can feel the challenges every time I see benchmark numbers.

48:27 Well, people shooting arrows at it.

48:30 No, you didn't do it this way, but I did it that way.

48:32 If I do it this way, it's faster.

48:34 Yeah.

48:35 Yeah.

48:35 It's just, but I still feel like they're kind of important to give you a general sense.

48:40 Right?

48:41 Mm-hmm.

48:42 So, on like CPython, you have, let's see, you've got Flask coming in around 4,200 for this particular benchmark.

48:50 You lay out the details on the website.

48:51 Like 4,200 requests a second.

48:55 You've got Bottle going at 16,000, but Bottle's like a super micro framework.

49:00 And then Falcon coming in at 30,000, which is really nice.

49:04 So, sort of use Pecan as a baseline, and it's 28 times faster than that.

49:09 So, that's cool.

49:09 Pecan was one of the frameworks that we were looking at for developing some services earlier on.

49:14 So, it just happened to end up in the benchmarks.

49:15 And we probably need to add Django.

49:18 It's a fairly straightforward benchmark just to show you what's possible, really.

49:25 Right.

49:25 How much of a difference it can make to kind of remove some of the layers and the abstractions.

49:30 And you may end up not needing, you know, some people are, a lot of people are kind of moving to Go or looking at some other, or Node, looking at some other options.

49:40 But you may not need to.

49:42 Maybe you just need to use something a little bit lighter.

49:44 But we try to be very, very straightforward about what this is and how we've done it.

49:49 But you certainly need to go benchmark your own use cases.

49:52 I mean, for that messaging service that we use for cloud backup I mentioned earlier, I went and built out an almost full implementation in Node and in Python and benchmark both of them to see which would do better for us.

50:05 So, yeah, you've got to do your own homework.

50:08 But this gives you a rough feeling for what's possible.

50:11 Yeah, that's very cool.

50:12 I was going to say, in addition to that, one of the things that is often kind of missed as a part of the benchmarks that we do is that we do remove the WSGI server from the benchmark.

50:25 A lot of for the reasons why I was mentioning earlier around the performance constraints that occur in the WSGI server.

50:32 So that's where we really encourage people to focus on what their use case will actually be, because that's really the numbers that will, at the end of the day, matter.

50:42 So you can do great things, and they can be extremely fast.

50:47 It just really depends on your configuration and your use case, because the benchmarks that we ended up doing were primarily to illustrate overhead within the framework themselves.

51:01 And, you know, to show that kind of, this is where we sit from a, how much load the framework has on the entire process.

51:11 So the theoretical maximum currently.

51:14 Right, yeah.

51:15 If you did nothing, you could maybe get this.

51:17 Yeah, and it's also worth pointing out the PyPy one, where, as I said, the CPython one was at 30,000 requests a second.

51:24 The PyPy one is 345,346.

51:28 So that's a really dramatic increase.

51:31 One of the things I know, I've definitely used PyPy quite a bit in more larger scale caching services.

51:39 And the higher performance nature of running Falcon under PyPy has really saved, you know, saved the situation, so to speak.

51:50 Yeah, that's really cool.

51:51 Another piece of advice you guys have is to use, is it micro JSON, UJSON?

51:56 If you're using CPython, because it'll speed up the serialization and query string parsing and stuff.

52:02 But skip it on PyPy, because otherwise it'll have to fall back to c types, because micro JSON, I'm guessing, is partially implemented in c.

52:10 PyPy has been historically at a bit of a disadvantage when it comes to c types.

52:15 And they've been getting a lot better at that, so we'll see where that goes.

52:18 But if you're using Python CFFI, it works a little bit better, better optimized for that case.

52:24 This just kind of goes back to the tradeoffs, right?

52:27 I mean, there are a lot of nice kind of drop-in replacement libraries you can use that are highly optimized.

52:33 But make sure you go and look at actually how they're implemented.

52:37 They may be faster on CPython, but slower on PyPy.

52:42 Yep. Measure, don't guess, huh?

52:43 Yep.

52:43 John, how about some notable users or deployments?

52:46 Yeah.

52:46 So there are, we've got quite a few people from various organizations.

52:52 You know, people from, you know, LinkedIn, they have a few open source projects that use us.

52:57 EMZ, obviously, since I was there.

53:00 OpenStack.

53:01 Wargaming, which for people who are in the gaming world, I believe they do use us for certain aspects of World of Tanks.

53:09 Oh, that's cool.

53:10 Rackspace, obviously.

53:11 In fact, I think there's a talk that was done by some of the warm gaming people in Russia over some of their usage.

53:19 Yeah, we've got a lot of people.

53:21 I think last time we checked, we get it for stats are a good thing.

53:26 And I think we get around 50,000 something downloads per month with PyPy.

53:33 That's awesome.

53:34 A lot of people using it in various circumstances.

53:36 I guess you...

53:37 A lot of people using it for internal things.

53:39 Yeah, they're not going to talk about it probably.

53:41 Yeah.

53:42 There's also everyone using Hug in a sense, right?

53:44 I guess.

53:45 That's actually one of the kind of very interesting things about Falcon and his current position of having someone like Timothy coming along and building a framework on top of us.

53:57 We don't necessarily get the advantages from a download perspective.

54:01 But we get users by proxy almost, which is very interesting.

54:06 Yeah, and probably improvements made at your level by way of that framework also help you.

54:11 Definitely trying to understand some of the use cases that occur in a framework like Hug definitely help kind of inform some of our decisions.

54:21 It helps us...

54:23 It almost helps keep us honest going back to the whole continuous integration.

54:27 It's great to have almost like a classic use case that we can test against.

54:33 Yeah, that's really cool.

54:34 All right, gentlemen.

54:35 I think that is all the time we have to talk about Falcon.

54:38 But let me ask you the two questions I always ask at the end.

54:42 And Kurt, I guess I'll start with you.

54:44 Favorite editor, if you want to write some Python code, what do you open up?

54:46 So I live and breathe in Sublime.

54:48 It's kind of my working horse editor.

54:51 So I used to, years ago, I used to be more of an IDE guy.

54:54 But I've kind of taken the pragmatic programmer's advice to heart and tried to find something I can use that's a little more versatile.

55:01 I can kind of use for everything.

55:02 And then I don't have to context switch with my brain.

55:06 Yeah, makes sense.

55:07 So it's a nice mixture between having access to a lot of keyboard shortcuts and whatnot.

55:11 But I can also kind of use my mouse for certain things that are more efficient that way.

55:16 Sure.

55:16 John?

55:16 NeoVim.

55:17 I am one of those Vim people.

55:19 All right.

55:19 Awesome.

55:20 And notable PyPI package.

55:23 What do you guys want to recommend?

55:25 Kurt, go with you first.

55:27 Oh, sorry.

55:27 Go ahead, John.

55:28 One of the ones I like to recommend is the testing.libraries.

55:32 A lot of people, they talk about having to mock up database interactions or, you know, when they're trying to test their API.

55:40 Whenever there's a Python package that will actually, on demand, set up a local instance of like Postgres or Redis or MySQL.

55:50 And then tear it down as a part of your tests.

55:53 And you can eliminate a lot of testing burden just through those packages.

55:59 So I'm a big fan of them.

56:00 Yeah, that's really cool because sometimes mocking out the data layer is just like so much work for that tradeoff, you know?

56:06 It is.

56:07 And you also need to test your migration.

56:08 So it's great for that.

56:10 Yeah, cool.

56:10 We mentioned UVicorn a few times.

56:13 That's Tom Christie's kind of new baby.

56:16 And he's doing some impressive work over there.

56:18 So I invite everyone to check that out.

56:20 He uses the MagicStack HTTP parser and AsyncIO drop-in.

56:26 Some pretty impressive performance numbers out of that.

56:29 Some interesting work.

56:30 So check that out.

56:31 Yeah, it's cool.

56:31 It's based on UVloop as well, right?

56:33 Yes.

56:34 Yep.

56:34 And probably just another one.

56:36 I want to give a shout out to Brian Warner's Magic Wormhole project.

56:40 I think he gave a talk at it a couple years back at PyCon.

56:44 But it's just a really clever, easy way to securely ship files from point A to point B to send something to a friend.

56:51 It's like on-demand Dropbox from the command line with a one-time code thing.

56:58 Yeah.

56:58 I mean, whether or not you even care about the security, it's just a really slick way to ship files.

57:04 So check that out.

57:05 All right.

57:05 Yeah.

57:05 Good recommendations, you guys.

57:06 Very nice projects.

57:08 All right.

57:09 Final call to action.

57:10 People want to get started.

57:11 What do they do?

57:12 Go check out falconframework.org.

57:14 It just gives you a quick overview of the project, has links to GitHub, has links to our Gitter channel.

57:22 We have a couple channels there.

57:23 There's a user channel for just getting started, asking questions.

57:28 We have a dev channel for contributors.

57:30 And, you know, check that out.

57:32 Once you get playing with the framework, if you run into any issues, reach out to us.

57:38 We're always happy to help.

57:40 And we're always looking for contributors, certainly.

57:42 So of all levels, we're happy to help you get started there as well.

57:46 All right.

57:46 That's great.

57:47 Yeah, definitely a cool project to get involved with.

57:49 A lot of people ask about what open source project they might get a chance to, you know,

57:53 they want to do their first open source thing.

57:55 This would be a fun one.

57:56 If you're interested in kind of learning the fundamentals of the HTTP protocol,

58:01 which is a surprisingly complex protocol, you know, it's a good way to kind of get under the hood

58:06 and see how it all works.

58:07 Yep.

58:07 Sounds great.

58:08 Thank you guys for being on the show.

58:09 This project is really, really interesting.

58:11 I'm glad to see it being successful.

58:13 Awesome.

58:13 Thank you.

58:14 Thanks a lot.

58:15 This has been another episode of Talk Python to Me.

58:19 Our guests have been Kurt Griffiths and John Verbonic.

58:22 And this episode has been brought to you by Linode and Datadog.

58:26 Linode is bulletproof hosting for whatever you're building with Python.

58:30 Get your four months free at talkpython.fm/Linode.

58:34 Just use the code Python17.

58:37 Datadog gives you visibility into the whole system running your code.

58:40 Visit talkpython.fm/Datadog and see what you've been missing.

58:45 Don't even throw in a free t-shirt for doing the tutorial.

58:47 Are you or a colleague trying to learn Python?

58:49 Have you tried books and videos that just left you bored by covering topics point by point?

58:55 Well, check out my online course, Python Jumpstart by building 10 apps at talkpython.fm/course to experience a more engaging way to learn Python.

59:03 And if you're looking for something a little more advanced, try my Write Pythonic code course at talkpython.fm/Pythonic.

59:11 Be sure to subscribe to the show.

59:13 Open your favorite podcatcher and search for Python.

59:15 We should be right at the top.

59:16 You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.

59:26 This is your host, Michael Kennedy.

59:27 Thanks so much for listening.

59:29 I really appreciate it.

59:30 Now get out there and write some Python code.

59:32 I really appreciate it.