Transcript: Django's Async Future - Tom Christie (Ep46 Replay)
Hi, and welcome to another episode of Django Chat, a weekly podcast on the Django Web Framework.
I'm Carlton Gibson, joined as ever by Will Vincent. How are you, Will?
I'm great. How are you, Carlton?
I am marvelous. And today we're joined by a very special guest, Tom Christie,
creator of Django REST Framework, and well, you know who he is. Hey, Tom, how are you doing?
Oh, pleasure.
Thanks for coming on.
there's so many things to talk about let's just as a broad structure i gotta ask you about jenga
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? Yes yeah 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 cube 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
no no gorillas is where you threw the bananas right and you had to throw the throw it up and
hit the other building with the source code so you could go and have a look and then try and
figure out how do i turn that into a flying triangle instead or yeah i thought you're
going to talk about we had nicholas tollerby on talking about the what's carlton what's that
british thing that you all did the bbc the bbc micro did you did you play around with that as
well tom because in the states we didn't have anything like that no no no that was not a thing
But, you know, it was kind of by accident trying to figure out, well, what are you going to 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 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 too soon domain
well yeah it's still 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 a big boom in all of it
but even so i think it's always quite a difficult space to work in a way because it's only really
with the mega corporations 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 so
well there is and sorry i just because i know that um with current options there's for doing um
audio to text one of the few non-megacorps is speechmatics which is i don't think a megacorp
um but it's based in the uk but maybe they're bigger than i think they are in terms of i don't
i don't i don't follow that scene anymore so 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 yeah sorry
i interrupted please no that's okay 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 but i didn't know how to build my own website right or my you know or just
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.
The backend stuff.
And when I started, yeah,
when I started kind of working in the web industry,
that was, you know, I guess about a year later
was when I started working on REST Framework.
Right, and so did you find Django at that point?
Yes, 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 i had found
right so i went looking for jango right to corral them into look we should do more of this stuff
because that stuff's really painful for me well and was the the natural language things was that
in python um because most of it is now um so was python around when you're doing your degree
it it certainly wasn't very big on the scene right and i've struggled to remember at what point
i switched over from bash scripting and pearl 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 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 large corpuses of uh audio
tagged words you know you need to do so much wrangle 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 right you know
actually does the signal processing and pulls the waveform out into a set of different signals that
we can yeah and that's still the case though right because a lot of the scientific python
libraries or extensions around the underlying C implementations and stuff. So it's not necessarily
changed at the implementation level even now today. Possibly so. Well, that background actually,
that makes a lot of sense. I was just saying before we recorded your talk at DjangoCon Europe
this year on 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 abstraction that I think is often
assumed because people work at their own 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 going up the abstraction layers in a way to 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
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 want to dive into that stuff but did you what else with your story so you were
doing web stuff and at some point you did um jingo s framework and then encode right should we finish
the professional yeah so what's the origin what's the drf origin story what's okay yeah sure 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 from 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 but even sending non-post requests you know to
send a put or a delete you know the http verbs are available forms themselves don't natively support
it right and i had a couple of ideas about well look here here are different ways that you could
get around that 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 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 and the browsable api is still like you know i don't know how many years
later now so seven eight nine years later perhaps the browsable api is still really cool you know
you fire up a new api and you 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 but for get up and
running it's like oh wow this is super and i don't have to crack open the command line and i can play
around i can create some models and still it's you know it's still an awesome thing yeah i mean
obviously you know i think there are nicer things that we could be doing with it but um time and
time and effort yes well there's i mean it's a great for i mean i think of a lot as the admin
for django itself where it just works it's fantastic and you get it out of the box and
then if you need more you can use postman or something same way as you know you shouldn't
force your django admin to do too much but it's just that first time experience of like you can
see it and it works you know that's really really powerful i mean so for example like in my my book
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 the command line just doesn't do
it yeah well having having the immediacy and the accessibility of it but that's interesting you
almost worked backwards so you you started with that idea rather than saying you know tasty pie
or twisted or the other ones you know the serializers were the issue you almost sort of
started with the end goal there is that correct um yeah yeah yeah definitely yeah yeah it was um
it was tasty pie and piston at the time i used tasty pie i never used piston i should well i
should have done what jasper noah the the author of piston did which is found bit bucket and then
sell that to atlassian for who knows how much that's why he's not on the scene anymore right
Oh, yeah, he's still sitting on a desert island feet up.
So, you know.
Wow.
Well, so Django has frameworks.
So 3.11 is coming out.
Well, it will be out by the time this is released.
It's so feature-complete as is.
What do you see as the future for that project?
And then we'll get into all these other projects.
Like, I can't necessarily think of what more it needs beyond polishing.
But, you know, you two wrote and maintain it.
yeah so at the at the moment i would say it's just in its mature phase 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 that's kind of interesting i mean there's also you know there's
also i guess yeah yeah that's that's where i'd be most interested right because there's someone who
users DRF for building projects in the commercial environment have done you know it's how I found
it I was building iOS apps and I needed a back end with an API and a new Django and I was playing
with tasty pie and I was like this isn't working for me and I found DRF and I was like this is
working for me for me still in that still thinking about that environment it's the 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 fully fleshed out,
I think that that's where the growth is
for over the next short term period at least.
Cause I think that's, you know, 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,
the other area that i'm particularly interested in as well is you know at the moment we have that
what you have if you if you're coming to a new project and you want to build an api
you've got two different slices of option and 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 going to stay on their platform indefinitely or you go the other route and you
work with a framework like django or rails now i think you have to host your own 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 oh well start building your
admin and your api out in this hosted service here and you can put some you know you can start
putting data in and so on and you can start interacting with it as an api and when you're
ready here's this big green let's go button and you hit that and you've got your code and you're
ready to start running that so that's another area that i'm interested in working in so the
other big project that you was around right at the beginning was make docs right which is
which is incredible that it even exists because sphinx was the big beast in the room and you
created this other thing was it is my burning question was it just that you hated restructured
text so much that you wanted to use markdown or was there another no it's just i enjoyed working
with markdown so much um you know in the tour and the tooling for markdown was a lot better you know
as well like there's so many markdown editors and yeah um and support for markdown came to github
before support for restructured text and you know all 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 at your python package
and you can you can inject your uh your doc strings into your you know your markdown
your pros is this a wrap around around doc utils uh is it it's um it's a mcdocs equivalent of
uh is it autodoc that right okay this is an equivalent of autodoc but for mcdocs
so it'd be like creating api documentation yes it is yes placing api documentation within
your prose documentation 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 okay and what what's that
called for our listeners we'll put it in the show notes uh automac docs maybe i can't remember okay
we'll find it we'll find it it's in the show notes i'm using it now so i've forgotten the name
we're just okay abstracted away that's really cool so you've just said the big exciting thing
as well that you've mentioned httpx so tell us what that is uh yeah so actually i'll i'll start
from what was the motivation and then i'll kind of come to where it is now and what it is now so
the gap that was missing was 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 thread
concurrency model and you're generally only able well you're only able to open as many
the 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 20 concurrent requests. Whereas in the
asynchronous model, 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've put a bunch of time into trying to look at what would be a good way of
doing that and eventually that's 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 another big thing that it's started to provide
is HTTP2 support. So 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 so i can come along as a long-time request user i can get me import httpx i can do
my get and it'll be more or less the same yeah that that supports async 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 can we have a little sidestep what's the difference there
async io versus trio what's what's good no but you know in 10 words what's the difference
so so trio is an alternate implementation instead of async io and of like the event loop the big
thing is is that uh yes the trio people were bashing 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 tenets called structured concurrency which doesn't just apply to trio but
is a general idiom for that um that they've kind of discovered for look here's a sensible way
to deal with concurrency without having callbacks all over the place without potentially leaking
tasks that you forget about having uh you know well-defined semantics for what happens when
tasks are cancelled and so on. It's a really thoroughly designed alternative to asyncio.
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 backends, one for asyncio
and one for trio, and we're able to support both of those different platforms.
the plan is we what we did have we did have sync and async support for httpx
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 urllab3 which is the thing that
powers requests and some really smart ideas about how to do that so we've been working on that basis
right super and i was looking i've followed that conversation i was a bit um i was a bit like i
don't drop the sync support because i just want to be able to pull in httpx as my replacement 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 gets yeah and
it will it will on without you having to pull up your event loop and run the event loop yourself
it'll which is only a few lines but it'll do all that for you so yeah well it's not importantly
the sync support is coming back yeah and i mean i don't know when's the podcast coming out
well when do you want to come out yeah well anyway hopefully hopefully it's already back in
right yeah by the time you listen to this folks sync and async that additionally supports blah
right so hang on before we before we lose the thread here you just mentioned url lib 3 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 lib 3 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 lib 3 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 has it been
rewritten or is it so the uralib3 team are also working on a new version of that which brings
synchronous and asynchronous support okay and that's the underlying personally what i would
like to do is and i don't think is that difficult is provide the ability for httpx to be used with
that once that's available 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 service over the course of 10 years 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 so that's still a work in progress right but that's kind of
underlying level that that layer underlying layer is being yeah yeah 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 going to work
out better for the project well i think one of the things i took away from from your talk as
well tom for people listening who aren't or are new to this space is that async requires rebuilding
all the layers in the stack which is sort of why you know why is the rest framework person
working on http but it's because it you sort of have to rebuild everything for this new async world
yes but i you know um that's and that's certainly the motivation but what i hope as well is
um you know as mature and great as requests is i think it'd be really great to have a new
http clients that does all the same slice of stuff as it because i'm really pleased with the work
that we've done on http x 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 of three it would be nice
for us to freshen up and all that again and it's stable right httpx is because it's like 0.8 now
it's stable if you pin to no but what i mean is it's stable isn't the right word it's um the word
i mean like it's fully functional fully you i could put it into a project it does everything i
need is like because the north point what does the north point what's left for a 1.0 then let's put
it that way the big so yeah you should pin to a median release version so you should pin to
0.8 or 0.9 you know 0.9.x or 0.9.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 so maybe an import changes or something like yes you've got a name
space here and you've got to name it but there's not actually a massive amount more technical work
required to get there 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 2 in
a year's time or so on all that stuff so i really want to ask you about starlet um oh cool so let's
Let's just assume, so ASCII, their async 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,
like a new demo project with it, I believe, right?
So this is, let me tell you what I think it is,
correct me so this is you're building up 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 does tom work like you've got
like a dozen active projects that are all cool and all i've been trying to keep that more and
neatly corralled these days but do you i mean what you have i mean django rest framework httpx
asgi um uh uvicorn api star like yeah i mean there's kind of um there's kind of three projects
okay so there's django rest framework there's httpx yeah and there's the async web stack
the async web stack includes well we need an async server so here's uvicorn 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 and then carlton what's the schedule for django three
releases for how these things are added in right three one is going to have or three zero has
ascii three one is yeah okay so we so we've just released 3.0 and that that can um run under an
ascii web server so uvicorn or daphne or the other one i can never remember hypercorn um
so you can embed and what's useful about that at this stage is you can embed django next to
your data set 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 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 django con europe when it was called sketching out a django
redesign and 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 amazing that this stuff's here 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 and because Django's got a lot of
history and it's always going to be it's Django and it's got to be backwards compatible and
you know so it's a really exciting area and there's plenty of room for Starlet and
jango to rob all the good ideas or as many ideas we can and we won't be able to rob them all because
jango's jango and it's got a history and it needs it needs to maintain that um yeah 3.1
for async views which is a bit i'm really excited really nice has been being able to see how once
we've got a standardized approach ascii yeah you know andrew godwin's designed we're then able to
go off and i can go off and do a whole bunch of work in this kind of completely different approach
and different space and he can go off and do right how do we start to bring this into django
and they end up being complementary right so okay and mix and match right you can yeah yeah 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 ascii middleware to let you do that yeah using http x to make the requests
yeah and that's before there's it it just it starts to give you opportunities but coming back
to what will asked earlier actually because you kind of crystallized the answer to that in my mind
you said well what what is starlet i'll describe it what do you think well actually what starlet 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 exactly 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
you know because when i especially when i started working in the async space you know did things
like okay well i've got uvicorn 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 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 going to start to see you know a more
and more mature framework ecosystem yeah yeah 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 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 yeah that kind of thing yes yeah yeah and yeah the way that it's designed
is 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 yeah and one thing you've
talked 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
the space where it's important particularly is python's position within the landscape
right 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
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
and the intention here is to build up the kind of framework where you've got all of the wonderful
productivity benefits that working with python brings without having to make the case of it
doesn't matter that it's less you know able to handle vast amounts of loads than javascript
without having to make the argument being able to say it's basically equivalent and of course it's
not for go but the goal posts are shifted that much closer that it's not gonna matter to your
team yeah if you can get if you can get 95 performance you know that's probably good enough
so anecdotally here in boston i hear there's a fair number of enterprise java company stacks
that you know they're switching over to new technologies in part because they can't hire
java developers because no one coming out of school knows java and so they're looking at
yeah those three python javascript go 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 are you using python just for recruiting so it's almost right you know like but you know of
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 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 easy to look at one of those and think python slow but it's really so yeah so let's talk about
some other aspects of it as well though right because um web socket 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 existence whereas with you have a corn and starlet we're able to start
from a starting point of right we want to be able to handle long-lived connections such as web sockets
or streaming hcp 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 going to 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 look at those 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 will 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 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 maintenance 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 jango'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 involve 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 yeah
oh yeah no totally totally totally and like django's got 10 years of edge cases to
you know to accommodate and to maintain and rightfully so i and i always say one of the
reason why it's still exciting is because we don't break stuff so you know that it's still
going to be there and reliable so no but you can use the new version you can update and you can
use the new features because you don't have you know i always argue that unless you're unless
you're going to really abandon your app don't be on the lts be on the latest major version and get
the new feature 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 well so hosted api is the name of the the demo app
that um you built out and i guess i i want to mention to people listening if they're more
beginners jacob captain moss one of the django creators his he had a pycon talk 2017 which we'll
link to on if he were going to 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 um glaze over and i think part of it is they don't they don't
understand how the piece is what is the stack what is a web framework um so you know what is
whiskey 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 a real time sounds
nice you have to see where what you're dealing with and you a lot of people haven't see i think
the thing is the reason that we're having to talk about the technical aspects is because it's still
immature yeah right and what i've been working on really hard is and you know hosted api is just
like kind of the very right let me figure out what we're still missing is until you can get to the
point where you can put your technology in front of people that really don't know an awful lot
about the space and say, hey, look at this cool thing. 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? You know, and I'm
hoping to be able to get into that much more user facing space. Well, what do you think that example
is right 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 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 so a real-time admin right 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 kind 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 so kind of what hosted api is no you know maybe one day i'm skirting around you know
bigger plans or here's a simpler example right so um being able to when 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 in the in the phoenix web framework which is in
which is built on the elixir language which is kind of like a functional thing built on the
earling vm they um they've got a thing which is really the new hotness at the moment called light
which they call live view which is exactly this kind of real-time communication back to the server
and they can do you know inline validation send back the response updates in line and it's it's
like ajax but ajax plus plus plus plus plus because it's so quick and you know and really easy to
implement and they've kind of got that nice and be nice if starlet had that be nice if django get
can get there and it's time and you know for me you 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
imagine doing that but just with with an async framework where you know they don't even know
about it's 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 one of the things that is difficult though of course is trying to balance
that you know trying to balance django rest framework with okay i think that the
revitalizing the http space in python is really important so here's httpx
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 and so we come to the final
and perhaps most important topic is encode oss and your work to build the tagline what's there
sustainable software development right that's that's how you uh yes yeah it could be well
perhaps it was once upon a time but it was collaboratively funded software development
is what it is there you go yes that that that that chimes because like we've we've mentioned
what a dozen packages drf starlet h uvicorn you know httpx how on earth can you do it and
you know well yeah and there's a there's a short answer to that is uh my time is fully funded 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
two version two 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 he 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 work 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 it was a way back because i i it
would i got involved with rest framework before version 2 but it was like it was coming along and
there was the kickstarter and it was it was years ago yeah and i think you know the timing happens
to be just right people could see you know what we wanted to do it was kind of 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 and 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 eight 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 50 i
think 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 dab apps and work there you know
half time or whatever but as it happens we've 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 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 it's like an insurance makes business sense
yeah it's like one of these plans to service your boiler 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 res framework right you know if if all those people
fund it a little bit of all those companies fund it a little bit then it's totally sustainable on
the ongoing basis yeah i think too it's easier for people to understand that drf is is you and
a small team whereas i mean i'm constantly struck by django is 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 see oh it's it's going to tom and his crew right it's not i know it's a
little bit of an easier ask because i think of this in the context of i'm constantly thinking
for the 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
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 obviously a total no-brainer so i think yeah i think it's i think
it's really important that there's a very direct link between sponsorships and um the person doing
the work 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 recently as 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 mentee 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 buy and then it's a very direct relationship you know they can say
we're sponsoring this program right that person i think that is what they want at a corporate level
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 to their specific thing. I mean, because I think, again, in the Django context, I would posit that 95, 99% of people have no idea 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, nobody knows what that is because they don't really have to.
So it's – I like your idea of direct relationship from mentee.
I mean, just this year, the DSF with Jacob Kaplan Moss is mentoring someone on adding something to the funding page.
They got 1,000 people who wanted to be mentored.
And I think if you had a company that would sponsor that or something, yeah, that's brilliant.
that makes a lot of sense it's like a badge that a company can talk about and yeah have it as you
said a direct relationship between their funding and what they're getting out of it well it's a
lot easier for me and rest framework to be able to tackle that sort of thing because i can just
be very unilateral in how i want to approach funding right whereas that's more difficult with
a commute 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 jango's a big ship it takes
a while to turn you know yeah but and yet it you know if you go to a django con in the u.s or europe
or now Africa next year, I mean, it's still a small number of people
who really make it happen, which, I mean, this is like, you know,
being by far the newest to this community of the three of us,
I keep getting struck by, first it's like, wow, this is amorphous thing,
and then I'm like, oh, my God, it's so fragile.
Like, I mean, Carlton's given some talks to this point.
Django isn't, you know, this big organization.
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 well and it's true in so many places as well right
it's you know there's a lot of places where there's these core bits of
you go 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 yeah well as we wrap up is there anything else you want to mention highlight i mean
there will be a couple thousand people listening to this and you know it'll be there for posterity
uh no just hi
come back in six months time and i might have something different to say to that question
so we'll see okay great we're gonna have links to all the stuff encode everything uh in the show
notes so please do check out all the packages and stacks that are being worked on i'm also i'm
hoping to go to pycon in 2020 which is not something i do very often yeah i'm not often
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 i'm like i say i'm not over that way much so and and but you'll
be at um django con europe they've publicly announced it's in um porto portugal are you
gonna be there i haven't figured that out yet okay sorry to put you on the spot i think i'm
gonna try to cross over the pond uh for the first time i'm really excited to yes no i've been in a
bit of a squish at the moment so okay we can cut that bit out pretty much down okay so tom thank
you so much for coming on the show and listen from us and from the whole django community and
beyond thank you so much for the contributions you give and all the work you've done you're just
you know superhero thank you that's a pleasure yes thank you tom and this was django chat join
us next time folks