Transcript: Async Django - Andrew Godwin

Hello and welcome to another episode of Django Chat. This week we're joined by Andrew Godwin

to talk about all things Django. I'm Will Vincent, joined as always by Carlton. Hey Carlton.

Hello there. Hello Will.

And hi Andrew.

Hello, good to meet you.

Yeah, thank you so much for being on. This is really exciting because you've been responsible

for many cool things in Django in the past and are currently working on really the future

of Django so lots to cover around async and all the rest that you've done so maybe let's start

it off with can you quickly give us your background on how you got into coding and

Django in particular? I can yeah so like my first foray into coding was a little bit unusual I

started programming on a palm PDA a palm 5 to be precise there was basically this little sort of

basic app where you could like write basic programs and do little games like that's where I cut my

teeth coding um so that you know and i was one of those like annoying like early teenage coders

because of this was like 14 15 on holiday my parents in cornwall just coding in the caravan

rather than actually like doing any outdoor holiday things but then i'm not going outside

yeah exactly like also it's cornwall in summer it's never that it's sometimes nice it's a beautiful

place when it's sunny but there's a lot of rain too um but then i took from that went to some php

um so did a lot of php when i was sort of uh start university that kind of stuff and then i think it

was about 2006 i went to work for a company called torchbox um who are an agency in oxfordshire and

that's where i met simon willison and simon willison if you ever met him is an amazingly

enthusiastic person uh and he within i think two weeks had taken me from writing php to

writing Django which of course was very young at the time it was pre-version 1.0 and so that's

kind of my route into Django and then I've sort of worked with Django ever since I'd say at that

point but on and off like so Torchbox also where I wrote the first version of South and so it's

also my you know I think two summers later because I was doing summers there during university so I

do university during term time come the summer break I would then go and work at Torchbox for

few months um and i basically sort of released south and this is back when like russell was

still doing uh django evolution there was still like lots of options for migration frameworks

in django and i got this email from jacob who i'd never met and like vaguely heard of at this

point jacob captain moss that is he's like andrew like oh we've seen your release we're having a

panel at django con the first django con in silicon valley would you like to go and i was

like well i'm just a student i don't have the money to fly to america which i've never been to

and he's just like oh no it's fine like no the dsf will cover it like like we'll pay for you and

give you a scholarship to come out there so like and this is like i mean three or four weeks until

the conference so at four weeks notice i basically go okay and then book a ticket to america which

i've never been to fly out to silicon valley and like maybe the most alienating thing but then i

find this this wonderful community of people who are so supportive and that even that first django

con i think like settled me into django properly and that's really interesting that even at that

early stage the dsf still exists already existed and they were already you know sponsoring students

to come to conferences and i'm not sure if it's i my memory does not serve me well i know it may

not be in the dsf in its current form but like some version of something like like jacob was

like yes we can we can cover the costs for you basically and that's what got me out there right

fantastic so that's super and then that we heard tell that there was um some kind of celebrity

deathmatch panel um about migration frameworks yes i think uh it was it was me simon and russell

keith mcgee on stage uh doing this and like so i forget what simon's one was called so simon had

one that was my sequel only russell had the rather excellent um janga evolution and i had south and

sort of this like we did a little presentation we did a little chat but like through the years

that followed um south slowly became more and more dominant until eventually it sort of morphed

into the rewrite that became django migrations that are now built in so currently you're at

eventbrite yes what led you to there was it has it all been django or like many developers have

you done non-django things at various companies along the way yeah it's pretty much all been

django so like after after university i went to torchbox for a year or so i went then did some

freelance work and worked with a few different companies like global radio used to be running

Django that kind of thing and a few other small companies and then eventually I settled into doing

some contracting for lanyard which was a sort of event a site for discovering professional events

was the idea it's like here are all the conferences and you can follow your friends and that was run

again by Simon Willison so like my career and Simon's touch points along a lot of points along

the history and you just sort of follow him along really well not quite not quite but we I've worked

with him on and off for like 13 14 years now um and then like you know i enjoyed work contracting

a lanyard eventually someone offered me a okay short short divert here just before this i had

applied for a job at the british antarctic survey to be the on-site sysadmin at one of the bases in

the south pole and also in antarctica um halley six uh and unfortunately um i that was the year

that uh the bbc documentary series frozen planet had aired um and so the number of applications

that position went from two to about 40 and i got this very apologetic call from the wonderful

people at the antarctic survey going it's such an unusually good year and like any other year you

we would have hired you but there was somebody who was just more experienced than you we went

for him instead and so simon very nicely waited a week and then offered me a full-time role at

after after i missed out on my antarctica base position but then so suits suitable grieving

period well not quite but i i was very fond i still am fond of the idea like i better get a

chance i'm going down to antarctica um but it's it's not easy to do as you can imagine um but

then shortly afterwards like i would start working for lanyard and then in 2012 2013 something like

that um lanyard got acquired by eventbrite and i've been eventbrite ever since right okay and

you're still there and um so i mean and this leads into your kind of work on channels and the async

stuff because you would do a lot of the related to the work you do at eventbrite i don't know how

much you can say about that and but can you sort of talk about the evolution of the async thoughts

and the thoughts around channels and yeah for sure things like that as one of the things is like um

eventbrite has a lot of interesting challenges of django at scale um like these days especially

like it's just grown and grown over the last five or six years but interestingly very little of that

is async a lot of my work that is based on like seeing the challenges eventbrite faces and like

how would we tackle them like what is the best approach some of those ideas we have tried

internally at eventbrite some of those ideas are more like they doing things in a large company is

different to doing them on a volunteer project so they're better done on django and then maybe

brought in later in the future and but a lot of those do stem from like you know eventbrite has a

