Transcript: Django's Async Future - Tom Christie

I'm Carlton Gibson, joined as ever by Will Vinson.

How are you, Will?

How are you, Carlton?

And today we're joined by a very special guest, Tom Christie, creator of Django Rest Framework.

And well, you've you know who he is.

Hey Tom, how are you doing?

Oh, pleasure.

Let's just as a broad structure, I gotta ask you about Django Rest Framework, and then really want to talk about ENCODE and async and the future of all that.

Um but maybe before we get to that, so how did you learn how to code?

Because you're doing some really cool, almost like bare metal programming type stuff with async.

And I know you you have a formal background in computer science, is that right?

Mm-hmm.

Um so I started out the way I guess quite a lot of people who are my age who are in the programming industry did, which was writing games for a ZX Spectrum and doing a bit of, you know, basic programming there, and also on um on whatever thing, you know, the the Q Basic as well, wasn't it?

That was the the Windows DOS one, I think.

It came with snakes and something else.

Gorillas was another one.

Okay, both of you have

And you had to throw the throw it up and hit the other gorilla or building.

Because in the States we didn't have anything like that.

But I but um you know uh it it was kind of by accident trying to figure out well what are you gonna do once you get to leaving school age and just ended up doing a computer science degree and um I've I've worked in a few different areas kind of since then.

So I ended up moving into when I'd finished my degree, I then went and did a master's in computer speech and language processing.

It just seemed like an interesting area.

I was really interested in artificial intelligence at the time.

So I went and did that and um then worked in that area of the industry for a while, and then like most people who were on that small master's course with me, we eventually all ended up moving out of speech recognition because it was so it was such it's such a new domain.

Well, yeah, it's like in terms of where the money was at.

Yeah, it was too soon because it was right before, you know, that was all before Siri came along and you know, big boom and all of it.

But even so, I think it was always quite a difficult space to work in a way because it's only really with the mega corporations that and then you have this little research team and it's such a specialized area that you're working in.

Um personally, I found it quite frustrating eventually.

One of the few non-megacorps is speechmatics, which is I don't think a megacorp um but's based in the UK.

But maybe they're bigger than I think they are in terms of

I played around with transcribing our podcast, and it's like yeah, it's like Google, Amazon, you know, Microsoft, and then there's like a UK one, and they had a nice drag and drop option, not you know, configure an API to test it out and uh Yeah.

Sorry, I interrupted, please.

Um and then ended up slightly by chance, really, but ending up working in networking.

So worked with a content distribution network um who were doing stuff with peer-to-peer and building caches to live inside ISPs in order to save them traffic on all the peer-to-peer stuff that was going through their networks.

Um, did that for a while, and then eventually at the same time as I moved to Brighton, decided okay, I just want to have a complete change of stuff, and I would like to be able to again with both of those things, they were really, really kind of um but they were very deep technical kind of areas, uh, but I didn't know how to build my own website, right?

Or my you know, or just to do those sorts of things, and that freedom to be able to, okay, right, I know the basics of how to put stuff together and build stuff that I can do with, and eventually, you know, build up the skills that you can use to potentially build a company or do something like that rather than you know

Right.

I guess that the company that I was doing, that I was working with at the time must have been using it.

No, actually, I think they weren't.

I think they were using they were using Java, and that was massively frustrating.

But yes, had found Django.

Um, because it most of it is now.

And I've struggled to remember at what point uh switched over from bash scripting and Perl to, oh wait a minute.

This is really, really helpful.

Like this is much better.

I think it probably was, yeah, I think it I think it probably was after I'd left the speech recognition-y stuff because I can remember like some of the more impressive things that I did when I was there were very complicated sets of bash scripts and pearl strung together.

Because for all of the um with all the stuff where you're dealing with caught large corpuses of uh audio and you know, you need to do so much wrangling, basic wrangling with them.

You kind of got that stuff, and then you've got your like very detailed here's my bit of C that you know, does actually does the signal processing and pulls the the waveform out into a set of different signals that we can wife.

Because a lot of the scientific Python libraries are extensions around the underlying C implementations and stuff.

So it's it's not necessarily changed at the implementation level, even now today.

Possibly so.

