Have you been learning Django and now you want to get your site online?
You're not sure about the best way to host it or the trade-offs between the various options?
Maybe you want to make sure your Django site is secure.
On this episode, I'm joined by two Django experts, Will Vincent and Carlton Gibson.
Talk about deploying and running Django in production,
along with recent updates in Django 3.2 and beyond.
This is Talk by Thunder Me, episode 301, recorded January 19th, 2021.
Welcome to Talk Python to Me, a weekly podcast on Python,
the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy,
and keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is sponsored by Square and Linode.
Please check out what they're offering during their segments.
It really helps support the show.
Before we get to our discussion, just one quick announcement.
We started live streaming the recordings of Talk Python to Me episodes on YouTube.
If you're part of the live stream, you'll have a chance to ask questions,
and your comments might get featured on the air.
Just visit talkpython.fm/youtube to subscribe to the channel
and see upcoming and past live streams.
Now, on to the show.
So, Carlton, Will, welcome to Talk Python to Me.
Again, welcome back, guys.
Yeah, thank you.
You came on our show, and I was on your show three years ago.
So, Carlton's first time on your show.
Talk Python newbie.
It was great to have you on the show before, Will.
And we talked about Django then,
and I suspect it won't surprise people with you and Carlton here
that we may touch on Django.
I think we've got to talk about Django a little bit.
A little bit.
Carlton, tell people who you are.
I'm a Django fellow, so what that means is I help to maintain the framework.
A framework the size of, oh, you've got me on Twitter there.
Oh, yeah.
Carlton Gibson on Twitter and on GitHub, numerous other places probably.
But a framework the size of Django's, it just simply doesn't get maintained
on purely volunteer effort.
So, there's a body called the Django Software Foundation,
which Will's on the board for.
He can tell you a bit about that in a second.
But they are a charitable foundation, which, well,
they collect money from donations from GitHub sponsors,
and you can donate on DjangoProject.com.
And then the main thing they do is they contract the fellows,
which is myself and Maris Feliciak, who's my colleague now.
And we do that.
I don't know.
What do we do?
We triage the tickets.
We do pull request review.
We do handle security issues.
We handle the releases, not least the alpha releases today.
So, today, literally today, we released Django 3.2 Alpha 1.
Fantastic.
Is that the very first 3.2 release?
That's the first one.
So, that's like if you've got a Django project and you've got CI,
you download it now and you run it on your CI
and you tell us all the things we broke.
Better before we release the final.
You know, it's much better during the alpha pre-release period
than, you know, just after 3.2 final, you go,
hey, everything's broken.
Yeah, you really need people to test it now
before it's too late, right?
Yeah, but yes, it's quite exciting
because the last couple of weeks have been building
towards the feature-free.
So, the alpha marks the feature-free.
So, over the pre-release period now,
we'll merge bug fixes in the new features.
So, anything that people find and report will fix
and get out before the final.
But there's no new features going into 3.2.
So, on Thursday, just gone, I branched the stable branch
for 3.2, which will be, that's Django 3.2.
And it will be that for the next three years
because the long-term release gets quite,
the long-term support release, which 3.2 is,
gets three years of support.
That's really great.
All right, we're going to definitely have to come back to that,
but also, welcome, Will.
Tell everyone about yourself.
Real briefly, you know, you were on the show a while ago
and we talked, I believe it was learning Django
we spoke about, right?
I've been involved in Django, it's the time.
So, I'd written, I think, a couple books.
So, I have three books,
Django for Professionals and APIs.
And the last two years, I've been a member of the Django Software Foundation board.
About two people who were voted in,
who play a prominent role in the community one way or another.
And then the board is seven people annually voted on
who managed Django itself, which is a non-profit.
About that later.
So, yeah.
And I have now a website, learndjango.com,
which is an online version of additional content.
But in addition to having a podcast with Carlton, Django Chat,
since he's a fellow, which is contracted by the board,
we have another touchpoint, as if we didn't need more.
Exactly, yeah.
So, I was on your show a while ago and that was super fun.
I really enjoyed our conversation there.
And, you know, maybe just tell people quickly about your podcast.
What kind of stuff do you cover there?
Obviously Django, but, you know, where do they find it?
What do they cover?
Okay, so we get people on from the community.
It's kind of an interview type basis.
We get someone on.
It's fortnightly now.
We were doing it every week, but, you know,
not like you, Michael, we can't keep it up forever.
So, we've gone fortnightly,
which has taken a bit of pressure off with COVID
and, you know, the kids off school and all of that.
But we get, you know, people who've contributed to Django
or people who are using Django in their business and talk about it.
So, it's Django Chat.
It's chatting about Django.
It's chatting about Django, yeah.
Yeah, yeah, yeah.
It's chatjango.com.
I think recreating a little bit of what you would have at a Django
event.
So, these are annual events.
So, we started after I went to my first DjangoCon and met Carlton
and was like, why can't I talk to people about Django more often?
And at the time, there wasn't a Django podcast.
So, yeah, we've gotten to interview really my dream list of guests.
I mean, we had...
Actually, I was just talking to someone else who works at Stripe,
which is still running on Sinatra, which is a Ruby thing.
And I was like, yeah, yeah.
I've talked to DHH because he's came on our shows.
We talked about Rails versus Django.
We had Carl Meyer on, who's at Instagram, was formerly DjangoCore.
All the...
Basically, everyone...
Almost everyone we'd want to talk to who's involved in Django is willing to come on and
share their story.
So, I think it's a really nice connector and educational for us, too.
I do as well.
And you're just sort of a sidebar for our show here.
Being all of us fellow podcasters, I think it's really interesting the role that podcasts
play in keeping connections to the broader tech community when we can't go anywhere.
I mean, even if you weren't typically going to conferences or meetups, you could still go
to work and see other people, right?
It's just first when COVID hit, I was like, I'm just...
I'm not traveling anywhere.
I'm not taking my kid to school or anything like that.
So, there's no natural place.
Here, I'm stuck for 45 minutes.
I'm going to just listen.
But as it's drawn on, I've started to listen to shows, especially with multiple people trying
to bring sort of a normalcy.
And I get to kind of hang out with these people, even though they don't respond to me.
I still get to hang out with them.
And I think that's a really interesting societal thing that's happening right now.
Yeah.
I think it's beneficial across the board.
I mean, probably like you all, I listen to podcasts outside of tech as well.
And it's sort of like people I'd want to sit in on their conversations anyways.
So, for me, it's probably my primary media consumption aside from books.
Yeah.
But I mean, I'm not reading ancient Greek like Carlton.
Carlton has a PhD and all that.
We're going to talk about specifically deployments on Django.
I mean, we can go on and on about obviously all the intricacies of Django.
But I think suffice to say, I'm an educator and on the board and Carlton's a fellow.
So, he makes the releases happen, including 3.2 Alpha, which just dropped today.
And I guess you mentioned LTS.
So, that's confusing to non-Django people.
So, since having fellows like Carlton, Django has a pretty rapid release cycle where it's
every nine months or so.
So, there was 3.0, 3.1, 3.2.
This December, I think Carlton is 4.0.
One of those is a long-term service release.
So, that'll last two and a half years.
So, if that is a three years.
Yeah, it's on.
There's a link on the Django project site.
So, that's a way that.
So, Django doesn't really have.
It's rare to have breaking changes these days.
But the LTS is designed to help people who can't keep up with that cycle stay up to date.
Though we have a lot of podcasts and opinions about why you should always stay up to date.
And it's worth it.
Yeah.
Because that's one of the most rare things you can do.
Because as Carlton mentioned, there's bug fixes constantly.
So, there's 3.1.1, 3.1.2.
There'll be 3.2.
Then there'll be 3.2.1 a month later or so.
I'm a big advocate of, you know, if you possibly can get on the latest major release.
So, hanging out historically, the long-term release was really important.
The LTS release was really important.
Because there were breaking changes, right?
In each major version of Django, there were new things.
And it was difficult to keep.
But that's not the case anymore.
It's really easy to update.
So, I'm a big advocate of that.
Now, and then when I, you know, I talk to fellow people in the Django community,
they're like, well, you know, I work in the real world.
And you can't always keep up on the latest major version.
So, for those folks, then, you know, the LTS is a really good option.
Because it's once every three years.
You know it's coming.
Yeah.
You get a six-month window of overlap of support.
So, the old LTS gets six months of security release after the release of the new LTS.
And that's your window to update.
Well, I think that running and maintaining software built upon frameworks like Django,
it falls into two categories for me.
It falls into, here's something that we have a team or at least somebody dedicated to owning
this project.
And we care about its ongoing life.
And then we have the ones that are the, oh, please don't touch it.
And the, oh, please don't touch it is we've long since stopped developing that.
Maybe the person who developed it left.
But it's still important.
And we don't want to break it.
It's working right now.
But if you touch it and you break it, you've now adopted it.
You know what I mean?
Like, it's that thing that just, it runs.
It's like if you break the build.
Yes, but, but worse because it's legacy build.
So, to me, I feel like that please don't touch it side, the LTS make perfect sense for them.
Yeah, entirely, entirely.
The way I like to think of it is, is this a thing that you're feasibly going to add new
features to?
And if you're feasibly going to add new features to, then you should be on the latest major
version.
And because it's only, it's once every eight months, you need to allocate a day or two to
keep up, to, you know, fix up, download the new version, run the test suite, see the
deprecation warnings, fix the deprecation warnings.
You know, maybe you have to wait a couple of weeks for a dependency to update and, and
then you can push forward.
And that's once every eight months, that process.
And if you're adding new features, if it's a live project, ideally you'd be there.
There's something which you just need to keep running for the long run.
You know, you could do that much less frequently.
Right.
But it allows people who have that, please don't touch it.
But, oh, there's a security problem.
If there's no LTS and there's a security problem, then not only do they have to figure out how to
redeploy the fix, they've got to say, well, we didn't touch it for three years and it doesn't
quite work the same.
So then you get into the discussion of, well, what's the risk?
Will they really, it's just Java swing.
I mean, come on, what's the problem, right?
How bad could that go with, you know, like the entire world's credit report speed?
Now that we're in Python 3 world, Django was part of that.
It's really beyond the security thing.
It's also all the ecosystem around Django, the third party packages.
Like a lot of times, if you look at their project that says, I can't update, why can't you update?
They did two things.
They're using a third package, which falls into that, you know, touch it, you broke it situation.
Or they did something custom at one point.
They went off the guardrails and the bill comes due.
I mean, it's so tempting.
Actually, I want to, speaking of going off the guardrails, quick note that Django just passed
Flask to have stars, which is a really poor metric of popularity, but nonetheless, we'll take it.
Yeah, congratulations.
That's awesome.
It's very easy to, you know, spin up a couple API endpoints and boom, you're using Flask.
That's a very different thing.
That's like, as DHH would say, that's a Lego versus the Lego truck that is a framework like Django.
And anecdotally, a lot of places use Flask, but in terms of a big site that's all Flask, that's much less common than all Django.
Yeah.
Well, I was thinking about this morning and it, you know, the Flask and Django are pretty neck and neck in terms of popularity.
They're not on GitHub.
Yeah, yeah, sure.
There's these metrics and popularity.
They, there's like all over the map.
So one of the thoughts I had though, is the people that use Flask, this is not a knock against Flask.
I like it.
But one of the, my sort of impressions is if I just need to, like you said, just create a couple APIs and just, we're just going to get something going real small and simple.
And it's just roll.
Like those people are not as invested in the ecosystem and the framework as I feel like the Django folks are.
I feel like the Django folks, it's a more encompassing part of their development.
Like Django feels more part of the project when people adopt it and love it.
I don't know.
What do you guys think about that?
You need a dozen apps to use Flask.
And I hope that we get David Lord on to talk about Flask because he's at Django Cons.
I mean, it's not a competition.
I don't mean to say there's a competition between the two, but there are different purposes, I would say, Carlton, right?
Yeah.
The different styles as well.
Like, you know, if you want to put together something, why not Flask?
But I mean, I've been using Django for so long now that even if I just need to spin up two endpoints, it's much quicker for me to do that in Django than it is to go and get a supposedly micro framework and work out how am I supposed to use this?
We can put the link in the notes.
I made up a repo with the code because you didn't provide code.
You can have a single file Django project the same way you can for Flask because a lot of times that whole little world comparison will lead people to assume that Flask is much less complicated than Django.
And it's a little bit less.
It's more around to how it's structured, which is the point of Carlton's talk.
Yeah. So the talk was called How to Use Django as a Micro Framework or something like that.
And it was about the base HTTP handlers, the kind of that real core of the framework.
And I put up a few examples from different frameworks, like Flask and an old example and Starlet, the async micro framework from Tom Christie.
And then I showed how you might put that together in Django.
Yeah. For people who don't necessarily live and breathe the web stuff like the three of us do.
Yeah.
Give them a quick definition of micro framework before you go on.
Well, in the talk, I was like, you know, what is a micro framework?
Yeah. I'm asking you because I don't want to put my foot out there.
The answer I came up with was it's got a great hello world, right?
Yeah. Okay. Sure.
I think the idea is that it's easier to contrast it with like Rails or Django.
Rails and Django, they come with the batteries included with everything you need.
You know, you've got your ORM or active record.
You've got an ORM, you've got database, you've got migrations, all that stuff.
Yeah. You've got all those stuff.
Whereas your micro framework, you perhaps get the core HTTP handling and that's about it.
And then you have to go and find a forms library.
Okay. I found a forms library.
And then you have to pull in an ORM or a database of that.
Okay. I'll use that.
And, you know, so there are Node full batteries included frameworks.
Like Happy is very good.
It's got everything you need.
But like the classic Node example is, oh, you know, I get Express and I pull in this thing for passing URLs and that thing.
You know, so there's a continuum.
But micro frameworks fit more towards that.
You know, you put the pieces together yourself.
Whereas a batteries included framework like Django, you get not everything but a lot in the box.
Right.
Right. But your experience is more Django pieces, Django building blocks than a little flask, a little SQLAlchemy, a little this, a little that.
Definitely. And I've been doing it so long now that I'd struggle to break out of that.
I just, you know, I throw in a bit of Starlette or a bit of FastAPI, see what's going on with the new frameworks.
Every new framework that comes out, I'll always give it a run.
And then my question is, okay, well, what can we learn from that?
This portion of Talk Python to Me is brought to you by Square.
Do you run or want to build a web application that sells products or services?
Building a successful online business is the stuff that dreams are made of.
But accepting payments and handling credit cards with all the various regulations is a common stumbling block.
But not with Square's payment API.
With Square, your Python web app can easily take payments.
You'll seamlessly be able to accept debit and credit cards as well as Square gift cards.
Let your users pay with their digital wallets.
Square works with Apple Pay, Google Pay, and MasterPass all in one go.
Your API includes PCI compliance, end-to-end encryption, dispute management, and fraud detection.
Build your online payment form in three steps with Square payment SDKs.
Step one, create a new Square API application.
Step two, add Square's payment form to your checkout flow.
Step three, use Square's API to charge the card.
So get started building your business on Square.
Just visit talkpython.fm/square or click the link in your podcast player's show notes.
That's talkpython.fm/square.
A really large site.
If you ask them what language and framework do you use, it's like everything.
Just because of the needs of a massive site, it ends up being...
It's hard to say that it's truly one thing.
I mean, Instagram still has pieces of Django in it.
But at that scale, it's its own thing.
And I think the micro frameworks are really good for doing that.
This might be a pessimistic take, but I've heard people make that a micro framework allows you to switch the complexity from individual developers who may be sharing you just as much up to your upper level because they only can touch a tiny part of the monolith.
So they can, in a way, do less damage.
That's actually an organizational argument for micro frameworks is that only the software architects or the senior people fit it all together.
They weave the pieces or they build the puzzle or whatever.
That, I guess, especially if you're testing suite isn't as good as it could be.
Yeah.
I don't know.
I think there's an interesting conversation about like monolith type software styles versus not.
I'm actually a big fan of the monolith style.
All my attempts to break it into little pieces, at least in the microservices, which is not the same as micro framework, but I always feel like I've quadrupled my deployment complexity to half my software complexity.
And I'd rather manage half as much software complexity as twice as much deployment complexity.
Like if you were part of a five person team in a large organization assigned to fix something and you're just like, there's no way we can get done within this monolith.
But like, oh, we could spin something up and solve the problem and move on.
I play that by a lot.
I think, you know, or an individual project, you get fancy and you customize Django or you use a third party package that is out of date or maybe you shouldn't use any of the same issue.
Yeah, I don't know.
Like, OK, we're segwaying slightly back into the deployment topic, which ostensibly we came to talk about.
But I think the thing with microservices, right?
So if you've got a massive corporation, you can't have all the things going on in one team.
So you need to segment it somehow.
And then you can define service boundaries and it starts to make sense.
Then all the tech blogs become about microservices and how this is the way.
And then learners come along and they're like, well, I've got to build my thing using microservices.
It's like, no, that's really not a good move.
But where are the blog posts?
Not for, you know, and now the pendulum swings back.
And, you know, there are lots of posts now about how monoliths are making return and how they're the way to go.
And so hopefully the beginners come and see those posts.
But when you're learning and everyone's saying, oh, you must use a microservice architecture.
It's like, hang on.
Yeah, because the people who are knowledgeable are writing about their day job.
They're not writing about spinning up a Django app on a weekend, which is possible.
And you can deploy it, too, which we could.
Should we get into that deployment?
I do want to just point out, I think this might be the article that I read before.
Like the, yeah, you're not Google.
You're not LinkedIn.
You're not Facebook.
You're not Netflix.
There are people who actually that's an inaccurate statement about.
There's plenty of people that work at those companies.
But like you said, Carlton, the people who come along, they see these companies who they respect and say they must be doing it right.
And so often with these deployment stories, with these design patterns, you know, should you have like separate caching servers that run like something like Redis?
Yes, you should.
No, you shouldn't.
And that's the right answer at the same time.
But with the context that you need, right?
Are you trying to run 10,000 servers and let 500 people work on this project?
Or are you two people trying to do a startup?
Like those are not the same tradeoffs and balances you want to make, right?
Yeah.
And it depends as well on your model.
So one example that I really like is Stack Overflow.
Now they're built entirely on the Microsoft stack.
So they've got SQL Server and they're using .NET.
But the basic point is they've got a really big database one and then, you know, a few worker processes in front of those.
And that's it.
It's a classic monolith.
And they're one of the biggest sites on the internet.
And yet they're incredibly fast.
Yeah, exactly.
As fast as you could ever want.
Okay.
They do it in this kind of monolith, old school style, you know, vertical scale.
Make it just bigger.
Don't spin out parallels.
Just make the thing bigger.
Buy a bigger database server.
So that's, you're not going to be bigger than Stack Overflow, right?
Right.
And then another example we have.
And when you are, you'll reevaluate it anyway.
Whatever you do now is not going to solve that problem.
Yeah.
But you're not going to be bigger than Stack Overflow.
And then we had another example, which was Dr. On Demand.
They came on, Matt Lehman from Dr. On Demand came on Django Chat recently.
They've got a more containerized approach to it.
But the thing is, they're doing peer-to-peer communication between, you know, many simultaneous peer-to-peer video communications.
Because Dr. On Demand is like a telemedicine, right?
Right, right.
Like, I need to book a video appointment with my doctor.
Yeah, exactly.
And so, but they've got so many of those processes needed to be spun up that they need something which scales out and then back down again very easily.
So they've got a kind of more, like, modern, more, a cooler technology.
They're not as big as Stack Overflow probably in terms of raw traffic.
But they need that flexibility of architecture.
That's what we always think about, right?
We say, it depends.
That's our timeline.
Yeah, it depends.
It depends.
Yeah.
Exactly.
That's your subtitle.
I do think the context, right?
When people talk about design patterns, deployment, architecture, those are always within a silent, not mentioned most of the time context in which that makes sense.
And you've got to decide, are you in that context or are you not?
Yeah, no, entirely.
I should say, what problems are you trying to solve?
Like, you can't innovate everywhere.
Like, there's so many pieces to a website.
Do you want to innovate on deployment?
Not until you're, you know, Instagram, I don't think.
No, well, I think that's a great point.
And it's when you're small, the most important thing is adding features and going quick, right?
When you get bigger, the most important thing is to not go down, right?
If random little project that is like an ordering service for a restaurant in Milwaukee, if it goes down for half an hour, it's not ideal, but it's not the end of the world.
If Google goes down for half an hour, people really notice.
You know, it's like front page news type.
So it's just a totally different thing.
Now, before we move on to more deployment stuff, and we're kind of in there, I do, before we get away too far, maybe we could touch real quickly on some of the new features that are coming in 3.2 and like the Django 3 stuff that you guys are excited about.
Yeah, maybe can you start with just 3 in general, Carlton?
Because I think that makes 3.2 have more context.
Well, okay.
So, but 3 introduced, 3 began the process for making Django async, right?
So we added, so historically, Python has this WSGI, the web service gateway interface.
So Django is a WSGI framework.
Flask is a WSGI framework.
It was this standard so that application servers could talk to protocol servers, which could talk to the internet without, you know, each framework having to have its own protocol server.
So Gunnicorn is a WSGI server, and it can speak to Flask, and it can speak to Django, and it can speak to any other WSGI server.
Right.
You can use that, and I can use micro WSGI, and it's, we don't have to coordinate or do anything.
It just happens.
That's because of the WSGI or WSGI thing, right?
Yeah.
So that's the standard.
And so in order to make things async, there's this thing called ASCII, which is the asynchronous gateway interface.
I don't know.
Yeah, I don't know.
I don't really, yeah.
Anyway, it's not WSGI, it's ASCII.
So first of all, Django 3.0 brought in an ASCII handler.
So it wasn't async at all, but you could run it under an ASCII server.
And then 3.1 brought in actual async views.
And you can define an async def view, and you can use, I don't know, HTTPX, which is like an asynchronous HTTP client with a request.
Yeah, it's like requests, but async.
Right.
Or what's the ORM story?
Does that support async at await yet?
Right.
No.
So that's not there yet.
So this is something that will develop probably over the course of the Django 4 lifestyle.
So there's plans and there's thoughts.
And we need to get to the point where you, with the ORM, where you can, down to your kind of filter call.
And so things like filter, they can be totally synchronous because they don't actually do any IO.
They don't actually hit the database.
But when you then go, right, I've got my query set and I'm going to iterate it and I'm going to fetch the objects from the database.
We need that bit.
Even if the actual connection is run in a thread or whatever, we need that bit to be fully async.
And then Django will feel async as it is.
At the moment, if you write an async for you in Django, you kind of have to say, well, I'm not going to touch the DB.
I'm not going to.
Yeah.
You can wrap the ORM in async to async wrapper, but you kind of lose the point of that.
Yeah.
But that's coming, right?
Yeah.
So Andrew, yeah.
So Andrew Godwin, who's driving this effort, he gave a talk at DjangoCon Europe about the structuring of this and what it's going to look like.
And it's like, yeah, that makes sense.
This is going to work.
And we don't have to get, what's nice is we don't have to get async all the way down to the very bottom because we can run the actual, we can sort of hand off the actual database connection in a thread executor.
But from the outside of the ORM, it will look async.
And then you can, you know, you can stream out your content records of maximum throughput as you want to, that kind of thing.
Yeah.
Well, the fact that you can already do external APIs.
And if you're going down the microservice path, you can do your microservice calls with HTTPX and await those.
That's already a huge step.
Yeah.
So without, and this works, what's amazing about the way Andrew is just absolute hero, but he put it together in such a way that you can run this with a WSGI service.
You're running Django 3.1 with GunnerCorn.
Like you always have.
Yeah.
And you think to yourself, I just need to make a couple of API calls, but they're quite slow and I want to make them in parallel.
You can do that just by writing an async def call and then, you know, making the parallel calls using HTTPX.
And it just works.
And Django does all the rest for you and adapts it.
And you didn't have to change your application server.
You didn't have to do, you know, it's just like, yeah, we've got async just there.
One of the challenges if you're talking to the database is you say, okay, fine.
The bottleneck was we are waiting at the web server level, at the Django level.
And then we're going to push that down to the database.
We're going to just make all that async.
All of a sudden, all the pressure is now on the database, which can be a problem.
But if you're talking external APIs, you're now pushing the pressure onto the internet, which is way scalable.
Yeah.
And it's always going to scale more than you, right?
You're not going to need that many client requests probably.
Yeah.
Also, David Smith out there says 3.2 will be a great release.
You guys have done a great job getting many patches over.
Yeah, for sure.
Thank you, David.
Super.
We were working really hard.
We had two longer lists and we got, you know, one we had to bump for Django 4.0, but the rest we got in.
So we were very good.
Okay, so 3.0, acing it away.
This is a big deal.
Yeah.
And so those are the big features for 3.0.
And then what's coming in 3.2, we've got various other bits and bobs.
You can customize primary keys.
So traditionally, they've just been autofield, which is in 32.
Well, eventually, you know, if you get 22 billion of those or something, you can run out.
So you can now customize that for big in.
And over the next couple of releases, you know, major releases, we will make the default big in because that's probably what it should be in 64.
Because then you're never going to run out of primary keys.
But that's something that big sites run into that, especially if you start creating, I don't know, events, an event log.
Yeah.
You know, a site can generate a lot of events and they can add up quickly.
You know, so.
Yeah, they definitely can.
Functional indexes in the ORM.
So you can create an index on an expression like that these were greater than or that the sum of this was.
And then you can query on those at full speed because they're indexed.
That's a really big feature.
Oh, really?
So you can do a query like the sum of the orders of this.
The customer is greater than $100.
Yeah.
And that's a relationship.
Yeah.
And then you can create an index on that value.
And you've been able to do that in raw SQL for, you know, any amount of time.
But that's now exposed at the ORM level.
And that's nice.
That's awesome.
You can just kind of.
Yeah.
For people who are doing reporting or that kind of thing.
Yeah.
That's massive.
This portion of Talk Python to me is sponsored by Linode.
Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines.
Develop, deploy, and scale your modern applications faster and easier.
Whether you're developing a personal project or managing large workloads, you deserve simple, affordable, and accessible cloud computing solutions.
As listeners of Talk Python to me, you'll get a $100 free credit.
You can find all the details at talkpython.fm/Linode.
Linode has data centers around the world with the same simple and consistent pricing regardless of location.
Just choose the data center that's nearest to your users.
You'll also receive 24-7, 365 human support with no tiers or handoffs regardless of your plan size.
You can choose shared and dedicated compute instances,
or you can use your $100 in credit on S3 compatible object storage,
managed Kubernetes clusters, and more.
If it runs on Linux, it runs on Linode.
Visit talkpython.fm/Linode or click the link in your show notes,
then click that create free account button to get started.
And then we've got, I don't know, a new memcache backend for the cache.
We've got, you know, updating the API for using the admin for nice decorator API for creating various admin customizations.
We've got themes in the admin.
We're going to ship a dark thing.
It's a big one for people to see right away.
Because the Django admin could use a refresh and there's been all sorts of third-party ways to customize it,
but now be built in a bit more.
There's all sorts.
In the blog post for the author, I described it as a mess of new features.
And that's exactly what it is.
But what's nice is it's not, there aren't, apart from async, which is coming,
there aren't any new major features in Django, right?
It's 15 years old.
It's rich and mature and largely feature complete.
But each major release, each eight months, it always amazes me when we're drawing to get up the final release notes,
how much depth and extra, like, substance there is in the features that we've managed to add
and that have been contributed over that eight-month period.
Yeah, that's fantastic.
So I feel like you're capturing much of the modern Python awesomeness.
One other area that's, I think, interesting.
I have no idea what your plans are around it,
but maybe you could just give us your thoughts, is type hints, type annotations.
Yep.
That's difficult for us.
Carl, about that a little bit.
Yeah, I mean, that's difficult for us because Django, I mean, if you take the awesomeness,
it's super dynamic.
And there's an amazing project, Django Stubs, where they've got stub files and they've got,
you know, they've done a super job.
And it really does work well.
So if you load up VS Code or PyCharm these days,
you get very good autocomplete around things like Django model field definitions.
Yeah.
And that's all powered by Django Stubs.
Yeah.
Which probably is powered by type hints underneath, right?
Yeah, yeah.
It totally is.
A year or so ago, there was some discussion about whether we would make those inline hints
in Django itself.
And the technical board at the time said, no,
we need the typing technology to evolve a little bit further in Python itself before Django can
jump on and say, look, we endorse this particular technology.
There is, there's various ways of doing it and various type hinting, type checkers and various.
And so, so we, we favored mypy, which is obviously the endorsed one.
Well, what about the others?
We can't support them all and they might change and-
PyWrite and all the different various initiatives.
Yeah.
We can't take it out once it's in.
The thing with, the reason why people love Django is because it's super stable.
You know, you write a site five years later, you don't really have to do very much to keep
it going.
And so the technical board at the time said, no, we're not going to bring those type hints
into Django, but that will be reviewed.
You know, we'll look at it again in a little while's time.
One thing I will say about typing in all the peps, it says type hints remain optional.
They're not meant to be compulsory, even by convention.
Do you feel maintaining Django a certain pressure to have them?
I do worry that that optionality of type hints is perhaps undermined a little bit in the day
to day development.
I'm not sure.
I also code in Swift, right?
Which is a fully statically typed.
Swift is pretty strong in its syntax.
Like you can't even null out.
Yeah.
Even if they could be, right?
If there's not allowed to be optional, explicit, there's a lot of interesting stuff happening
in the Swift type.
Yeah.
I mean, Swift is a fantastic language, but there's no option.
It's type hints or it's type annotations all the way.
And then when I come back to Python after a few hours of that, I'm like, oh, this is so
breath of fresh air.
You know, the thing that I really, the comparison that I make a lot is between TypeScript, which
is type annotations for JavaScript and Python type hints.
And I always walk away from TypeScript feeling like, ah, that was way harder than it should
have been.
Why was it so frustrating and fighting me?
Whereas in Python, you might get some squigglies because you didn't quite define something just
right or it wasn't defined at all.
But then it just, it carries on, right?
Whereas things that are completely, it must work within this context.
They can become challenging, especially the reason I bring up TypeScript is the stuff that
it brings in is not necessarily typed, just like Python.
Whereas Swift is end to end.
It's all from scratch under that same system.
So it's coherent.
But bringing in, say, jQuery into TypeScript, like there's no TypeScript jQuery.
I know there's like stubs you can put on and whatnot, but like that kind of stuff is more
Python-like.
And so I think it's pretty interesting.
Yeah.
And Django's in that very much in that boat where it was never written with type hints in
mind.
Yeah, of course they didn't exist.
And if you look at Django stubs, it's awesome.
But a lot of the things are like string or any.
And it's like, that's horrible, right?
You don't want to write that every single time.
That's an issue.
And then another thing I see, which I'm not sure about, sometimes they make a type like
a model, the Django model admin, they make it a generic that takes the model type, which
tells you what it's the admin of.
And I remember, and I look at that and I wince a little bit.
You're like back to C++ templates or something, right?
Yeah, yeah, yeah.
And I see where they're going with that.
It's amazing what they've been able to do there.
But I remember coding Objective-C UI Table View, say.
And what you would always do is you get object, your row class in from the UI Table View delegate
where you're getting a list of cells, right?
So like a list of email messages.
And you'd immediately cast it to the type you wanted so that you knew what you were dealing
with.
Yeah.
In a way, when I get something back from a model admin, I'm quite happy to write colon
model name.
Yeah.
To tell the editor what it's meant to be.
To tell the type checker what it's meant to be.
And then for the rest of the method, I get the autocomplete.
I get the type checking.
And you probably don't put any more type hints because it's just now flows.
And it's, I agree.
It's so good at generating, like allowing you to generate code incredibly fast if the tool
supports it.
One quick comment or thought that before we move on, this having types around the ORM
is really interesting because all the big ORMs seem to do the same basic flow.
You know, I'm thinking, you know, Django ORM, SQLAlchemy, even NoSQL ones like Mongo Engine,
which I use.
They all have a class which has the columns defined as descriptors.
So at definition time, they create the tables or the collections.
And then at runtime, they become the scalar versions of the thing they say they are, right?
That an integer column is now actually an integer.
So what I've done when I define the model class is say like name colon str equals string
column.
And so the Python thinks it's all the types are actually what I said, the primary types like
in the model.
And then the underlying ORM can do what it needs to do.
But, you know, the rest of my code is like, oh, that's a float column right there or float
field.
That's been really helpful.
I don't know.
I haven't run into any problems doing that, but it's been pretty helpful.
Yeah.
I mean, it's the thing that brings my talk.
Well, there's data classes, right?
Which they brought in in 3.7 or 3.8.
Yeah.
And then Pydantic is an exciting thing, which is...
Pydantic is fantastic.
Yeah.
You define a model, call it a model with exactly this.
It's like field name type with an annotation string or int or whatever.
And that works really well.
And I can imagine us generating Django ORM models from that kind of thing.
But then you end up needing options.
Like, is it nullable?
Or is it, you know, is it required?
Is it...
What validators does this field have?
And then it starts...
When you start to add validation, it starts to look almost like what we've got now.
I mean, Pydantic's got one good advantage in raw serialization speed.
It's very fast.
So that's something we can learn.
But the short answer is, I don't know.
But it's exciting times, isn't it?
It's very exciting times.
All right.
Let's talk really quickly about maintaining your content or things that you generate.
Like, you guys all write articles, books, do online stuff, even podcasts.
So 3.2 is out.
What broke?
Like, real quickly, Will, maybe you want to just talk about what you've been doing to...
Yeah, there's a reason why there's very up-to-date Django books, because the release cycle of every
nine months doesn't overlap with the traditional publisher cycle.
So for me, I mean, I'm on version, I think, five for most of the books.
So I was on 110 or 111.
So it's sort of like writing the book again.
Every time I basically go through from scratch, because all the code is linked to the text.
Because I'm self-published, I can do all that.
I have my flow down.
So really, I have a list of new features I know that are in there.
So I'll play around with them to make sure that things don't break.
And then I'm constantly emailing with readers.
So I have feedback on what works and what doesn't.
So half the new features are fixing things so it's smooth.
And then half just making the text.
So at this point, I feel pretty good about the flow of all three.
And people will say, what about this?
And maybe I can explain it a little bit better.
I added, I mean, so for a 3.1 added in the beginner's book, I really wanted to have proper
deployments, but not go as deep as I do in the professional's book.
So I did introduce environment variables and showed, I think, a pretty elegant way to get
environment variables and to have some lockdown for deployed site.
Whereas before in beginners, it was just sort of like the local version, which is pretty open,
was what you deployed because it was more about getting something up.
I was able to introduce environment variables.
We could talk about that more.
There's a third party package.
It's great.
So that's always the tension for me is showing and telling, right?
Like I want to explain everything, but I don't want to overwhelm people.
And so that's part of the thing I have to think about for 3.1.
And I think also for Django being so stable, at least you can say all the stuff is still
the same.
There's just new features we haven't mentioned or a new way maybe is better, but as opposed
to this does not work anymore.
Well, it's the difference between what trips the professional programmer and someone who's
new.
So for example, in 3.1, the pathlib was added when you create a new Django project, the settings.py
file, which is the default settings.
The way the routes are done is a little bit different.
Like a minute stack overflow thing for someone who's used to using Django.
or the breaking stuff, but that can completely derail a beginner.
There's usually a couple of things like that.
You know, so in that case, like I have a dedicated blog post because I knew that was coming.
And just this morning, I got more questions around it.
So it's that's sort of the thing that fun me is figuring out how do I, you know, be compassionate
to the true beginners, but we're more further along.
It's a lot of work to do.
I don't know how you could do it.
I don't either.
I was just dealing with some GitHub issues on some folks who are having trouble because a
mismatch of pip upgrades and other packages.
And it's just like, it's just how it goes.
Real quick, John from the live stream is really excited about the admin themes.
So that's really cool that that is going to come along.
Thanks, Sean.
They add up to greatness.
I think that's, I love that.
Yeah, that's a great, great say.
All right.
We talked a lot about deployment already, which is why I've been dancing around a bit.
But let's go ahead and talk about deployment.
So when I create a web application with Django or really honestly with Flask or anything, I've
got a cool app.
But it's, you know, web apps are not generally meant for the individual.
They are meant to go on the internet and be amazing and connect things and allow other people
to do stuff.
And that's a huge gap, right?
So maybe I've just learned how to do Django.
You just talked about your beginner's book, Will, and I finally got that one page that
wouldn't show.
And the database stopped, you know, crashing when I did that one query because I checked
for none now and it's all good.
Wait, I have to learn Linux and I have to become an admin and what the heck just happened, right?
So how do you guys approach that?
What do you tell that person?
Yeah.
First of all, hand on shoulder, I feel you because it's just there's this massive deployment
gap.
We've got the Django tutorial.
We've got the Django girls tutorial.
We've got the Django rest framework tutorial.
People have done those.
They've got their app together.
They've come up with some ideas.
They've learned a teeny bit of JavaScript to make it that bit better.
And now put it online.
And exactly this, I've got to learn Linux.
Oh my word.
Yeah.
Among other things.
I mean, it's two things though, right?
I think, I think like when I think about this, oh, there's, there's two ways to think
about it.
One is making it friendly, which we can talk about.
And then there's the specifics of, do I, you know, do I do it on a VPS?
Do I do it on a pass?
So there's two separate things.
The first one, I think we can generalize and Django has some good notes on that.
The second one is sort of a deep end of opinion.
I guess I'm in favor of like, I use, I'm a big fan of platforms.
If somebody had something that like hosted AWS for Django, I would use that.
I mean, so, and I'm just going to throw it in here now.
I'm working on a app for this exact problem.
It's called button.
It's btn.dev.
And it's the idea is to be able to spin up a small environment for this exact.
I just want to get my app on line use case without, you know, you're having to become
a sysadmin expert.
Yeah. So the spectrum looks like to me pass, right?
Platform as a service, which you said you like Heroku and there's other options as well.
Yeah. Heroku, DigitalOcean.
Then I think maybe button is even before that.
I'm not entirely sure.
Like in terms of complexity.
Let me jump in.
You've got the platform as a service.
You've got Heroku, which is there at one end.
And that's kind of like, they'll run your app, but they don't, that's it.
Right. Or, you know, you can run another worker instance, but then you say to yourself,
I want to, I just want to put a file online.
And it's like, well, how on earth do I do that?
I can't. Or I want to put up a static website.
So I've got to bring in, I know, Netlify because another service.
Yeah. Netlify is really nice for just pure static sites.
Actually.
Yeah.
It is. It's awesome.
But then all of a sudden you're running two services and then you want to do some log analysis.
So you've got to bring in and it's like, oh, hang on.
I've got three services now running and it's, it gets a bit out of hand.
So then on the other hand, you've got AWS and you go to AWS and it's like, oh my word.
You know, it's the paradox of choice.
It's just like that in Azure.
I mean, they're both incredibly powerful, but it's just like, oh my goodness.
Look at this admin dashboard.
Like I, there's huge thing with a 50 choices.
I go into one and it expands into 20 and then I need to figure out the right one of those 20.
It's just, it's mind boggling.
Yeah, exactly.
And so where button fits in that is it's on AWS, but it provides a very simplified environment.
This is because it's part tool.
It's a tool to do it, but also a guide that says, look, this is how you should deploy.
So the app puts together the environment for how you should deploy your Django app or, you
know, you can do any app, but you know, I begin with Django because that's where obviously
what I know.
And then the difference between, well, why wouldn't I, why would I use that instead of
a platform as a service like Kuroka?
Well, because if you go out of it, it's just AWS.
And so you can go on and move on to other things and you can export to.
When you do go closer to now you are kind of Google or whatever.
You've got a growth path.
Obviously not, not far down that road, but a little ways you can go, oh, we actually need
to do this other thing.
Yeah.
And so that's what I'm aiming for.
And that that's launching very soon.
It'd be early access by the middle of February.
You know, beta by end of the quarter.
And then what I call version, what ends the beach?
I don't know.
End of the year, I would imagine.
Yeah.
That sounds really cool.
We'll definitely link to it in the show notes.
When I was pausing there, I said, okay, well, on one end we have pass like Heroku and other
platform as a service options.
What is the other end?
Is the other end Linux virtual machines or is the other end Kubernetes clusters?
It's Kubernetes cluster.
It's well beyond virtual machines, right?
So like to spin up a virtual machine is not a problem.
The problem is that you get a bare OS and then you've got to do all the app to get installed
to turn it into something you can deploy on.
Right.
And then you do that once.
And then the second problem is that six months later you need to upgrade it and you've got
to replace that VM.
So that's very difficult.
And I think that's what leads people into this kind of world of containers.
And then into containers, it's like, oh, well, I've got, I need an orchestration platform
to, ah, and that's, there are people who make a career doing that.
Yeah.
You can't expect to do that sensibly.
I agree with Carlton.
It depends slightly in that, like, so in my professionals book, we, I show how to use Docker
and Docker is for a smaller site.
I think actually you can put your containers online so you can, in a lot of different flow
is actually quite nice.
But I agree with Carlton's broader point about, you know, that is and all the rest.
It's, I feel like is the goal.
I'm setting up a Kubernetes cluster and I'm running the data layer and I'm running the caching
layer.
And I'm, if you're managing that whole thing in a cluster, you're at the far right end
of the most complicated.
But if I'm going to deploy to a hosted Kubernetes container and consume a database as a service
and a caching tier as a service, then it starts to fall back to, well, I just get my
container to run and plug in these connection strings and we're good to go.
I think there's, it can kind of live on both sides, honestly.
There's different approaches and different sweet spots for each individual.
The difference for me is you can containerize your application and run it up, but where do
you container that to?
Where do you run that container?
Is that on a set of VMs, which you provisioned yourself and put a container management system
on like Kubernetes?
Or is that on somebody else?
Like, is it basically service, the Cloud Run?
Cloud Run takes your container and runs it and you don't know anything about where it's
running.
So that's more like a platform as a service again.
Yeah, it is.
It falls back in that.
So Will said he's a fan of Heroku.
Carlton, let me ask you this question.
If you were writing an application in Django that was expected to get 5 million data-driven,
like proper requests, not for CSS and whatnot, but proper requests a month, how would you deploy
it right now?
I would deploy it on a pretty big VM with as many process workers as I need.
So I'd put stick Nginx as my front end.
Perhaps I'd probably use something like application load balance in front of it, one of these things
that AWS will provide or Azure have got their equivalent load balancer.
Then I'd have my Nginx, which is serving my static files.
Behind that, I'd probably have two, three.
It's also doing SSL, for example, right?
Your Let's Encrypt bits.
Yeah.
Yeah, yeah.
And they're handing all certificate renewals and all of that kind of thing, which is probably
worth the money because it only takes you a few minutes.
But you forget and then your site goes down and no, just hand all that stuff off.
So I'd put that on a nice size VM.
I'd have, you know, three, four, five Gunnicorn workers serving the application instances,
load balanced behind Nginx.
And then I'd have Postgres on a decent size RDS, which is a managed database service behind
it.
As a first preference, I would scale up the VM and I would scale up the RDS rather than-
Way before you scale out.
Yeah, way before I scale out.
Yeah, I agree.
Like if you can, as soon as you have them scaled out, it gets tricky, right?
You become, it takes you up a notch in that DevOps story.
At that point, you're hiring, you know, an extra hand just to manage the ops, an extra
hand to manage the ops.
Yeah.
It's like, well, what was the revenue of the application that justified that the salary and
the social security of that extra hand?
Yeah.
I mean, maybe you're like, well, I don't really want to pay for that larger VM that's $80 a
month instead of $10 a month.
But if the alternative is now we spend human hours on making, you know, three $10 VMs run,
you know, it's so easy for businesses to become Pennywise pound foolish around these kinds
of things, right?
It's just like, oh, we can't get you a new monitor, a new keyboard.
Like, really?
You pay me like $80,000 a year and you won't give me a new keyboard to be more productive?
Or I feel like that's the deployment equivalent of that.
Yeah.
No, it's penny pinching for no reason.
I mean, the other great example is Sentry, right?
So Sentry is your kind of, you log all your errors to it, send your exceptions to it.
It gives you great stack traces and it links it back to GitHub.
It's awesome.
Why would you not have this?
And then you're on the free account, you know, it'd give you 5,000 events a month or something.
And it's like, oh, we need 30 bucks to get onto the, like the million events a month.
The manager's like, no, you can't have paid Sentry.
You're like, what?
What are you talking about?
So then you stop logging.
You're like, well, we can't log that event because of Sentry.
And then you're blind.
And then your app goes down and you spend four hours trying to work out what it is while you're losing business.
Like, that was 30 bucks a month for Sentry.
Just pay it.
But I think it depends if your manager has felt that pay as an individual contributor themselves, right?
Because if they haven't, then yeah, stop complaining, developer, you know?
But yeah, you should, I always thought, I mean, at Quizlet, which is now like half of all high school students,
we had a joint, which I hope they're still around.
They're a hosting company, but we were having scaling issues.
They came in and we had the whole team CTO, which was great.
And, you know, at the end of the day, they were just like, you need bigger hardware, you know?
Get more hardware.
If you can get more, you know, and as a business person, if you can throw money at a scaling problem,
like, yeah, that's the easiest money you've spent.
Yeah.
You know, so what I'm doing right now, Carlton, is I'm running Nginx on Ubuntu, but I'm using MicroWhisgee.
And I came across this, although as I'm starting to think about the ASGI stuff,
Gunicorn, Genicorn, and like UVicorn worker processes is starting to look like a really awesome thing.
But what I wanted to point out is there's this great article by the Bloomberg tech folks
talking about configuring MicroWhisgee for production.
And man, do they have a bunch of good little tips of like, well, here's all these things,
but oh, did you know if you turn on like enable threads versus not, or if you set single interpreter
mode to true, you automatically get better performance because it was configured to potentially run
like Python 3.7 and 3.8 at the same time.
And you're never going to do that in one process, most likely.
And there's just all these really fantastic settings and like vacuum and whatnot to clean up sockets and whatnot.
So people, if they're running MicroWhisgee in production, they should absolutely check that out.
That's a really, I read it a bunch of the way I was doing things after reading that one.
Just scroll to the image at the top, if you would please, Michael, because a little diagram that I had.
Yeah.
But like, yeah, so that looks almost exactly how I deploy.
Like Nginx in front of a worker process, you know, that's running your Python applications
and, you know, talking to your database.
Yeah, exactly.
It's, it's pretty standard.
Yeah.
They got memcached in there.
So I'd, I'd have Redis instead of memcached, but same deal.
Yeah.
There's a comment about, does EC2 sit between a VPS and Kubernetes?
Yeah.
Since you're AWS expert.
Okay.
Well, I don't know about expert, but so, but on AWS, like you, this is what I haven't found in AWS.
Like I would love to love their light sale product, but it just seems totally uncared where they,
they kind of manage the cluster all for you.
But on the, the, I can't even remember what the cluster services called, but the,
you have to provision the EC2 instances and you can do it quite easy.
It's not hard to do, but you have to spin those up and they're kind of your responsibility.
And then it will run the cluster service on top of it.
The Kubernetes on top of it.
And then you deploy your containers in there.
This is where something like Cloud Run is a bit easier because you don't have that layer of I'm
provisioning the, the underlying instances myself.
And you have to choose the size of them and you can scale them up easily enough, but you
know it's, it's, it's non-trivial to set up a cluster on AWS.
Yeah.
That's always been my feeling as well.
I also feel like you're sort of committed to their hosted services.
And if for some reason you don't want to use them, the step is not a tiny bit more.
It's a bigger, a much bigger step to like try to rework that.
Yeah.
The example is run, you can run your own Postgres on EC2 instances when, you know, you can provision
the disks and you can do all that rather than RDS.
And for me, I'm like, okay, if you've got a very specialist use case, then yeah, do that.
But RDS is great.
Just use RDS.
Just use the hosted service because again, you're saving money and yet it's a bit more expensive
hour, but not as expensive as you, your time, your life force.
Yeah.
Well, I think also it depends, right?
Are you one single person who is building up an idea and you have zero revenue and you're
just trying to do this for two hours a week to see if you can get a little tiny bit of traction.
Maybe it is worth an extra five hours, right?
Versus I have actual money coming in the door and I'm trading out building this feature or
that feature.
Like those are really very different contexts.
Also though, you get yourself a Raspberry Pi and you can install Nginx on it and Postgres
on it.
And no, but you can run all those, right?
And you can do it locally and you can bet you can run a Apache bench again against it and
you, it will serve plenty.
So you can get not the nano one, but yeah, sure.
But you can get, you can run Postgres is my point.
You don't need RDS to run a small Postgres, but if you're running a slightly bigger one, then
yeah, use RDS.
And then if you're a specialist and you really need to customize your Postgres somehow,
then okay.
Yeah.
You know, spin up the EC2, install Postgres on it and customize it to your heart's content.
But that's well beyond my skill level.
And yeah.
This is why they have hundreds or thousands of employees, right?
Like when people say, why do the big companies do that?
It's like, well, why does Instagram have a thousand, whatever thousand engineers when Carlton,
you and I could spin up a, you know, a prototype relatively quickly.
It's like, because we're not dealing with the traffic they are.
And so it just gets exponentially harder, which is why you need a lot of people for all these
issues.
Absolutely.
Will, you mentioned something really interesting there that I would like to just touch on for
a moment.
Then we're getting short on time.
You said you could run SQLite.
Oh, well, so that Carlton has a good story about SQLite.
I mean, about how it's, so generally people say, well, you can't use it.
You shouldn't use it at all.
But there are some cases where that's not the case.
I mean, if it's a read heavy application, you can probably get away with it.
Simon Wilson's doing a lot with data set.
Yeah.
I just had him on the show.
His episode just came out this week, actually.
Yeah.
He's great.
And that is such a cool project.
I feel like that is actually an undersold story for the beginners, right?
Because deployment of web application often means deployment of web application plus database
server, plus backups of database server, plus like all of a sudden it goes from, you know,
20% to 90% hard or whatever, right?
Or you go to hosted and you're like, okay, well, I still got to backup that thing potentially.
And, you know, there's just, you've got potential migrations.
I don't know.
There's a lot of stuff going on.
And if you can say, well, until you actually get much traffic, you can just say, here's
the DB file and the SQLite connection on the one machine that I have.
And you back up that file every now and then, that might be a good story.
If the alternative is it's too much for me to get my app out.
Yeah, yeah.
No, definitely.
Especially if it's a blog or a content site, like a shop catalog where it's all read only
and, you know, maybe you're using the admin to manage the content on it.
If it's only one person using the admin, you're not going to have concurrent rights, which
is the thing about SQLite.
And so it's never going to be an issue.
And it is fast.
It's fast.
Read only workloads.
It's fast.
It's fast enough.
It's yeah, it's very fast.
Yeah, you can use it.
And there's no server for people who don't understand are not totally aware.
Like it comes with Python and it runs in process.
There's no other server to set up and connect to.
Yeah.
So Carlton correct me on that at one point, because I was saying, oh yeah, no SQLite.
And he was, so I have to give credit to Carlton for there are some instances.
Here's the secret about SQLite.
It's got a writer headlock.
A wow mode, which means that actually you've got a good chance of being able to do kind
of concurrent rights to Django's ORM has got a retry value, which if you set that, you know,
you know, a little bit higher.
If it gets database locked, it will try again in a second.
And then, you know, you can go quite a long way enabling these things.
And then when you finally in production actually get a database was locked error, then you could
think, you know what?
I think it's time we move to post.
Yeah.
In my world, I'm running MagaDB as the database.
And it doesn't make sense to consider running that on SQLite.
But I can remember back when I first started deployment, like, okay, well, I got to learn Linux.
I got to learn Ingenx.
I got to learn MicroWisgee.
Like, okay, what other deployment?
Like, how do I have to learn running my database on these things?
There's just, there was a lot.
And I can definitely see if you could say, well, here's an intermediate step to get it
out and get it going.
And then you just change the connection string at some point over to a big separate server.
I think that's a really good path.
It's a little bit like, you know, raw SQL versus Django models.
This is timely because I've had a thread emailing with a reader who doesn't quite, has something
in mind.
And he's like, I modeled it all out, the scheme all out in SQL.
And SQL is easy to learn the basics and really hard at scale.
And while Django lets you write SQL, you really, really, really should resist doing that unless
you're a way better programmer than I am.
So whereas before you would have to learn tons of stuff, the same thing with deployment,
you can get a lot of the way there by trusting someone who says, until you need it, don't
bother.
The same thing with database stuff.
Like, okay, you know, do some basic SQL, understand a little bit of the relations, but that's the
power of the Django ORM is that it will handle so much of this for you.
And if you think you need to go custom, unless, you know, if you have any doubts, you shouldn't
do it.
Yeah.
And the migration side, that's a huge part of a challenge if you were maintaining it yourself.
Yeah.
I mean, I was, you know, Andrew, Andrew was responsible for the, doing most of the, a lot
of the async stuff now.
Nice.
All right, guys, we're getting short on time, but I do want to just really quickly cover
one more thing.
Servers up and running, feels like it works.
I watched it all day.
It was fine.
I want to walk away from my desk.
I want to know that it's probably still fine.
And to me, like Carlton, you already talked about one thing.
There's some really great monitoring services that you integrate at the API level.
Like you plug in as a library to your code.
Sentry being one of them.
They're really great.
They sponsored the show for a while.
Thanks for that as well.
But I use Sentry on.
Yeah, they're great.
And I, I've got Sentry running on my apps and every now and then I'll get an email.
And a lot of, at this point, when I first integrated that type of service, I got a lot of, oh, I
didn't know that was happening.
Oh crap.
I'm going to have to fix that.
Well, that's why there's a lot of logging and stuff, right?
Yeah.
Yeah, absolutely.
And once I kind of dialed in now, it's more like, well, somebody tried to send like some
binary hacky thing that broke the URL parsing, but it's not really a problem.
It's just right.
But having that thing there is, is really important.
I think.
Yes, absolutely.
Absolutely.
Sentry.
I, I just can't see a reason not to use it.
Even if they've got the free plan.
Why wouldn't you have that?
Yeah.
The free tier, like once you run out, you can decide whether or not you want to pay for it.
But, you know, at least get, get us some kind of insight into the errors that are happening.
Yeah.
The other thing that I'm a fan of is Prometheus.
It takes a teeny bit of setting up, but again, you can get yourself a Raspberry Pi and you
can play with that locally.
And it's not that hard.
You can put it on your Mac or you put it on your Windows machine.
It will run, but get a Raspberry Pi, set it up, monitor the device.
Prometheus is good fun.
There's a dashboard that goes with it called Grafana.
And then they do a log thing called Locky, which, you know, you have to configure it yourself,
but it teaches you about your application.
You have to say, okay, I want to monitor this.
And then you can put a little couple of tags in and then, okay, you get metrics then for
that bit.
So, you know, perhaps you've got a slow view.
So one thing you can do is you can put on your Nginx logs, you can log the upstream response
time.
So you've handed off to Garnicorn or to Microwiskey and Nginx will then log how long those responses
took.
And then you can say, well, actually that those responses to that particular request is taking
a long time.
And then on that request, you can go into that view and you can add a little, you know,
a little bit of instrumentation and then you can start getting metrics for what that view
is doing.
And yeah, yeah.
You know, that's really good.
He does over all of you guys.
Yeah.
I'm also a fan of Datadog.
I think those sound pretty similar.
Okay.
I think they're Boston based actually, but yeah, they do.
They call it APM application process monitoring.
And so there's quite a lot of commercial solutions.
And then Prometheus is the sort of DIY.
Nice.
Equivalent.
Okay, cool.
So that's the errors and performance.
The other side is just the website is down, right?
So maybe there's so many different layers and moving parts.
For example, like we have very little downtime with our train courses and stuff.
But one thing that did happen is we have this thing that will take the main IP address and
switch it to a failover server so we can do reboots and patches and then it'll switch it
back.
And that's all done through an API through like a get push.
And then it all just sort of goes down the chain.
Well, at one point there was a bug where that switch of the IP like disassociated it with either
server.
So the server thought it was fine.
It's like, well, things are chill, right?
Right.
So you log in and it's like, yeah, no problem.
But the site was just timing out or so.
I don't remember what happened,
but it wasn't good.
So I think there's some really nice uptime monitoring things that are free that people
should just plug in to go hit these three pages just to see.
I can talk to the site.
It talks to the database and the answer comes back.
Yeah, for sure.
I mean, I've got those configured.
I was I know we're almost out of time.
I did want to mention on deployment.
I think one thing that trips people up, especially around Django is static files, which is something
if you're doing it, you know, VPS, you know, and I think the key thing is that
your server doesn't want to run your static files like it can ways to do it.
But, you know, so both within Django, Django out of the box defaults to local settings.
And the Django has a local server.
They'll just run your static files to put that into point and deployment.
You would run collect static, which is a command that makes a single static file.
And you probably want to use something like white noise.
But there's a couple of steps there.
But something that really sort of intermediate level Django people, it really trips them up.
I have a blog post on that because I forget the commands.
There's like four things to tweak.
You just have to do every time.
It works locally.
Why doesn't it work live?
And it's like partly because people don't understand, you know, how their server is working because
they don't have to.
But, you know, that's I just want to.
Yeah.
Awesome.
Yeah.
One of the big four.
Right.
So get your code in place.
However you do that.
Tab or get pulled.
You know, whatever.
How do you get it there?
Configure your virtual environment.
You know, so in pip installed all your requirements.
Configure your database and make sure you connect to that and get your static files in place.
Database is the other one that, you know, well, you know, this might go like beginners.
They're like, well, I updated it locally and I pushed my code.
Why isn't my production database different?
Right.
And it is like I still occasionally make that mistake, you know, just but, you know, your code
is not your two separate databases.
Yeah, absolutely.
That's what you want as well.
You want to be able to write your blog post in locally and then it appear on your server.
You don't want to have to go, oh, no, now I have to paste it into the admin on my remote.
Yeah, it depends how automated you want to go.
I mean, for a simple like so my learn Django site, which is basically one admin, largely
a content site.
I mean, in terms of easy peasy, it's just Django and I've got Cloudflare in front and it's done.
It's super fast.
I get, you know, decent amount of traffic.
I don't have to think about it.
I've got I think I've got PagerDuty, one of those, you know.
Yeah.
Yeah, that's the one that tells you if it's completely unreachable, right?
Yeah, yeah.
But it's an external one that, you know, exactly to your point, because you can't always trust
yourself.
Yeah.
There's some interesting ones.
I use status cake and it's neat.
But there's some one that I heard the Dan Bader was telling me about that would sound a lot
nicer, but I'm like, but this one's already set up.
You know, it's not that important.
I get I get notifications.
If it goes down, I'm all good.
It's plumbing, right?
Like, I'm happy to live.
We have the new silver pipes.
Like, yeah, my bronze pipes.
Fine.
I'm just gonna leave it.
Well, that's Docker for Carltons, you know, so.
I use Docker loads.
All right, guys.
Yeah.
No, all the time.
All the time.
Let's just wrap it up really quick.
There's a Django newsletter.
I learned about that.
That's interesting.
You guys want to just mention that that exists?
Yeah.
So that's something I run with Jeff Triplett, who's a partner at RevSys.
He's a Python board member, very involved with Django.
So Django-news.com.
There wasn't a regular Django newsletter.
There wasn't a podcast.
So he and I have been doing that for a little over a year and has projects, articles.
I sort of wish someone else did it, so I didn't have to do it.
But we got a lot of people using it.
So that's a good resource for the community.
Yeah, fantastic.
All right.
So before I let you two out of here, final two questions really quick.
Will, I'll go with you first.
Notable PyPI package out there that you were like, oh my gosh, I ran across this the other
day.
I can't believe it.
That's a good question.
I'll go back to an old school one, which I think is Bleach, because I've been thinking
about a course on forms.
And Bleach is a Python one, not Django-specific, but you pretty much always want to have that
added.
So this validates user input to make sure there's no cross-site scripting type stuff?
Yeah.
So that's top of mind.
Not a new one, but I think along with white noise, you just got to use it.
Yeah.
Awesome.
Carlton?
Yeah.
No.
Well, the one that's just really captured my imagination
recently is Rich, which is the-
Yeah, Rich is cool.
the library for creating basically nice terminal output, nice console output, but it does
everything.
It even has like tables and all sorts of stuff.
Yeah.
It's really neat.
But like, it's got this inspect functionality where you can get an old, and you're sitting
there and you're in this shell and you're like, I want to see it.
And you print it and you deer it and you look at the dict and it's all, it's not, and then
you go inspect, and Rich formats this thing where it's like, oh yeah, I can look here and
I can see exactly what's going on.
And it's just amazing.
Rich is brilliant.
And 20,000.
That's what I love about coding, right?
I'd never heard of this before and it's clearly a very established thing.
Well, I think it's last year.
It's taken off quite, yeah, it's about a year old.
It's taken off quite steeply in its adoption.
One that I ran across really recently, just throw it out there because it's a Django semi-related
one, is Disk Cache.
Have you guys heard of that?
No.
So it's a really interesting caching plugin that will, instead of using memory for caching,
it will store it onto local disk because you usually have way more hard drive space than
you have memory in the cloud.
And it plugs into Django to like a stand in for the cache there.
Okay, fine.
Yeah.
I mean, I'm a big fan of file cache in general because like memory is expensive, right?
So memory cache is the best way and Redis and Memcache are good ways of doing that all
in memory.
But then you think, I just want to generate some HTML once and then just pipe it off the
hard disk.
Exactly.
To me, this is kind of the equivalent of SQLite versus a real database.
It's like, you don't need Redis or Memcache or something like completely set up just like
until it gets beyond whatever.
It looks pretty interesting.
You do these packages things, by the way.
Like we include packages every week in Django News and there's also like an awesome Django
repo that Jeff and I do.
You know, because the problem is you want some degree of curation, right?
Like something new.
That's right.
Like legit enough to be worth looking at.
Yeah, absolutely.
Thanks.
Yeah, that's very cool.
All right.
And then final question.
If you're going to write some Python code, what editor do you use?
VS Code.
Same for both of us.
Yeah.
Right, Carlton?
You're still in the other code?
Well, I have to.
Yes.
VS Code.
Very nice.
Use it a lot.
Also, though, I still like BBEdit.
Yeah, right on.
All right.
Keeping it old school every now and then just for a little nostalgia.
I'll tell you what, right?
So I'm using VS Code and I'm like, but I need to do some transformations or I need to,
you know, do a multi-file search and a diff here.
And VS Code's got all that stuff, but it's a bit, you know, this is built in JavaScript,
whereas BBEdit's a native Mac app and it's got a lot going.
Yeah, absolutely.
I use PyCharm.
Yeah, I'm a big fan.
Local company here in Portland, Panic, came out with, what's it called?
Nova?
I think it's Nova.
They just came out with a brand new editor.
Yeah, yeah, yeah.
I want to give that a go.
It looks pretty interesting as well, yeah.
It looks just beautiful.
Transmit.
I love Transmit.
Yeah.
I use it all the time.
All the time.
For S3 stuff.
We were talking about Nova, yeah.
Fantastic.
Cool.
All right, gentlemen.
Thank you so much for being on the show.
Thank you for having us.
Yeah, it's been great.
And thanks for all the work on Django and I'll catch up with you all soon.
All right.
Thanks for having us.
This has been another episode of Talk Python to Me.
Our guests on this episode were Will Vincent and Carlton Gibson, and it's been brought to
you by Square and Linode.
With Square, your web app can easily take payments, seamlessly accept debit and credit cards, as
well as digital wallet payments.
Get started building your own online payment form in three steps with Square's Python SDK
at talkpython.fm/Square.
Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines.
Develop, deploy, and scale your modern applications faster and easier.
Visit talkpython.fm/Linode and click the Create Free Account button to get started.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the
direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to
subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
We'll be right back.