slightly unique traffic pattern and that it deliberately like we deliberately ddos ourselves

like multiple times a day because our model is we have these things that go on sale and everyone

arrives at once for that event like in e-commerce like normally e-commerce is like oh christmas is

terrible like thanksgiving or thanksgiving or black friday but everything else is quiet whereas

we just have like this very like gentle demand curve and then these massive spikes like a few

times a day as events sort of go on sale and so that's an interesting scaling challenge that some

of the things in async are particularly good at coping with so yeah it's sort of like black friday

a couple times every day right exactly but but much shorter and sharper and you get 20 seconds

warning which is always fun so we had uh simon on just a little while ago to talk a little bit about

some of these things and he mentioned how global eventbrite is so is that sort of a continuous

throughout the day thing then where like europe to america and asia or is it um does it matter

sort of the geographic range of where those spikes are or it's i mean yeah like as we get more global

it's the spikes spread out over the time zones as you can imagine um but there is you know i remember

it's still very heavily in europe and america as that's what they tend to construct but yeah like

it has started being like a world they happen at 3 a.m uh pacific time too right and like nobody in

the sf office is awake at that point but we have a wonderful madrid office now madrid might be around

like it's trying to it's trying to like make sure that you have global coverage but also you have to

just start to code to cope with those things at some point right like you you can't treat everyone

specially like well we just have to design for this we have to expect it um and we can't design

for it by over provisioning the entire site so that it runs at full capacity all the time and

just waste money so there's an interesting balance there that async really helps enable

but there's interesting questions i guess as well as about how fast you can spin up instances and

how you know what kind of lead time you know there's a spike coming so you you can spin up

instances in advance and then but then there's coordination issues so you must be using

kubernetes and have problems with ingress tables and all the rest we have we have a very curious

uh like i i can't talk too much about the actual infrastructure stack like i do work on that i'm

an sre i sort of like do sre architecture over there these days um but yeah like a lot of the

like spinning up servers on demand is a difficult proposition um especially so like our django app

it's it's in it's in or near the million lines of code mark um it takes 30 seconds to import

all the python modules into memory like they're just so there's just so many python modules that

just the import itself is slow and so like we even have that like cold boot problem of like well

it's a big app spinning it up takes a lot of time and we're trying to break it up and make it into

smaller pieces but it takes time to turn a monolith into into services right okay and um i saw i don't

know if this is something you've um come across or whatever but um i saw on the century um blog

that they were talking about you rewriting little elements in rust or something like that to make

it to get speed gains there is that something you might do as well i mean honestly is it rewriting

it in python is kind of in our strategy like like ventbrite's still a very heavily python company

and pretty much like the one case we needed to speed up like uh pi pi as in pypy gave us that

speed up right like it cost a bit more ram but like it made our our webhooks delivery like seven

times faster i think and so they're a place like if you need that trade-off you can still do it

within the python ecosystem i think there was one piece written in go but that's because it was a

time before async http in python was ready like so like we have a like a live seat map for you

the way you can see, like, here's the seat map of the venue,

and the seats, like, vanish in real time as people pick them.

So the whole thing is, like, live-streamed.

And that was written sort of four or five years ago

before WebSockets and Python and Async HTTP was a good thing.

And so that particular bit is written in Go.

So let's talk about channels, because I think a lot of this is,

as a Django educator, I get a ton of questions about this

because it seems sort of, like, sexy in the future of Django,

but I think most people don't really understand what it is.

Um, actually, I'm curious, could you give the backstory of Channels and kind of how that's

morphed over time to where we are today? Yeah, so Channels history actually starts

away from me. It starts with Aymeric Augustin, one of the Django contributors, and he is responsible

for things like the big transaction rewrite, for example. And Aymeric did a lot of work

quite a few years ago now on an attempt at doing WebSockets with Django. He has sort of a game

of life example where every cell ran its own socket and that kind of thing and i looked at

that and i talked to him a few times and i was interested and also at this point like migrations

was done i'd had a year or two clear of it so i sort of understood like i'd recovered a bit from

the burnout that comes with pushing yourself yeah as you can imagine and then i was like okay well

i want a new project what seems to be the best thing to do for janga like what is what is janga's

future and at that point websockets was the new kid on the block it seemed to be the thing everyone

unwanted and so i was like well okay like let's let's take a serious look at this and of course

as i did with south i was like well south succeeded by being a external project integrating into

django and then over time becoming very popular and eventually being merged in so like well let's

follow the same principle right and so i was like okay so channels is going to try and be this

separate um sort of third-party app uh except we're going to sort of fund it under the dsf's

auspices so um the wonderful folks at mozilla gave us a grant for i think 115 000 of all

thereabouts um to fund it uh for a year or so or year or two in fact ended up being and so like

that helped build it out and helped have the research and a lot of what channels is is basically

like how do you take asynchronous django and not touch it but somehow wrap asynchronous around it

So particularly for WebSockets, especially.

It doesn't really try and address asynchronous HTTP.

It's in there.

Like you can do it, but it's not easy.

It's not really designed for that.

It's much more about you want either normal, boring, synchronous HTTP with Django

or you want flashy WebSockets with channels.

But there's very little middle ground between those two.

Yeah, and I know, I think it was at Django Under the Hood,

you gave like a 50-minute talk where you really went into the details on all this

that we can, do I have that right?

It was at Django Under the Hood?

Yes. No, the Django on the hood was almost certainly where it was. Yeah.

Yeah. Yeah. So we can link to that so you don't have to repeat that. So I want to talk more about

that, but actually it brings up, can you talk about, so merging South into Django, what was

that like? Because from the outside, I started with Django when South was there and then just

kind of magically it happened. But what was that process like for you personally and just the