I was just saying before we recorded your your talk at uh DjangoCon Europe this year on um async and future of Django was fantastic.

And you did a really good job of breaking down going a level deeper, level deeper on the layers of abstract abstraction that I think is often assumed because people work at their own um level, but given that you've jumped about a whole bunch of those levels professionally, it makes sense how you would be able to wrap it up together.

You sort of kept gone going up the abstraction layers in a way to um you know working with web stuff.

But anyways, we'll link to that talk.

I think for for people interested in async, your talk and Andrew's uh Godwin's talk, which we'll link to from DjangoCon this year, I think are the the two places I point people to.

Um so I I want to dive into that stuff, but did you what what else with your story?

So you were doing web stuff, and then at some point you did um Django West framework and then encode, right?

Should we finish the per professional?

What's the okay?

So what happened was basically there's this one big motivating factor.

I have no idea kind of where it came out of, but there was the idea was why on earth is it that out of all these APIs that we're building, none of them are web browsable.

Why on earth is it that when we're having to interact with our web APIs, we're having to do that from the command line rather than just being able to point a web browser at it?

Um HTTP is designed with content negotiation so that you can serve different representations to different kinds of clients so that a programmatic client could get JSON, but a web browser could request HTML instead.

And I had a couple of ideas about how you would do it because there were there were things that made it awkward to do.

So, for instance, browsers not being able to post JSON inside one of their regular forms.

I mean, this was a way back, so even where JavaScript was was a bit different then as well.

And it seemed to me such an obvious and such a beneficial idea that the web API should be web browsable.

That you know, I looked into oh, can I use one of the existing frameworks at the the time to do this?

And eventually went, no, I don't think so.

Let's just, you know, let's build, let's build a proof of concept first and show that you can do this thing.

And then it just kind of snowballed from there.

You know, it was the big like that was kind of always the big motivation because I thought it was such a you know, I thought it was an important idea.

I ended up wanting to pile more and more time into improving the framework so I could show people how I thought we ought to be interacting with APIs.

It the Browserbull API is still really cool.

You know, you fire up a new API and you go to it and it's like, oh yeah, great.

And okay, at some point, you know, you get nested serializers and all the rest.

It doesn't handle those.

Still, it's you know, it's still an awesome thing.

Yes.

And then if you need more, you can use Postman or or something, same way as you know, you shouldn't force your Django admin to do too much.

But it it just that first time experience of like you can see it and it works, it's you know, that's really, really powerful.

Um I mean, so for example, like in my my but my book um on Django APIs, I mean it's all using the built-in um web views.

And I say, you know, you can go to Postman, you can do all this other stuff, but really most of what you need, especially when you're starting out, it's just the first time first time I saw visually those things, actually.

I think that's the case for many people.

They they you know, because command line just doesn't do it.

So you you started with that idea rather than saying, you know, Tasty Pie or Twisted are the other ones, you know, the serializers w w were the issue.

You almost sort of started with the end goal there.

Is that correct?

Yeah, yeah.

It was um it was Tasty Pie and Piston at the time.

I used

That's why he's not on the scene anymore.

Right, right, yeah.

He's still sitting on a desert island feet off.

So, you know.

Wow.

Where it's so feature complete as is.

Where do you see what do you see as the future for that project?

And then we'll get into all these other projects.

Um like I I can't necessarily think of what more it needs beyond polishing, but um, you know, YouTube wrote and maintained it, so

Now if there if there is another big jump, I think that to me the obvious place would be so we have the we have an admin-like view in there at the moment, right?

But it's not great, it's not that great.

Um, and I think like the obvious place that you could put some improvements in would be making it so that rather than the browsable API defaulting to look like here's a bunch of JSON and here's some form fields, it's like, well, here's your tab for the JSON, and here's your tab for I want to see this data displayed in a table and be able to paginate through it with pagination controls and so on.

So, yeah, if there's another like big jump to happen there, I think that's probably where I'd be most interested in putting time in.

I was building iOS apps and I needed a back end with an API and a new Django, and I was playing with Taste DPI, and I was like, ah, this isn't working for me, and I found DRF and I was like, ah, this is working for me.

For me, still in that, still thinking about that environment, it's the to it's the integration with the open API tooling, the schemas, the client generations, and all that stuff.

And that can't be part of REST framework, really, but integrating with that ecosystem and making that more full fetched full um fully fleshed out.

I think that that's where the growth is for the over the next short term period at least.

Um, because I think that's you know, as a as a jobbing programmer, that's what you need.

You know, you need your API quickly, but you also need all these client libraries, and if you can produce decent docs and you know, code examples, and you know, and all that stuff.

Um one of your options is you use a completely hosted service, something like Firebase or something like that, and you build within their service.

Um, and you have to be happy to kind of live within the set of constraints that they provided and know that you're gonna stay on their platform indefinitely, or you go the other route and you work with a framework like Django or Rails.

Now I think a really nice space that's somewhere in the middle, which is you know, what's the easiest way to get put you know, express it like this like what's the easiest way to get started with Django?

So that's another area that I'm interested in working in.

Which is the which is um incredible that it even exists because Sphinx was the big beast in the room and you created this other thing.

Was it here's my burning question Was it just that you hated restructured text so much that you wanted to use Markdown?

Or was there another

Um, you know, and the tool and the tooling for Markdown was a lot better, you know, as well.

Like there's so many Markdown editors and still is and support for Markdown came to GitHub before support for restructured text and you know, all these sorts of things.

Um and yeah, it's you know, it's a trade-off.

Obviously, like you know, it's still all these years later, it doesn't have interlinking.

Um just pushed out a package that does um you know, you point it at your Python package and you can you can inject your uh your doc strings into your you know your markdown your price

Right.

But for muck docs.

So that came out last month, and we're using that so far with HTTPX.

Uh I can't remember if I'm using it in any of the other projects yet.

We'll put it in the show notes.

I can't remember.

We'll find it.

It's in the show notes.

I just

So you've just said the big exciting thing as well that you've mentioned HTTPX.

So tell us what that is.

So the gap that was missing was uh well two things in particular.

Number one, how do you, you know, what's the async HTTP client for Python?

So you know, with requests, you're using the the thread concurrency model, and you're generally only able, well, you're only able to open as many outgoing HTTP requests as you have threads running.

Whereas if you're using the asynchronous model, so and that might be, you know, say maybe 10 or or 20 concurrent requests.

Whereas in the asynchronous model, the make the process of making a request doesn't block all of the other little async tasks that are off running concurrently alongside your other one thread of control that you're looking at right now, and you're able to serve thousands of concurrent HTTP requests.

Now the big question was well, we've got requests at the moment, but how do we bring async functionality to requests?

So I put a bunch of time into trying to look at what would be a good way of doing that, and eventually that uh evolved into you know what, let's build a complete HTTP client from scratch all the way through, because we need to build one that is async capable up front and center, and also you know, like we're in a different landscape now than when requests started.

So let's start by building an HTTP client that uses type annotations all the way through, so it's very, very precise about exactly what the API is, and um and another big thing that it's started to provide is HTTP2 supports, right?

So uh there's there's one other kind of halfway incomplete Python HTTP client that supports HTTP2, um but there wasn't really anything and fully mature that had that in place.

So the two big things were let's look at async support and let's look at HTTP2 support.

Um what it's evolved into is a an HTTP client that is largely requests compatible.

So wherever possible the API meets up with requests.

Uh right now that means two things.

So we support async.io, but we've also just added properly support for the trio async library as well.

What's the difference there?

Async.io versus trio.

What's what's good no but you know, in 10 in 10 words, what's the difference between those two?

Uh so so trio is an alternate implementation instead of async.io and the big thing is is that uh yes, the trio people would bash me over the head because it doesn't use event loops or something, but um and it had essentially it's a more thoroughly designed, it's got this really nice core tenants called structured concurrency, which doesn't just apply to

There's a really thoroughly designed alternative to async IO.

It's a bit awkward because the two things are completely incompatible, but from the point of view of HTTPX, it's largely irrelevant.

We've got these two tiny little back ends, one for async IO and one for Trio, and we're able to support both of those uh yeah, both of those different platforms.

Um the plan is we what we did have, we did have sync and async support for HTTPX.