logistics of the Django community? Because that was, is one of the largest, you know,

third party packages be coming into Django and many third party ones,

you know, Django rest framework don't, and probably won't.

won't so curious what was the personally what was that experience like because i'm sure it was a ton

of work and work in ways that aren't obvious from the outside yeah it's one of the things i think

it's not immediately obvious to some people is that it wasn't moving south into jango as a full

rewrite so like jango migrations is a from scratch rewrite of south basically i took the i think six

or seven years at that point of lessons from maintaining a migration framework and going okay

like if i could do it differently here is what i would do and this is the one chance we get to have

breaking backwards compatibility right so like yeah we're gonna provide a migration path that

migration path is going to be like not particularly fluid like you have to like basically move to

migrations and then run a command to synchronize all up and you're done and so like that basically

i sat down i planned it all out i went to kickstarter um we ran it as a kickstarter and i

think i raised like 17 000 uh pounds sterling i think something like that and that helped again

fund it so like a lot of um one of the things i do is i work four days a week and the fifth day

each week is for open source work which is i'm very thankful i've had from lanyard i've had to

prevent bright like they've been very supportive in both of these and it's like that money basically

pays for my fifth day a week to work on the projects and so with migrations uh when i was

back at lanyard i believe this was um i was doing doing that and i was like okay let's you know

raise the money so i can fund it and take the salary cut and it makes sense um and then i sat

down planned it out went to the community and said here's my pitch like i this is before the

i think it's before the debt process so like we didn't have a debt so i was like i just pitched

on janga developers and i pitched um like the core team at that point was like okay like this seems

like what we want does anyone disagree and i got very little pushback i think the one pushback was

like i have problems with south i was like yes i do too here is the list of problems here's how

we're gonna fix them um and i think and everyone agreed like it's a problem that pretty much every

install of django faces right like almost everyone has that problem with the orm and so

that all lined up and i sat down spent six months to a year doing the full rewrite fully testing it

and then released it in django 1.7 uh and there's a few extra fixes and then thank i'm very thankful

to people like Marcus and other people who took over maintenance of it like after I'd sort of

done that and burnt out a bit um but yeah it was it was an interesting time I remember migrating

projects it was you know and it just it it was like ah we've got to change and we've got it but

it was remarkably smooth in the end like you know looking back you think oh it wasn't that bad you

know and at the time you're pulling your hair out and but it was it was well done I remember you

know it was one of the big milestones in Django's move from the early days to the later days I guess

of in the 1.7 with the migrations coming in exactly and what what was that collaboration

like i mean so was it six months you just went off and did on your own like how often were you

showing the work to others like how did that like so how would it be different now with async stuff

versus what you did back then so yeah so back then it was very much i became a hermit right like i i

yeah good approval i i went into the shadows for six months and came back with a basically a beta

version like here you go you're welcome yeah no like like i wouldn't recommend this right it's

not a good strategy but it's also like as a developer it's my default and it's hard to get

away from that and so like well some degree of space is nice too i mean you can't have people

second guessing you as much as you're second guessing yourself with some decisions totally

but at the same time like having people to bounce off of is also crucial to like getting good

development done right and one of the things i've learned about eventbrite is like how to run large

projects and so like if you look at the async proposal versus like the migrations proposal if

you go back and look at it um they're structured very differently like async is structured in a

way where it's like well this is a very big project it needs to be across multiple people

it needs to provide value in incremental steps and not be one big dump and it needs to be like

exchangeable between like different people and like we can pull out any time like that that's

kind of like it's run like how i'd run things as a lead engineer at eventbrite it's run in that way

Like, we have to have this be small incremental steps that are all achievable by themselves, rather than Andrew goes through a bunker for a year and writes it.

Yeah, I mean, we'll obviously link to it.

It's a lengthy document, but I was struck when I read it that it was how iterative it was.

I mean, I was quite impressed because I know it's very difficult to not just have the idea, but to have the roadmap.

And yeah, I guess that makes sense that doing that professionally guides the process of then doing it in an open source way.

yeah and it's one of the places where like open source and commercial work often reflect off

each other like I've taken things from open source like documentation culture into Eventbrite and

that's really helpful and Simon has too right like there are things that go both ways and like

running large projects is not a thing you see a lot in open source and I am determined to not have

this be a burnout center again right like that I've learned from the last two times I would hope

and like even if we just do the first part it's a win right even if we just but that's yeah that's

exactly it even if the if even if it's just the view layer that gets you know that gets async

that's kind of okay it'd be nice if we get to the orm and we get a lot but if we have the view layer

then we can write proper async apps and we can embed other asgi apps and we can do all sorts of

really exciting things with just that and right and i i think of like having an async view and

routing and url layer opens the door to everything else right once you've opened that door and you

going to do async def views then like the community can fill in things like if you want to do an urm

you can but maybe you can pull in like tom christie's databases library and do async stuff

with that right you have all these different options and so that really to me is the way of

doing this of like let's get that first thing unlocked and like that first piece of work is

arguably the most like solo piece of work like i don't intend to be done by me alone i'll try

get some collaboration but needs to be tightly controlled it needs to be like have high like

i'm not saying the word high touch like lots of contact between different people who are working

on it and make sure it's a singular a singular vision so that it comes out right everything else

can be like you know like async forms async rm async cash can be farmed out to different teams

that's going to work fine and hopefully it's a new contributor as well like i'd love to be like hey

like we need the cash layer to be async we can write you a clear definition we can give you some

guidance and mentorship let's bring on some new contributors to django as part of that process

i think as well that the view layer needs to in a way it's it's going to be less susceptible to

changes going forward so it kind of almost has to be right or nearly right first time it you know if

we mess up the formula well we can redo the formula we could have you know it wouldn't be the end of