Um momentarily I've dropped out the sync support because we needed to re-engineer the way that that works.

Previously, the the sync code was kind of bridging onto the async code, so it would seem to the user like you're running synchronous code, but actually you've got an event loop running under the hood, an async code running underneath, and we're actually switching that round so that instead the sync version of the client will be a pure sync version of the client and the async will be a pure async one, and the folks working on who worked on

URL Web3, which is the thing that powers requests, have some really smart ideas about how to do that.

So we've been working on that basis.

But having looked at it, um async.io has this nice function called run, which you can just call from a synchronous context and you can pass it your coroutine, which will be your HTTPX get say.

Yeah.

So yeah,

Yeah and hope I mean I don't know when's the podcast coming out.

Sync and async client that additionally supports blah blah blah blah.

Right.

Now, so one thing that um I was sort of under the impression that um the requests, um, one of the things about requests is it was built on kind of some older tech which wasn't quite as robust, and then the underlying networking layer has kind of been redone and URL lib3 is part of that.

But all of that's a bit vague to me because I haven't dug into it and haven't researched it.

Could you what's going on there?

Like what's you know, URL lib3?

Is that is that what we need to be using?

And is is I don't know, what's going on?

How would you describe that stack?

Is it being rewritten or is it

Right.

Um I mean, we've already implemented a slice of it as well ourselves, but that's the mature battle-tested battle scars, um, you know, deals with all these different edge cases that they've hit in the wild when servers

in different ways.

So whereas we've got this kind of that this is clean, HCB works like this, this is what we expect version, it would be really, really beneficial to kind of have both those options on the table and be able to figure out where we're going from there.

But the the that's kind of underlying level that that layer underlying layer is being

They're working in the in the exact same space as us, and a whole bunch of the work that they've done.

So, for example, their approach onto how do you build code that is both sync and async is what we're now tacking for in HTTPX because it's smarter than the approach we had before.

It's gonna work out better for the project.

But it's because it you sort of have to rebuild everything for this new async world.

Like the design is is really nice, and I think folks kind of coming to it now and digging into the code base will be able to get a handle on oh right, okay.

I see how I mean that's kind of true for requests as well, actually.

But um, you know, we've kind of been stuck in this place where there's just this one entity and it's backed onto URL lib3.

It would be nice for us to freshen up on all that again.

HTTPX is is because it's like 0.8 now, is it?

It's um the word I mean uh like it's fully functional, fully you I could put it into a project, it does everything I need.

There's no because the 0 point, what does the 0 point, what's left for a 1.0 then?

Let's put it that way.

So you should pin to 0.8 or 0.9, you know, 0.9.x or 0.8.x, and the big thing that will still change is once we add sync support back in, then you've got to go.

Well, what are we calling the async client and what are we calling the sync client?

And what are we calling async requests and what are we calling sync requests?

like that.

Um, and once it hits 1.0, that's when we'll have the right.

Here's our uh formal deprecation policy, here's what you can expect to happen once we upgrade to version two in a year's time, or so on, all that stuff.

Um cool.

So let's just assume so ASGI, their async with um Web Service Gateway interface, we could talk about that, but let's assume that exists.

Starlet's really interesting to me, and you've also done some work building out, you've been putting the code um like a new demo project with it, I believe, right?

Um so this is let me tell you what I think it is, and you can correct me.

So this is you're building out so lightweight framework using ASCII that the ideas of which could eventually roll into a larger thing like Django itself.

Um is that how would you describe the motivations?

Because I look at it as like it's really educational for me, but um you know you have so many projects that sometimes I'm like, wait, what is Tom Word?

Like you've got like a dozen active projects that are all cool and all

Uh the async web stack includes, well, we need an async server, so here's UVCorn, that's your async web server.

We need an async web framework, so here's Starlet.

We need a way of interacting with async database drivers, that's at a nice level, so here's the databases package.

We need an ORM eventually.

I mean, so the ORM package, you know, that's kind of more on my horizon, but kind of got the basics in there.

So there's that bit.

Um and yeah, and one or two other bits and pieces around the periphery there.

3.1 is gonna have or 3.0 has ASGI, 3.1 is yeah, okay.

Um so you can embed, and what's useful about that at this stage is you can embed Django next to your dataset application or you know, next to your Starlet application, it's not actually async views.

So hopefully 3.1 will have async view capacity.

And for there, you know, from the Django perspective, Tom's work is like breaking new ground and it's showing the way to go, and it's like it's just amazing.

And Tom's talk from DjangoCon Europe, where it's he's it was called sketching out a Django redesign, and he but he spent the entire time talking about Starlet, not the entire time, but you know, basically was talking about Starlet.

But how else do you show what Django could become looking at other than showing what an async web framework looks like?

And that's you know, from the Django perspective, it's like it's it's it's amazing that this stuff's here, that the work that Tom's doing and seeing it, and we can take some ideas, and we won't be able to take it all because Django's got a lot of history, and it's always going to be it's it's Django and it's got to be backwards compatible, and it you know, so uh it it's a really exciting area, and there's plenty of room for Starlet and Django to rob all the good ideas, or as many ideas as we can, and it we won't be able to rob them all because Django's Django, and it's got a history, and it needs it

needs to maintain that.

Um 3.1 for async views, which is the bit I'm really excited about.

And the they end up being complementary, right?

So okay,

So for example, like we've got the baseline functionality in Django 3.0 of you can um you can be running in async right at the very bottom level.

Well, what that means, I mean I haven't dug into it in detail, but you'd be able to do some neat, you know, not stuff that you'll need to do all the time, but neat ideas like okay, well, we have this one particular this one particular case where we want this path to always just proxy requests off to some other service, and you could add in an ASGE middleware to let you do that.

You said, Well, what what is Starlet?

I'll describe it.

What do you think?

Well, actually, what Starla is is essentially um how would I start to go about designing the fundamentals of something like Django if I was coming to it fresh now from where we are now in the landscape.

That's not to say it's any, you know, of course it's not remotely at that level, but that's because, right, let's put these foundations here, let's put those foundations there, let's do this bit, let's do that bit.

And um, you know, because when I especially when I started working in the async space, you know, did things like, okay, well, I've got UVCorn and that's built here, but my god, you know, trying to build some production service on top of that, like what are all the other bits of work that I'd have to do to do that?

It seems immense and undoable, and I don't want to have to work with these async database drivers.

It's not my core expertise, so I don't understand how to do that.

But gradually, as we fill in more and more of the blanks, um you know, you're gonna start to see, you know, a more and more mature framework ecosystem there.

And it's about providing the the abstraction.

So you don't want to handle um ASGI send and receive handlers.

You want a handler that takes a request and you send back a response and you want the framework to do the send and receive to ASGI, and you don't want to look at that.

Yeah.

And yeah, the way that it's designed is it's it's kind of designed to be to be very lightweight, but without sacrificing the kinds of abstractions that you want to be working with at the framework level.

And one thing you've talked about about a lot is the importance of all this stuff.

Because we talk about async and it's all very, you know, but why does it matter?

How important is this to Python and Django and other frameworks?

So two of its biggest competitors in particular would be JavaScript and Go.

And both of those, when compared to the synchronous Python frameworks, are able to handle vastly higher levels of throughput.

So, you know, for each server that you're running, you're able to handle a certain number of active users.

Now that doesn't, you know, for vast swathes of businesses, that doesn't always matter.

But for the heavy hitters, it does.

And and also, you know, a lot of businesses that they're starting out and they're hoping, well, one day we want this to be, you know, and we don't want to have started out in a technology that we then find we're fighting against the current with.

You know, able to handle vast amounts of loads than JavaScript without having to make that argument.

Being able to say it's basically equivalent.

And of course it's not for Go, but the goalposts are shifted that much closer that it's not gonna matter to your team.

And so they're looking at yeah, those three Python, JavaScript, Go as the as modern current workforce can use.

Um and maybe because I flew I flew back from PyCon on the plane with a whole bunch of these people saying I was like, oh, why using Python?

Oh just for recruiting.

So it's almost you know, like but you know, of those those are the three kind of modern, I need something high performing.

Well, and really, yeah, people would say go, and then JavaScript is mangled.