the world but the view layer would be would be annoying to have to introduce breaking changes

later on i think it's notable too that like one of the fun things about going through and doing

some of those first parts of the work and some of the research is you run git blame on some of

these few code files it goes back a decade right you immediately jump to like 31.0 like most of

the rest of like you know i remember when the current form system was called new forms right

like most of the rest of django has changed over that time and the view layer has mostly stayed

the same um like one of the things people don't realize is that django predates whiskey um like

whiskey basically came around kind of from jack like django and turbo gears and other contemporary

frameworks and so like in some ways django doesn't have a like django is not whiskey all the way

through because it predates it like you go look at like flask and virksoig like they are basically

written around whiskey i've been i've talked to the flask maintainers um like david lord about

like what it would take for him to support acing he's like well like it's so deeply ingrained in

our stack that it's a lot harder to untwist and it's possible he swapped some ideas but whereas

django like we have that distance which means that both it's very old code but at the same time

it's kind of not totally tied to whiskey simon talked a little bit briefly about that abstraction

when yeah creating django and that's great that that's a yeah major strength today that

abstraction i wonder yeah i sort of wonder how flask will handle that it's not really strength

it's an accidental helpful thing right um that we get the place yeah okay strength is the wrong

word yeah us not touching for 10 years maybe not a strength it's but again a testament to the

original developers it's run fine for a decade right um but yeah again like i want to touch it

once i want to and crucially i want to keep the same kind of abstraction because like i think

one of the things that appeals people at django the most is like that very simple like mapping

of like hey you have a function or a class you put it in a urls file bam it's done there's no

like weird routing there's no magic objects there's no like tracing attributes or like

implicitness like it's very explicit and i want to try and keep that design the um so you talked

about um the experimental work that's gone in thus far and so the the ascii ref the the ascii

standard is is just gone to its 3.0 version or its version 3 and so can you talk just quickly

about the ascii standard and is that kind of stable now is 3 going to be around with us for

a long time yeah so my my impression is that three is is very stable um so in many ways asky was one

of the goals of the channels project um which was to like channels was both trying to make web

sockets work but also research into what it means to make an asynchronous django like channels was

always meant to be the predecessor to django itself becoming async but when i started that project i

had no idea what that would look like um and we also didn't realize web sockets wouldn't be nearly

as popular as we thought they would be right like these days it's like nah like hdb2 has made like

ajax a lot more reasonable and like long polling is still around and sockets are still used but

they're not as popular as maybe they're not like every site's not using them and so ascii sort of

ascii one was um this sort of weird internal channels format ascii 2 was born out of the

channels to rewrite which we'll maybe go into in a little bit um there's basically sort of like a

better version and then tom christie has been instrumental in in ascii 3 of like running a full

ascii framework and using it in production and having channels used in production and talking

to other frameworks like you know like we've had way in from a decent number of python web

frameworks on ascii 3 to try and make it something that both seems implementable by servers like i've

talked to a few different server authors too they're like this seems okay like no one says

it's good because no one wants to write new server support but like people generally seem like it

seems fine um and web frameworks agree this too and crucially as he three is the most looking

like whiskey yet um which i think was always the goal like it's meant to be a spiritual successor

but not a direct successor tom christie gave a great uh i don't know his keynote but talk at

jango con europe this year about um async and ascii that we'll link to for people who want to

get up to speed on the terms we're tossing around yeah that's that talk is also a fantastic dive

into uh his vision for a totally un-django like but very pure um asgi framework which is fascinating

what what came for me out the django con thing was that the people were talking well why do we need

as async why you know what this is well you know what came from tom's talk was very clearly that

well we don't want to have to change language just because we need that extra throughput that

async will give us and so python's got to have async and asgi is a great candidate

for a python standard for web frameworks there and then well why does django have to have it well

because django is the batteries included web framework in python and so it may not be that

we need everything that ascii could offer but we need something you know you don't want to have to

change web framework just because you want to build async views and so i think it's really

important um and that well that was kind of interesting from the conversations that django

corner around that yeah well it's fantastic strength of django too that's so mature that

it can be this forward looking it's not just constantly triaging past bugs you know it takes

up 100 of the bandwidth of the fellows and the core contributors yeah i also i think one of the

things that batteries included is that like some batteries are very easy and some batteries are

very hard like migrations is a very hard problem and i think async ranks the same category like

it's a thing that we should solve so everyone else doesn't have to like like anything security

related or like networking related i think falls in this categories like django like you know

fumble doesn't provide things like you know nice looking ui libraries it's better sold by other

people but like solving async is a thing that like django kind of should treat as its core

competency right like it has to be baked in well the and the security is a good analogy because i

was just um i'm writing a book on django which hopefully will be out by the time this comes out

and in the security chapter basically it's uh you know you can take off the defaults that django

provides but think pretty carefully about doing that because it just gives you the guardrails

and it does give you the option to take them off if you want to write raw sql or you know but if

you don't want to have crs csrf tags but it just sort of handles it for you right because security

yeah it's also that oh my god it's such a deep well of of knowledge and once you get beyond the

sort of basic attacks it's it's almost kind of infinite and that's the point of these the uh

the monthly updates to Django and all the work so yeah so one of these areas that's definitely

if someone else can handle it for the community or the community a small subset of the community

can handle it for Django developers it's a huge benefit and doesn't need to be redone each time

yeah and you touched on the thing there too which I think is important to Django which is like

you can remove piece of it right you can remove the guard rails like some web frameworks don't

have that right some web frameworks are all or nothing um i think famously like like i don't

wish to talk bad about rails but my experience working on rails projects was like rails that's

what i was thinking of yeah exactly um it's like you know i spent a good six months working on