So, anyways, it's an interesting perspective, and I think it's right that if you can just check that box, like again in your talk, you had great you you showed a bunch of benchmarks and kind of why they're not the standard benchmarks people trot out don't really matter.

Or are sort of incomplete, right?

I mean Carlton and I often talk in this podcast about how Python is not what you know the programming language is not going to be the thing that slows down your web stack anyway.

But even if you're looking language to language, it's it's easy to look at one of those and think Python's slow, but it's really

Because um WebSocket support, right, for instance, that's one of the big now Django has that with Django channels, but it's had to be kind of designed, you know, into an existing set, whereas with Yovicorn and Starlet, we're able to start from a starting point of great, we want to be able to handle long-lived connections such as WebSock or streaming HTTP requests.

Now, I know there's not necessarily loads and loads of good kind of tutorial level examples yet of look at the interesting functionality that you can start to easily build out with using these stacks, but that's gonna start to come, and I think that when it does, and when you start to be able to show, look, here's a production-ready framework that you can start working with now and um look

at the sorts of real-time things that you can start to build with it.

I think that will be interesting.

Um and the and the other thing is forgetting about the async at all, but just Starlet in its own right, I think, is really interesting because the you know, having had 10 years of working with Django, and right, how would I approach this from scratch, just the the way that it's stripped everything right down, you know, it's easy to say.

I think that people kind of get a feel for it when they've been working with it for a bit, but it's a very, very low depth of complexity stat, right?

And that's something that I can say nebulously and is difficult to you know, difficult to quantify, but it's a you know, I think it's a really elegant design, and I think that as the uh space on top of that starts to mature, that's going to kind of become apparent in the way that it allows you to kind of uh you know the the framework ends up having a low main

tenance cost so you can work on new things quickly, you can adapt new things quickly if you get things wrong, it's easy to move stuff around.

Versus okay, cool, we're supporting, you know, versus Django's completely different thing, which is supporting tens of thousands of businesses, and here's all the things we're carrying along with us, and we do a fantastic job of continuing to evolve and support them.

Um, but it's also worth putting time into great, here's this new sprinter on the scene, let's work with that for a bit.

And like Django's got 10 years of edge cases to uh you know to accommodate and to maintain and like that.

So no, but you can use the new version, you can update it and you can use the new features because you don't have you know, for I always argue that unless you're unless you're gonna really abandon your app, don't be on the LTS, be on the latest major version and get the new features and have fun with it.

I mean, yeah, you've got to update every nine months, but that's just like taking you taking your car to the garage.

And I guess I I want to mention to people listening, if they're more beginners, Jacob Kaplan Moss, one of the Django creators, his he had a PyCon talk 2017, which we'll link to on if he were gonna build Django today from scratch, what would he uh redo?

Um because I think when at least when I try to explain to like I work in a co-working space, there's a whole bunch of people using Django who aren't developers, so they're managing developers.

And when I try to describe async, I see their eyes uh glaze over.

And I think part of it is they don't they they don't understand how the piece is, what is the stack, what is a web framework?

Um, so you know, what is WISGI?

How did all these things stack together?

So um, you know, I think of this as an educator.

I want to write some courses on async, but I think it really has to start with well, here's all the things you were using you didn't have to think about, but like here's what the stack is, here are the choices.

Because I I think until you can understand why async beyond oh real time sounds nice, you have to see where what you're dealing with, and you a lot of people haven't.

Yeah, right.

Isn't this what your business wants to be able to do or to be able to build or you know to have your team work with?

Um you know, and I'm hoping to be able to get into that much more user-facing space.

Because I think of well, maybe it's like what is you know, something you build the sync way and the async way, and you can just show it's massively more performant.

Is there like uh I mean it's like oh chat seems a little bit faster, like what would be a good, you know, killer example, right?

Like what's the like equivalent of like um

So a real-time admin plus uh oh and look, here's a bit of JavaScript that we've written on the other side, and here's a website where we've got these various kinds of graphs that are updating, and we can see when we put, you know, either when we're putting data into the admin, we can see that stuff updating over here.

Or here's a simpler example, right?

So um being able to when you when you start up Django, right, and you get your little welcome screen, and then you've added in the admin and you get the admin, right?