rails projects and and it was uh very informative um but where's well yeah but it's it's i mean

yeah that's what um i get that question a lot of well should i use rails should i use django and i

you know, specifically for beginner,

the user authentication in Django is more work than Rails.

Because Django then makes it completely customizable

and you can swap out what you want,

but it comes at the cost of more upfront time.

And so that's kind of what I tell people

on the ease of convenience,

Rails is pretty much near the top,

but when you want, you know, the fact that Django is, I don't know, three quarters,

80% of the way there, but lets you customize it with experience. You appreciate that trade-off,

I think. Um, but it, but it's a little bit, but it's a little bit of a bump when you're

just starting out. It's not all magic. Oh yeah. I totally agree. Like rails is

definitely easier from, from like step one, but like Django strength come like, you know,

like Eventbrite still runs Django. We've replaced like half of it in various pieces, right? Like

we run a different like user authentication framework and cookie system but like we could

still have the old csrf system right we run a different cache layer but we still run things

like the the orm pretty much untouched um so that's kind of part of the way like part of the

value i see in django itself yeah well i think it's what instagram swapped out the orm because

i was wondering i know they have facebook has its own solution if that's um if you if you can

speak broadly is that like where are the pain points that to the extent these a couple sites

that are at massive scale that use django where does django kind of break down at super scale or

is it really just specific on the needs of the project so um i think one of the i can speak to

event right more than instagram though i do know they do run facebook um graph uh as their data

store rather than drm um but like one of the problems we face at eventbrite is that running

at scale means having like it's it's more problem of engineering teams right like you can't have all

the teams running on one big project um it's much easier to have them working on like separate

for whatever word i say microservices but they're not micro they're sort of like medium-sized

services and what that means is like you now have this whole like service call and routing problem

you didn't have before and crucially for async you have this thing where like you're gonna you're

like main view or template logic it's gonna call like four or five other things to service different

parts of the page and wait for them all and come back if you wait for those all serially you're

be waiting a lot longer than if you call them all in parallel and get the results in parallel and

put them all on the page because those things act independently i think that's one of the things

like at least i've seen talking to other big sites too is that like making sure it can split up more

and more and become more independent like that channels version two i know carlton you mentioned

that maybe there was more to unpack there about what that was like okay so one thing you know

that's interesting is what was actually wrong with channels one because lots of people took

channels one they built good sites they were using it very well and yet you weren't happy and other

people using it at scale perhaps weren't happy so what was the what was the issue with channels one

can you if you could explain that i think that's interesting yeah and also i want to explain like

i i do not make the choice to go back because i'm incompatible likely to right so that's like

if i make a big jump like that it's because there's a good reason and in this case it's

architectural um channels one was written in architecture where you had a server that received

WebSockets and HTTP requests. You had a separate server that ran Django and the functions. And both

of those talked to a central bus, which was called the channel layer, which is basically Redis for

most installs. This is an interesting architecture in theory. And again, in theory, it scales really

well. But in practice, it doesn't. In particular, it's much more fragile. And you're adding in

another point of failure to the web flow like you've gone from running a single server process

to running two different processes and also a communication layer between them and in the end

like i just couldn't overcome the difficulty of doing all of that like deploying it was massively

confusing and in many ways the reason we did that was because channels one its goal was to work with

the lcs at the time which supported python 2 which meant we couldn't use async io channels

two is a re-examining of the same problem that channels one was a solution to but with the

different constraint of you can support 3.5 and up and like given those two different constraints

you end up with two different designs but like to support python 2 you can't have asynchronous code

you have to run a different process like redis was your asynchronous scheduler basically that's

how it worked whereas with channels 2 we're like well we have asyncio now we can do this internally

in python and sure there are a few issues asyncio it's not totally perfect but having it in process

is way easier and having the deploy be run it like whiskey is also a lot easier to convince people

like hey like you just run a server and pass an application object like you used to rather than

running a red redis cluster you can't shard properly and all that jazz yeah okay right

and because you you as well like deploying django is hard enough for your average project right

without making it extra by having this whole devops like yeah and not to mention like you

couldn't use redis cluster because of the way we use redis it had blocking calls and so it has to

have its own sharding implementation that ran on top of redis that sharded basically it was i'm

very impressed it worked as well as it did in production um i'm very happy that it did but it

just wasn't conducive to long-term maintenance and crucially it's not a pattern we could have

taken django itself into like we could never make django like that okay so i um you mentioned a

burnout in your career which makes sense given how busy you are i'm curious how

how do you tell that you're burned out and then what sort of techniques have worked for you because

i think this is something that hits almost everyone maybe not simon when we interviewed

simon i remember saying like you're the unburnout engineer like he's so enthusiastic but uh for

everyone else and for yourself what kind of how have you spotted it and then what's you know what

works or is it beyond just taking a break from all the extra work that you're doing so i'll

preface it by saying like burnout is deeply personal and i think like what works for me

doesn't work other people right but like with that caveat in place like yeah my my personal

signs are generally a lack of enthusiasm um mostly for doing anything right it's almost like apathy

so like i like i go from like um like the two of you who are here you can see behind me on the

video that i have like there's a sewing machine there's a 3d printer behind me you can't even see

like i do a lot of making in my spare time right like when those hobbies start suffering is when i

know i'm suffering from burnout um it's when i'm like like my making a 3d printing and fabrication

and like my other like crazy art projects suffer that's when i know like overall i'm being burnt

out and then the way i found to do that is to step back and i've been more forceful with myself

over time i used to be like oh if i step back like i feel guilty like the community depends on me

like everyone's felt like in a different way be it be it like your company or your spouse or anyone

depends on you um and in the end like i found that like just you know like with channels too

at the start of the year i was like like i've realized i'm burnt out i give myself there's a

i get a month right there's a month to try and find a handover period and colton very thankfully

stepped in to help at that point but i was like like you know it's better to take this project

say like it is officially done and to try keep pushing through the burnout because like it's

But a big problem I have with documentation sometimes, too, is, like, it's much more important to say, like, this, like, be honest, right?

This is not maintained.

It's much better than saying, like, oh, this has the look of being maintained, but it's not actually under the hood.

And that's very different.

Yeah, no, I mean, I think there's a massive, the expectation thing that you mentioned just there is absolutely true, especially contributing to open source.

And there's kind of, like, this, people get this expectation that they have to contribute, that they have to triage that extra ticket, that they have to, it's like, no, you're volunteering.

Like, and much more important is you say no

and that you take the time for yourself

so that you enjoy contributing.

And, you know, if you can't do that, step away.

Like, absolutely.

I also want to talk to something

that's not obvious to people.

Like, being an open source maintainer

is particularly difficult

because all you ever get are bugs.

The only feedback you ever see as a maintainer

are the problems people have.

Like, for like seven, eight years of South,

for all of migrations and for most of channels,

like i only ever saw people going it doesn't work for me it's ruined my life like i never like the

only time i ever got positive feedback basically at conferences people come like oh yeah we're

using your thing in a production so like three million dollars i was like what like that's the

only time you ever hear that stuff like so like i encourage you like if you're listening and you

and like there's an open source project you use that you think might not might be in this problem

like an email to the creator or maintainers saying thank you is always welcome like i get a couple of

every month and they're always welcome like just many people reach out and go like your work is

amazing thank you very much um like it honestly like those are what keep me going like yeah that

it's it's you know otherwise you just see like everyone trying to do weird things with databases

and not succeeding and it just it feels like a huge load right like having having that empathy

everyone is difficult why i remember there was a there was a permissions mix in is the login

permissions mix in that someone brought to my attention six months ago. And I looked at the

ticket and found the person who had worked on it and shot them a quick email. And yeah, they

responded as if they'd never gotten an email of thanks in their life about it. So it's certainly

helpful. And yeah, even for me, in a way, books are a form of open source. Numbers don't mean

anything. It's the personal emails, which aren't that many, that make it meaningful and push

through the sort of the negative like yeah this this is broken kind of stuff which does get tiring

yeah and it's just a general thing in life like like when we work in a volunteer community

it's important to respect each other and make sure like each we like you know like i try and

make sure that i thank everyone in person whoever i can who does work that helps me helps me out

and i think just you know if we just have more of that going forward like the general community is

already one of the best communities i've ever been in for open source right like it i joke that

sometimes i stick around for the people um but it's it's kind of half true right like the the

group of people around janga some of the nicest kindest and best people i've ever like had the

pleasure of interacting with and working with and supporting and just being around and that's that's

a huge part of it also as well there's a culture where um correct behavior is expected and the

code of conduct and everything that's done around that is so important and it just inculcates like

once it started like when when i first turned up to my to a django event i was like wow blown away

i've been using django for 10 years i've never been to an event and i came and i was like oh

wow this is what i've been missing and it was just already there and in contrast to other

environments where perhaps not it's like it's really noticeable so there's a reason i like i

used to fly i've been to every django con europe and every django con us for a reason right it's

not just because i like going to different different random states in the us it's also

because like there are people there who are very like i see them twice a year but i see them some

of my best friends right that's kind of kind of the way django works i remember my well first and

only django con i experienced that and but most people can't go to django con yet use django so

that was really this podcast came about in part to open up people to the broader community and

the people like yourself who have these amazingly outsized sized roles yet uh you know i would say

majority of people using django don't know who you are um and more of them should so but also

i'm fine with that right like one of the things well yeah yeah like maybe one of the things that

yeah we all want to go up in our cave and do our thing but you know we pop our head up every once

in a while it's nice to um yeah yeah it's one of the one of the weirdest experiences for me was

like django con 2009 2010 like what second or third one um someone came up to me when oh are

you andrew godwin i was like yes so i know that oh no i just i just know you from online like that

was the turn of like people knowing who i was without me knowing them and it's honestly a very

strange experience um i've got much more used to it now and like i try and meet new people every

jango con and try and push beyond my admittedly like very difficult like introvert boundaries

to meet new people um but at the same time like yeah there's a lot of people that like jango con

is by its very nature has to be an exclusive event right not everyone can travel not everyone

is in the right country or can get visas or whatever and so i think it's also important

that we make sure django is supportive in other ways too and like we have a good community online

and you know in different mediums like that well carlton was was noticed someone by his voice alone

right at the one of the sprints at django con europe they're like oh wait who are you oh you're

that podcast person right yeah i was talking to an issue with someone i'm sort of meltdown next

them with they're at their laptop and all of a sudden they stop and they're like do you do that

podcast because i'm just talking in their ear yeah well i mean one thing with the django community

from where i sit because i think i sort of sit hopefully maybe near the beginning of the tunnel

and you guys are both at the you know very mount everest of it is there's so many people

learning django for the first time who it's their first web framework yeah or um i mean just the

variety of people i interact with is unbelievable it's you know so it's undergrads doing computer

science i mean just last week it was multiple tenured ivy league professors and you know

economics or some other profession who for a field for whatever reason want to learn web stuff and

they're you know you know one of them is like on track for i looked looked him up on track for like

nobel prize uh in economics and he was stuck on chapter three of my book with heroku and i was

like oh well you know it's i got stuck on it too like a lot of people do but it's this both this

great equalizer and also people are just using you know django and web as a piece of whatever

they're already doing because they see that to be knowledgeable in the modern world it's such a

benefit and so it's um you know i just see all this crazy upside to django as being one of if