What would be what would be really nice in async framework land would be once you've started your new project and you go to a screen, you can see uh like a real-time graph of how many requests per second are we running at the moment, and it's updating all the time.

What's our throughput?

How many servers are running and currently connected to the same channel at the moment to be able to see really responsive set of information like that and have those be in your basic programmers toolbox.

So, you know, rather than Django debug toolbar is the thing, is the kind of level that we're looking at, you know, responsive set of information that's coming back straight away about you know, those sorts of things.

And they've kind of got that nice.

And it'd be nice if Starlet had that, it'd be nice if Django can get there in its time.

And you know, for me, you start, you've got you take a beginner and you run them through and you create a Django model and they start and they spin up the admin and they do imagine doing that, but just with with an async framework where where you know they don't even know about its async, they're just building something and they're and all of a sudden it's like they're programming and they're learning to program, but using this this really cool modern async stack.

Fantastic.

Yeah.

With oh, I think that the async web space in Python is really important, so here's the async web stack, right?

Trying to balance those things and trying to make the case for, you know, especially with in places where stuff is newer, trying to make the case for yes, this is less mature.

No, your business shouldn't necessarily be working on this yet, unless you know that you've got a good reason to.

Um, but yes, we think it's worth investing the time up front on.

What's that?

The tag sustainable software development, right?

That's that's how you

But it but

Yes, that that that that chimes.

How on earth can you do it?

And you know

I work on this stuff full time.

Actually, I think it's interesting going back into the story of how that happened to come about because it's quite lucky, really.

Um, you know, Django Rest Framework 2, version 2, was when we very first ran a Kickstarter for it.

And at the time I was working with the web consultancy Dab apps, and they were really on board with the idea of running a Kickstarter for this.

So we kind of came to an arrangement where we said, okay, we'll do a Kickstarter, and you know, we'll figure out for however much money the Kickstarter makes, here's how much of my time can be taken out of client projects and instead just be put to working on Rest Framework.

And we we ran the Kickstarter and it was wildly successful, you know, for Rest Framework 2.

I can't remember how many how long ago that was now, but

People could see, you know, what we wanted to do.

It uh it was kind of it just about started emerging as you know, like the more mature, like for a long time, Tasty Pie had been overall the kind of the the slightly better choice in terms of if you just want to look at what features have they each got, but the timing just happened to be just right.

Uh you know, we got like 30,000 pounds from the Kickstarter, and I worked on Rest Framework 2 for I can't remember, but you know, between six months and eat and nine months somewhere in that area, which was fantastic.

When we came to okay, here's a new slice of work that I think needs to happen, and Rest Framework 3.

Um, again, we got pretty lucky with the timing because Mozilla had just launched their grants scheme, and I knew that although I wanted to run a big kind of initial fundraiser for it, what I actually really wanted was ongoing funding rather than a single Kickstarter style drop work, work, work, now we're done.

And it wasn't really obvious to me that leaving my job would be a good idea or not.

But because I'd applied to the moss grant, the way it went was once that grant, you know, once they came back and said, Yep, here you go, here's your grant, which I think was about fifty, I think it was fifty thousand dollars, I think it was thirty thousand pounds again.

So that gave me this huge chunk of runway, you know, like best part of a year.

And I said, Okay, like Tab Apps is a great place to work, but I can see an opportunity here.

So I I quit and launched the um the ongoing funding model, and I thought, well, we'll wait and see how many companies pitch in with this and what kind of level it gets to, and if it's 50% of what I need, then at least I'll know, you know, I'll have a year's worth of figuring out, and maybe I can go back to DabApps and work there, you know, half time or whatever.

But as it happens, we just about got we've just about got enough to keep me going full-time on things.

And sometimes we've had a bit more, and sometimes Carlton's had contract time on it.

Uh, sometimes in the past, I've supplemented it with a little bit of contracting and so on.

But on the whole, I'm trying not to do any of that at all and just use the funded time.

And and the pitch that I that I always go with if I'm ever on stage talking about it is um, you know, I want to work for your company full-time for a hundred dollars a month.

Because that's that's what the case is.

That's and it's so clear then why collaboratively funded open source development makes economic sense, right?