not the default entryways to web development for people you know so i think i would bet the django

will be way bigger than it is now in a couple of years

because all those points are going

in the right direction, I guess.

I mean, I met you for the first time at PyCon.

I mean, PyCon is really not about Django

and yet it's massive.

Yeah, exactly.

And I think one of the things I think

the django contributor contributors over the years have been good at is not forgetting beginners

right like it's very easy to fall into the thing like oh like we've all been working on this for

like five ten years we're now all experts we should solve the expert problems and like one

of the things i try not to lose but i do sometimes i try not to lose perspective on is like the

beginner view like what does it mean to sit down for the first time use this thing and try and

understand the con like the web is still revolutionary right like we empower people in

that way like what does it sit down on soundness like not know how anything this works like i don't

want people to know async is until like at least you know chapter nine of any potential book right

like they should not have to care about it i get reminded weekly yeah but what are these sticking

points i mean so that professor he was it was the structure he was using start project and he didn't

include the period um you know even though i specifically said three times you need to include

the period even though i had the source code you know because you know so it's so i'm very aware of

like of you know of that thing and even actually last week i got on friday i got stuck on a no

reverse match error and i was having an existential crisis over it because i'm just how much time have

i spent on this i can't believe i'm having this issue but you know i i asked carlton uh jose

padilla a whole bunch of people and you know it wasn't like everyone immediately saw it even among

you know this like murderous row of django people so um programming is very humanizing like that

yeah totally yeah and it's just acing acing doubly so because like i i often struggle to

think about like i was taught like asynchronous like proof theory university which is like it's

one of the very few things that come back to go actually that was useful and i have used it again

but like it's so i regularly sit down just like just sit there like lie on my bed with like a

drinks of like i see or something going like what is this problem how do we solve it just like

thinking it through like it's not easy and i don't want to like again if you want to remove the guard

rail and jump into it we should let you but i also think we should protect you from it unless you

really want that yeah one thing you've talked about with the async proposal is to keep almost

keep sync views as the default way of doing it because most times it's easy and that's the one

you want to walk into and then when you want to opt into async then it's there not not suddenly

need we've got a node js like web framework replacing django it's not right it's not going

to be like that like one of the things you learn when you're writing code is async code is just

harder um like it's like you've got more to think about there's there's more to have in your brain

at once and i honestly will find any excuse to write synchronous code i can because like

synchronicity and the gill and everything sure it's slower but it makes it so much easier to

think about and understand and like i value that sometimes like if the code is not performance

critical that's great and like that's and most yeah most times it's not exactly yeah yeah so uh

so for people listening what are some good steps to get involved and learn more we're going to link

to your um proposal what are some what would you say if someone says well i know django but i'm

async is still new to me in terms of well here's how you uh learn more and then here are maybe some

areas that could use help on so i unfortunately that i have not yet found a good async tutorial

which means i probably have to either write one or get somebody else to write one

um but there isn't for python or you mean for python or for python or even just the general

concept of of what it means to have so like python's version of async is called um cooperative

uh asynchronous programming which is similar to some other languages but like for example go is

not the same right go is not quite it's similar but not exactly the same like just like interesting

like how do you even think about the problem how do you reason about it like that's what's missing

at the same time it's python so i suggest you just like find some just like find a project

just hack on it like just make a little thing that fetches urls in parallel like the classic

example is you want to fetch like 10 urls in parallel and you can do that in like five lines

of asynchronous python but like do that and like just break it and try and work out why it breaks

like that's that's my approach to stuff um and i'd say and for jang basic in general um it seems

like uh depth nine which is the the big long document you referred to earlier um is uh seems

to have sort of settled down and the feedback slowed down so we're going to start pushing it

through to the proposal process for the technical board um and once that's done i'm going to start

working on both a how to get involved um sort of blog post a document and also a funding one

because the funding is a big part yeah for us um so like like look forward to those i don't have

them yet unfortunately um i took a good well they may be out by the time we release this this is

true yes but at time of recording i just come back from uh two weeks of vacation and a week

of pycon before that so uh those are not times when i get get stuff done should we say yeah right

yeah what about you carlton anything to add on that front so one thing you've mentioned a couple

of times oh well on that front in particular no um one thing you mentioned a couple of times is

documentation and i know you're really keen on writing good documentation the channels docs are

just phenomenal to be honest so yeah can you talk about your philosophy there and stuff because i

think it's something that a lot of people could learn from and i've learned from myself yeah i

mean i the philosophy in some ways is self-inflicted because i learned it when i was looking at my code

from three years prior and going what was i thinking um so like like i write documentation

for myself in the future is is the line i use right it's like well okay like

and to me it's not about how to use it's about how to think right it's like if you are approaching

this project here is the frame of mind here is the way that as the author as a maintainer i

approach this project and like that will by itself convey to you like how to approach this like like

the channel stocks for example a good portion of his concepts it's like here are the concepts and

here are the here's a glossary of the words we use elsewhere because that will get you so much

further than me guiding you through it with with like hand on hand because like i could give you

lines to run but you wouldn't understand at the end like my philosophy is always like documentation

is to teach and to inform you a thing exists and to show you how to approach it but and like you

do want like detailed instructions when you get there but you have to have the other parts too

that's kind of how i approach it i think that's well said because i i noticed i think meta about

things the difference between documentation and tutorials where people want tutorials but they

you sort of need documentation and i think when you say that the fact the channels docs in

particular why they're so great is because you also do sort of a tutorial on it yeah you sort

of meld those together but um that's a lot of work to do and like we know we need to do the same for

async too right like there is presumably a part five or part six of the jungle tutorial that is

and is now async with some jazz hands in it um but like as i said like like you know there is no good

tutorial out there to learn how python async works i think it probably then falls to to jango as a

project to supply that my hope also like you know documentation is a crucial part of engineering

like if you if you haven't talked about engineering like engineering is part programming part

documentation part communication and collaboration and like those parts are all pretty much equal

in my experience and people often put way too much emphasis on programming and not enough on the other

two like written and verbal communication is incredibly important and so a big part of this

project is like i want to bring on people that say like hey like like we just need people to

who are good at explaining and understanding and honestly like beginners are the best at this like

if you are a beginner or relatively new to django or even to a concept you are in the best position

to explain what was difficult about it like your example earlier of the period right like obviously

you you'd anticipated that one but there are things i can't anticipate that like beginners go

oh i found problem x really hard i was like oh that never even occurred to me and so like yeah

an amazing opportunity here for like beginners and people even like one or two years in they

still remember like i've forgotten what was hard about python because i started in like python 2.4

where people are going all decorators are new and exciting like at this point yeah i'm not i'm on

somebody's a terrible teacher of python people come to me and go like oh how did you learn python

they're like i can tell you but it won't help because like all the things that were there in

2006 are totally irrelevant now it's a different way of they've gone yeah well i find if you just

ask if you think something simple ask someone next to you to do it like install python here's

you know on a windows machine go for it like you're like oh my goodness yeah which that thankfully

suddenly got a lot easier in the last month or two but yeah it's it's it's so many things like

that where i want to like make sure that again like we talked about beginners earlier right like

beginners are a crucial part of of django's ecosystem i've always want to make sure i'm like

so are big companies i don't want to have us like captured by big companies right enough people who

work with django and python in general work at big companies like i want to i want to occasionally

forget about the big scale problems and come back to i'm writing my blog like how do i get that

stuff working properly right like i do still maintain my own django power blog half for this

reason um it is still on django 1.10 i think unfortunately um but it does use migrations at

least uh and like that's kind of my my test bed for like i'm just like a normal like contractor

again like how do i handle this stuff and that's a useful perspective to have i think yeah i think

oh go on i was just saying one of the beautiful things about async is that it's coming out of this

need that is seen rather than you know eventbrite has a specific need and you are filling that

via open source so in some ways that solves some problems and that uh it doesn't seem like you feel

the burden of building something custom for eventbrite or someone else for a specific company

it's it can be done in this you know community-based way whereas many other features

and other projects you know do have that you know a large company wants something custom

and then you have trade-offs yeah a classic example that's kubernetes right like kubernetes

is pretty much written how i would think about a enterprise level orchestrator which means it's

very hard to get into and you can't really run it on a single box it's getting better but like

that and that's what i wanted to avoid and part of channels one and channels two and like the

years of research and talking people has been working out like what is best for everyone like

talking to different people up and down the spectrum in different countries in different

industries of like hey like what do you need like what's useful for you and i think like the

culmination of that is like the async proposal is pretty much like it's the node of like here is the

place where all those needs cross and like everyone everyone can agree on this stuff and i i'm hoping

like the general lack of people going oh this is a terrible idea is is proof of that right like

everyone seems to go oh yeah no we do we do need this um but also it's a very difficult thing and

like yeah like if it was just for eventbrite it'd be a very different solution to the problem

but that's not my goal here carlton what were you going to say before i cut you off

i was going to say something about um the previous conversation but it's no point going back to it

now minor minor agreeing with andrew oh okay i would when i when i edit these podcasts i often

hear myself jumping over you carlton so i'm sorry that's okay didn't your mom tell you about that as

well yes my parents remind me of many that's okay helpful things i can improve on that's what no

that's so super i think okay so is there anything else people to get in touch or what what else do

you want to promote i mean you have a lot of other projects as well andrew what what would you like

to say as we wrap this up i have enough other projects that i'm not going to promote any one

of them um like if you like if you if you're interested in like electronics and fabrication

like you know i have a youtube channel with some stuff or on twitter but honestly like

the thing like if you listen to this podcast you're probably involved with django um what i

encourage you to do is like look out like we'll get a post on the django blog probably but i'll

tweet about it as well like like look out for like i was talking about like how to get involved

and like i really want to run async in a way that not only brings in new contributors but also like

is spread out properly and like we spread the workload and we have everyone understanding

and agreeing on on how things work so i i'd love people to like even if it's just like copy editing

documentation or writing some new tests like there's so much work that we can do that can be

paralyzed out that you know don't don't feel shy about stepping up um don't feel like you're going

to have the burden of the world coming down crushing on you um like it's not like that at

least not at first um and yeah so we can make the work asynced yeah exactly uh but yeah like like i

above all else like please get involved like not even with this like maybe a local like jango girls

meetup or like pyladies or other meetups like open source takes volunteer work and it takes

many volunteers to make it sustainable so that's my call to action you're brilliant and all i'd

just add on to that is that as well if you feel like you need help with that reach out because

there are people in the community that will support you in contributing if you want to

contribute yeah people are way nicer than you give them credit for is my general advice

i've seen it time and time again like especially in the django and python communities

um i generally expect the best people i'm usually rewarded which is which says a lot yeah and if

you're reaching out you're validating how someone in a position of expertise spends their their time

so regardless of the question it's it's sort of validating and and it and it provides and it's

interesting because it provides that lens on oh i i forgot that this was hard or i forgot you know

that makes sense that with your lens this is how you think about it so it's it's helpful as well to

even someone who's a expert totally as i said like beginners have the best questions and often have

the best answers so reach out all right well thank you so much for taking the time to come on um

as ever people can find this episode on jango chat.com we're on twitter at chat jango and we'll

have links to everything in the show notes that we talked about so thanks again andrew for making

the time thank you thank you for having me on it's been great all right bye