Like, you know, you make a subscription to keep the the fundamental infrastructure of your business.

There isn't a there isn't a person listening to this podcast who doesn't use REST framework, right?

So you know, if if if all those people fund it a little bit, if all those companies fund it a little bit, then it's totally sustainable on the ongoing basis.

I think too, it's easier for people to understand that DRF is is you in a small team, whereas I mean I'm constantly struck by Django as just this amorphous thing, even though it is a half dozen, dozen people who really do the yeoman's work, um it's a little bit easier in a way when you can people can say, oh, it's it's going to Tom and his crew, right?

It's not I don't know, it's a little bit even easier to ask.

Because I think of this in the context of I'm constantly thinking for the uh Django Software Foundation, I think there's a lot of ways they could get more money, which would help a lot of things.

Um but it's a little bit harder than when you're literally on stage saying, you know, I want to work for you for a hundred dollars a month, and it's just like, man, if I'm using DRF for anything as a business, that's uh obviously a total no-brainer.

Because I think it is a personal relationship.

I mean, you know, I I think there's probably more that we could be doing in that space as well.

That um, you know, so for instance, things that I've kind of toyed with in recently is well, it would be great to get some more to get somebody else in with a bit of funded time on the project.

Well, maybe the right sort of way to approach that is you you have a a mente uh a mentorship program and you specifically ask for, you know, we want to run this program and we we need three companies to sponsor it.

Yeah.

And here's how much we expect you to pay.

And then it's a very direct relationship.

You know, they can say we're sponsoring this program that person.

They want to I mean it's like giving to you know, university.

You want your name in the building versus just general fund, right?

Everyone wants to point point to their specific thing.

I mean, because I think again in the in the Django context, I would posit that 95-99% of people have no idea who that a Django fellow exists, let alone that there are two, let alone that Carlton is one of them.

I mean, it's just totally the DSF, I d I nobody knows what that is.

Because they don't really have to.

Um, so it's and it's uh I like the your idea of direct relationship from mentee.

I mean, well just this just this year, um the DSF with uh Jacob Kaplan Moss is mentoring someone on I think what adding something to the funding page.

They got a thousand people uh you know who wanted to be mentored.

Um and that and I think if you had a a company that would sponsor that or something, yeah, that's brilliant.

That makes a lot of sense.

It's it's like a badge that a company can talk about and yeah, have a, as you say, a direct relationship between their funding and what they're getting out of it.

Whereas that's more difficult with a commu you know, something where there's a bunch of different people who are all kind of equally responsible for the health of the project to go to to make very like direct decisions about you know what, let's put the funding up front and center and let's be very direct about this, you know.

Those conversations can be more complicated.

Yeah.

Which I mean, this is like I I, you know, uh being by far the newest to this community of the of the three of us, I keep getting struck by first it's like, wow, it's this amorphous thing, and then I'm like, oh my god, it's so fragile.

Like, I mean, Carlton's given some talks to this more.

There's there's there's Marius, there's myself, there's half a dozen people who are very active, and then there's you know, 50 people who are kind of active, and then that's it.

That's that's it.

And you know, people will email the Django developers saying the Django team, and it's like, well, really that's you if you step up.

Uh it's you know, there's a lot of places where there's these core bits of in Python or any other bit of the space where there's something absolutely critical and it's one person sitting in their garage, you know, every now and again who's working working on it out of love.

Yeah.

Open source.

I mean, there will be a couple thousand people listening to this, and you know, it'll be there for posterity.

Okay, well,

come back in six months' time and I might have something different to say to that question.

So we'll see.

Okay, great.

So please do check out all the packages and stacks that are being worked on.

Yeah, I'm not often uh I think yeah, over in the States.

So it would be really wonderful to chat with loads and loads and loads of people there, because um, like I say, I'm not over that way much.

They've publicly announced it's in um Porto, Portugal.

Are you gonna be there?

I think I'm gonna try to cross over the pond uh for the first time.

I'm really excited to

So we can cut that bit out.

And listen, from uh us and from the whole Django community and beyond, thank you so much for all the contributions you give and all the work you've done.

You're just you know, superhero.

Thank you, Tom.

Join us next time, folks.