Transcript: Docker & Flask - Nick Janetakis
Hi, welcome to another episode of Django chat podcast on the Django web framework. I'm Will
Vincent joined by Carlton Gibson. Hello, Carlton. Hello, Will. This week, we're very pleased
to have Nick Janotakis join us to talk about Flask, Docker programming. Welcome to the
show, Nick.
Hey, thanks a lot for having me and well done on the last name. Many people don't get it
right. You nailed it.
Well, I've, you know, I've taken your courses and listen to your podcast. We could just plug
that right now running in production, which has a number of things on Django actually,
but you're not limited to just Django on it. That's correct, right?
Yep. Correct. Although at this point, I think half the episodes are Django.
Yeah. Well, I think cause we'll just dive into it. So, so I think we first met because I took
your dive into Docker course after reading, well, you have a lot of Docker stuff back when I was
learning that. And I found that to be an excellent resource. And then I found, I think you actually
approached me about the podcast, right? Because you were thinking about the podcast. And then I
see that you've done, I think, more episodes than we have in like half the time. So you found a way
to be prolific. But maybe if you could just talk about the podcast, you know, why do it and kind
of what are the topics that you cover? Because it's different than this one. Yeah, so the Running
and production podcast, it just focuses on talking to someone new every week. And we just go over
their basic tech stack, like how they built their application, how they deploy it, lessons learned,
best tips. But we do get into the woods a little bit when it comes to developing the application
itself, right? Like we go over what framework they have, like what libraries to use to help
build that type of application. So hopefully, you know, there's some value out there for listeners
where, you know, it's sort of entertainment, but at the same time, you might learn a new tool or
go research something so you can try it out in your own stuff and kind of just see how it works
overall for other folks because there's a big mix of you know individuals who are just deploying
their first application maybe on heroku or something like that but on the other you know
side of the spectrum there's like people like dropbox where they're handling like you know a
billion requests per second uh and have been around for whatever like 13 years yeah i saw uh you had
the dropbox one came out recently they're they're using still is it pylons or they started with
pylons right yeah that that took me for uh you know threw me off a little bit because
yeah the project is so old not in like a bad way but you know pylons was the hotness back then so
that's kind of why they chose that one but i think it's a really strong testament to maybe the web
framework doesn't matter that that much right it's like you just build up your own core you know code
that you'd like for whatever business domain you're in and while the framework is important
you know helps you out etc but for like a really big project that's like long long-term one then
uh yeah it looks like pretty much anything we're turning web requests into web responses right and
There's only so much that needs to happen when you do that.
All the frameworks kind of very similar when you get right down to that job.
But I would say, right, I mean, Carlton as the Django fellow, a lot of what he and Marius
and the team work on is security and bug fixes, which that's you need to be Dropbox
sized to manage that yourself.
If you have a custom framework, that's, you know, one of the things that if you stay within
the rails of, say, Django, you get for free.
So I would think that's a pretty I don't did you talk about that in the with the Dropbox
folks, like how they, you know, cause every month there's a new security or bug fix or a couple
within Django. Um, so if you roll your own framework, you have to do that yourself. Yeah,
for sure. No, we didn't get too deep into like how they manage security patches and whatnot,
but that is definitely a really good point. And, you know, I'm not advocating like, Hey,
just use whatever you want to roll your own framework from scratch because there's a lot
of value in using Django or flask or whatever, just because, yeah, you don't need to think about
those problems, especially if you're at a smaller scale, just starting out. That's a great thing to
have yeah so i want to ask you a lot about flask because you have a course on flask and flask is
going through some changes with 2.0 i think is out or is about to be out um but we always like
to ask guests you know how did you get into programming you know what's how did you get to
where you are today you know as much or little detail as you like and then i'd love to ask you
a bunch of stuff about flask okay so this show is you say about an hour long so we can focus the
whole hour on that i think because but no i guess like the super tldr version is you started
programming in the very late 1990s was really into video games especially quake and uh ended up just
developing my own web application around that with a couple friends like we built a competitive
gaming ladder and uh yeah like that was my intro to programming from there you know it was like
such a big mixture of different languages back then because it was like classic asp or classic
ASP to PHP to just not using any frameworks, right? Like just a standard library. Then I did
that for a whole bunch of many years and then eventually learned about WordPress, then eventually
learned about Rails, then eventually learned about Flask. And here we are present day. So I've been
using Flask since about 2014, just to give some timeline on where we're at. Can I ask why, why
did you switch to Python and Flask? What, what did it do for you that the, you know, Rails and the
other frameworks hadn't? So it's interesting because I still do some client work now. So I am
like a freelance developer, where I kind of do still write Rails, but I also write Flask apps as
well. Even some other languages too, like Phoenix and Elixir. But yeah, I mean, I went from, so like
WordPress is basically like, you know, one of the highest levels you can get at, right? It's like
just point, click, user admin, you know, drop in some plugins, do whatever. So I was finding myself
that, well, you know, there's a lot of things that I just don't have control over. And I looked at
some of the plugin code that other developers wrote.
And it's like, not like ragging on them,
but that was not something I wanted to deal with.
So when I started to get more complicated client work,
like, you know, building a SaaS app, et cetera,
I just wanted to start writing my own code to do that.
And initially I started with Rails
and, you know, that definitely worked out very well for me.
But when I ended up transitioning over to Python
and why I specifically chose Flask,
like maybe instead of Django,
we're just moving to Python and Flask in general.
I think it's just the, you know,
it's the Zen of Python, right? The main one that really stuck out to me was, and I don't want to
misquote it, but it was around like, you know, there should only be one preferable way to do
something like the obvious way to do it. And Ruby is sort of kind of the opposite of that. Not to
say that's a bad thing, but you know, Ruby gives you a lot of sharp knives. Like you can write the
same thing eight different times and maybe one looks more beautiful than the other, but that's
all like subjective stuff to some extent. So I really liked with Python where I just felt like
I can read other people's code much, much easier. And at the end of the day, like that's a big deal
for me because then, you know, it makes it easier to jump into other people's code, see what's going
on, open PRs, understand it better, and then ultimately write better code that I can maintain
and understand like six months later. So we're biased, but I would say that the extension of
that is Django over Flask in that, you know, Django being a full-bodied framework as opposed
to a micro framework. When I look at Flask projects, I see way more diversity of structure
and and packages than i do within django um so i guess the question would be for you with client
work like how much how disparate are flask projects that you jump into like are there kind
of default best practices that you see or i mean it is a micro framework so you have much more
options and responsibility when you're you know wiring it up yeah so you're definitely right in
that front like you know with rails and django specifically you get so much out of the box so
many guidelines to work with not the guidelines in a bad way that you don't need to just think
about like oh where should you know my models go or where should my templating stuff go but yeah
with flask i'm finding it's pretty much all over the place but i feel like you can gravitate towards
things that are considered best practices i guess so but it's mainly like a learning process to get
there where it's like one more thing you need to think about basically yeah so you're so you're
the last course that you have a video course you build a very um full-bodied sas app um i guess
how did you or how have you learned you know the best practices that you then teach to others like
were there certain open source apps you saw that worked well or like what was that process for you
that you now distill you know for others right yeah it's interesting when it comes to best
practices because it's like they're not set in stone like no one just says like these are the
best practices. Therefore everyone should do this and everyone else is wrong. Like it's kind of just
like things you, I don't know, at least for me, right. It's like things you just figure out as
you go. Like you might do something wrong five times, but it's not wrong because it's like
incorrect. It's wrong because, well, you know, I'm, I'm struggling with this specific pattern,
but when I move it to this way, it's like, Ooh, that's like kind of nice. And then you grow into
the best practices over time. So when it came to creating that flask course, the build a SaaS
app of the last one, I had already built a few different SaaS apps for a couple of different
people. And I found myself going over the same patterns, the same patterns, the same patterns.
And I'm like, well, while I like doing the freelance work, like, wouldn't it be neat if I
can just like automate myself out of the job and kind of just like make a course around that sort
of. And yeah, I took all those, you know, quote unquote best practices that I've learned along
the way. And then I just started building up a course and, you know, incrementally breaking down
the final product into something you can actually build like step by step yeah i mean i think it's
patterns isn't it you find this you find yourself doing the same thing oh i've done this before oh
yeah okay if i structure it this way that works if i structure it the other way it's a bit more
fiddly and so you go with what works yeah for sure so not that you are the flask community but i have
questions about that since you know we are a django podcast and my sense is i know some of the people
in the flask community but you know where where do you go for questions where do you direct you
know people who take your course like what is there a central hub um so django has this forum
dot django project and conferences but flask is flask isn't as developed in that sense is my
my sense yeah so usually for like just general help like let's say you need to ask a question
you know if you can't find it when googling and you need to speak to a human being or want to
then it's usually irc or discord where there's i don't know a couple hundred people on the irc
channel and i think thousands in the discord channel honestly i just use the irc directly
because there's uh what is that uh you know there's like a bot that relays the chat from
discord to irc but it's pretty active there like you know you can ask a question and you know
pretty much we'll get a response within minutes most of the time unless it's like you know sunday
morning at like 6 a.m yeah there was a django has all the same things and there was actually just a
discussion around um free node and that whole thing and libra and um yeah there's lots of
different areas i mean with django all those and then there's also um i'm sure i know carl i mean
there's the django developers list you know and google groups you know to libra chat um moved all
the i don't know what went down at frino but something strange happened all of a sudden it was
ah we're up and off after 12 years in the same place and then um what do we have we've got the
forum and we've got the the mailing lists as well yeah so no but there was a discussion about you
know do we keep the irc so on so the way django is structured there's 200 or so individual members
who get voted in and they kind of decide where things go um and so that was where the discussion
happened there was a dozen or two dozen emails around hey something's come up and um you know
so it's anyways that seems more structured than flask but it's barely unstructured community at
all you know i know armin who wrote it and um david lord who sort of is the big maintain
like me maintaining but then beyond that i don't know the ecosystem at all right i think in general
though with python we are very fortunate in that most of the web programming problems are sort of
kind of solved so i find myself being able to just google most problems and honestly just find
really really good answers either through stack overflow or individual blog posts that folks wrote
and then also certain libraries are just very well documented like i mean i think that's one
the advantages of using a established thing right you've got if you google it it'll be on you know
there'll be a stack overflow thing with 500 upvotes that's the answer to your problem and it's
yes that's what I needed thank you so flask has a 2.0 update coming out which I believe
um is going to add async or could you just generally speak to some of the changes that are
coming in flask or um again because we don't know much about the flask world
right so 2.0 shipped i think i don't want to say exact days because i don't know but it was like
may 12th at 13th 2021 so it already came out at the time of recording this um yeah there's a whole
bunch of different uh quality of life features there and it like around async and just route
decorators and text like convenience things um yeah i haven't gotten super deep into the async
stuff so i don't know how much we're going to be able to talk about that one um but i know there
is async and Django as well. Like, and correct me if I'm wrong here, because really I don't know
that much about the async stuff, but don't you need every part of your stack to be async compatible
to get the benefits out of that? Like your database adapter, like ORM, et cetera, or no?
No, uh, it's a good question. So if you want like the full massive, um, I'm going to get the most
out of my single thread by handling it async throughput, you, yeah, you need everything to
be fully async compatible but what um what django's done is i think really there's two there's two
phases of it there's within whiskey where you can define a single view handler as async def
and within that and it will be wrapped in a coroutine and you know an async in the event
loop and it will be dispatched and that'll that'll work and you don't have to do anything else um you
can use that and i think that's really exciting because say you want to make i don't know two or
three parallel http requests and then combine them to put together your response you can get that kind
of um concurrency going without any big changes and then we also have the the the asgi side of it
which is the the async um standard like whiskey was the python standard for um web application
servers well asgi is the asynchronous version of that so we have asgi compatibility and when it
gets down to an ORM operation it runs it in a thread loop executor so that's you're not going
to get the full throughput there with Django just yet because we haven't got the ORM compatibility
just yet that's coming and that you know that will that will evolve but I think what's nice is
is the ability to sprinkle in a little bit of async that's that's the first bit and then over
time yeah you know if you really need high throughput then you've got to be careful what
middleware you're using are your middleware all properly async synchronous are you using the orm
if you are well you've got to really think carefully about what you're doing there because
you know um that's not asynchronous but slowly slowly i don't and yeah i mean i'm interested
with what's um flask has been next there was a that was another framework it's totally slipped
my mind began with q that was like an experiment one and that's been merged into flask or something
is that right do you know about that i don't know if it's going to be merged in but i believe the
of that one is quartz yeah and it's kind of influenced the the development of flask
yeah i remember seeing a reference to that in the new flask 2 docs but
okay i'm just not super into that but it sounds like
without needing the whole stack to be async compatible you can still get pretty good wins
Just out of the box, like, at least on the Django side of things.
Yeah, I mean, it's exciting times.
And, you know, obviously, if throughput on a single thread is your, you know, sine qua non,
then you have to go for, you know, async framework like Starlet or whatever and be fully in that world.
But I think for the vast majority of cases, we don't need that, right?
And so it's what can we add in.
And Django's got a long way to go
because it's not just about adding async compatibility.
It's about adding a Django-like API, right?
It's like where you can define some views
and, you know, it's nicely declarative
and then it just kind of works in the right way.
We're a long way from that, I think, still.
You know, but that's fine.
That's, yeah, yeah.
Yeah, but it's not an all or nothing thing, right?
Which is nice is that it's being,
because like, so ASCII was added to 3.0.
3.1 had views and then models in the ORM.
Was there another one, views, and was there a second one?
No, the view, I mean, the view, so 3.0 added ASCII support, right?
And you could run with an ASCII server, but it was kind of foundational for something.
There was no real benefit to that at all.
With 3.1 and the view layer being async compatible,
That was kind of a nice addition
in that you can define these async-def views
just within your WSGI environment
or you can run a full ASCII pipeline down to the view.
The next phase, the one that will really change everything,
I think, is getting async down to the ORM.
I think that will enable a whole different...
Because at the moment, let me give you a concrete example.
You can have an async view, say, but let's say you want the request.user.
You want to access the session.
Well, in Django, request.user comes from the database.
And so the session middleware that populates the session has to be wrapped in a thread executor.
And because of the way database connections aren't thread safe, they're not async aware,
All those database connections have to essentially be done on the main thread, on a single main thread.
So essentially, it's not concurrent whilst you're accessing the ORM.
Essentially, it's still single-threaded.
And that's a real blocker.
So as soon as we can get a proper story there at the ORM level,
then the potential to increase the throughput becomes much higher.
Let me ask you a question about that one. So I guess I'm a fan of like sprinkling in async when needed without necessarily using an async framework. But like, if I want to execute something in the background, typically, I would just reach for using Celery. And like, for example, like if I wanted to, I don't know, send an email out, right, like over SendGrid or, you know, some transactional email service.
What's interesting about Celery, at least, is like you get these benefits out of the box, like being able to do retries, you know, based on various rules that you can set up, you get some pretty good, you know, insight of, you know, how things are going. But if you execute something like that, in an async view, do you lose all of those benefits without rolling your own code on top of that?
Yeah. I mean, I don't think it's really for that kind of case. You're still going to want a queuing system for background tasks, right? Async isn't, I mean, so, okay, Starlet's got the capacity to spin off a background task and that's great. And it's kind of cool, but you don't have all of these extra features that the queuing system, the dedicated queuing systems have built up over years and years and years and years and years.
kind of what what like what happens if the email fails to send you know you can't you know where's
the where's the retry there is no retry so you know someone might build and there are you know
examples um in the channels ecosystem where they built um examples of a queuing system built on
channels which is built on asgi but it's recreating things which have been built in queuing systems
before it's not it's not fundamentally changing the the the nature of the game i think the
advantages come in um making requests out to third parties which is something that we do a lot now
right so if you can if you can do that um concurrently you can reduce times um it comes
with things like proxying servers it comes with um and yeah handling you know handling more in
in theory handling more requests on a single threaded work on a single worker um but
it's not going to eliminate the need for say queuing systems i would say it's not going to
eliminate you know a messaging bus or you know all these other bits and pieces that people spin up
when they when they start to scale i've asked carlton that same question uh because it's similar
but different like it's sort of the same but they're going to be separate probably you know
Eventually, when it is all built out, you'll still need both, depending on what you need.
Yeah, I mean, I think the advantages right now are what making requests out to third party services and then things like service and events or WebSocket communication that you can do.
That's, you know, that's where it starts to make more sense.
You know, when you don't want to hold open a thread for a connection, if you've got, you know, you start scaling up WebSocket connections, you can't hold open a thread for every single one.
yeah that component of async excites me a lot because i don't know if you've looked into
using hotwire turbo yet or no a little bit a little bit yeah but go on tell us about what
you're excited about with hotwire because that's i mean that's a hot topic right i mean that we've
been we've talked a lot on the show about htmx which is in the same ballpark um yeah we had um
carson on um the episode before this oh nice yeah i'll have to check that one out but yeah i mean
hotwire turbo i guess it's similar in some regards where it's just the ability to create
create something that feels similar to a single page application without having to actually
go all in and create like an API backend and then create a separate application on the front end
with, you know, React or whatever you want to do. So, you know, Hotwire Turbo just makes certain
patterns, I guess, I don't want to say easy to create, but, you know, easier to create than the
alternative where, you know, you can do partial page updates, but also you can send, you know,
incremental updates over a WebSocket connection. Like if you wanted to add an item to a list or
something like that if you had to like you know a chat example or a to-do item you might want to
add one item to the list or remove one item from the list so yeah but for that to work you would
need um you know web socket connection so async would be very nice there instead of having to use
you know like a third-party web socket service or run an extra server on your own yeah i mean
no that's exactly the kind of use cases right there sort of is there is there much point in
just replacing the the traditional um request response cycle no not really like that that works
perfectly well for you know the vast majority of cases but then there there are these exciting
things like you know the live um you talked to you used elixir you said so you've looked at the
phoenix live where they're you know using a web socket to to um update the the html in the page
there and then and we to have that kind of same same ability in python and in flask and in django
that's that's exciting yeah so i'm not like resident expert on this one but i think there
is a hotwire turbo library cooking right now for django like someone in the community created that
yeah i believe so yeah well there's also um there's a django htmx um project that adam
johnson who's on the technical board has created so those things are are coming in and yeah it's
pretty exciting um to not have to write javascript yourself i think there's also a not that much yeah
yeah yeah so that so there's also the package called django unicorn which is um it's a magical
full stack framework for django so it uses um you know i haven't actually dug into the
implementation but it uses um web sockets to then again do this live html updating yeah it's very
cool very cool stuff we'll put a link to that in the show notes but anyway these are the things i
think is exciting about async like you know and i don't know um switching gears slightly um docker
so you have a course on docker docker something we talk about on this podcast um maybe why create
a course on docker you know clearly i probably i guess your own uh journey into learning it was not
as straight as it could be and then you wanted to uh impart something better for people coming
after you yeah so when it came to using docker i started really early on it was like 2014 i want
to say like docker has already been it was one i would by then i think was like 1.4 is when i
started but we're talking like ancient times in the tech universe and um back then yeah the
ecosystem was so much different like even things like you know docker desktop was many many years
from being created docker toolbox didn't even exist like if you were on windows or something
like that and you wanted to run docker it was like you had to like actually roll your own vm
like a Linux VM and install Docker directly on that. But yeah, you know how it is with tech
projects, like documentation might not be the best initially, but then slowly gets better over time.
Like right now, Docker, their docs and stuff is in a great position. But for me, when it came to
using Docker, yeah, it was just like, I had trouble or not, you know, basically pain points and
creating my own local development environment, specifically, I think it was with Rails at the
time where it was like, you have to install Ruby and all these other things. And, you know,
there was a lot of moving parts and, you know, it's pretty comparable with Python as well.
I mean, you do get Python installed by default, unlike most distros of Linux and macOS and stuff,
but you still need to manage like a virtual environment. And then, you know, maybe if
you're using something like Postgres, you're pulling in the PG package, which is going to
have like a C dependency that you need to install, unless you use like that other package that's like
not meant for production or whatever. But, you know, getting that C dependency installed,
if you're on Windows or macOS and Linux, that's a way different experience. And, you know, besides
just that one pg library there's other packages as well that need c dependencies and it's not even
just your application too right because it's like well okay now i need to run postgres okay now i
need to run redis okay now i'm running g unicorn celery redis and postgres and maybe something else
maybe like an elastic search or whatever you know your app happens to need and before you know it
you're in this like like hell of just like managing how do i run all the stuff how do i get it all
installed and then it's like cool i finally developed my app you know three months mvp is
ready to go let me ship it to production and then it's like well okay i was running windows or mac
os not linux like how the heck do i do all this on linux and now it's like you need to become an
expert there and repeat all those steps there and it's like you finally get it out and shipped maybe
you open source the product and now uh you have other code contributors trying to come into the
code base and now suddenly you need documentation that's really good for everyone and um before you
know it like your whole life is taken over by just writing documentation that's going to get out of
to get people on board but with docker now it's just like okay cool you just run docker compose
up dash dash build wait five or ten minutes and like the whole thing is up and running so for me
like i don't know like i'm not just saying like oh use docker it's cool i have a course on it go
buy it like i use these things for many many many months or even like a year plus uh because it
really helped me out like i really fundamentally believe like docker or just containers in general
is such a big like it's one of those technology shifts that it's like i'm very thankful to be a
of the time where i can actually use that stuff because i've used the alternatives and it just
it wasn't good so carlton and i are carlton still likes to do it his way and he uses docker when he
has to but um he has not maybe experienced all those problems as much as you and i have i don't
know i've i've i've cried plenty of blood um but what would i say i said you know i didn't i don't
mean to put you on the spot i mean i think you know we always end up turning it back into a
dot-com say i think that containers have a great use case um and it's exactly that packaging up
your your dependencies in one thing and you know putting them on there but if you can keep a grip
on your dependencies and be able to manage them and know exactly what they are it does it is
you know if you're deploying a python app to a known environment you don't need to
add that extra layer necessarily all the time i think that's what that's that would be my kind
of take is that yeah okay brilliant you want me to run something that uses java that's going in a
docker container no problem because i'm not installing all that and i'm not putting you
know getting into the hell there but you want me to stick my my my little my little django amp
in a container why i can just you know i can just run it locally and but i don't want to turn this
into a docker conversation i hate docker conversations i mean i hate i hate when i
hate it when you swing it around to me and go go why don't you like docker i'm like oh god do we
have to do that no no i i do that because i think it's important to not just without thinking jump
on the train and say docker all the way and that there are trade-offs for sure yeah it's i mean if
you don't need it it's a massive jump up in your complexity that's the thing it's mad like so when
When you have complexity, yes, it can be simpler, but you then trade off getting the packages
installed for building containers and managing all of that nonsense. It's not time-free.
I'll say one immediate for sure trade-off is, right now at least at the time
of recording this podcast, it is not the fastest thing in the world to build a new version of your
Docker image when you just change one dependency. So like if you weren't using Docker and your
requirements, a text file has, you know, 20 things in it. And maybe like, you know what,
you know, maybe I need to install this one Django library or flask library, whatever
with Docker. It's like, you need to rebuild your image and it's going to invalidate the
cache layer on your dependencies. And suddenly all 20 of those dependencies are going to be
reinstalled instead of one so like realistically the turnaround time there is that maybe it takes
like five or six minutes to build all of that where if it were local outside of docker maybe
30 seconds so and those things and you can end up spending you know basically all week optimizing
your docker build process and it's like at that point it's like hang on i wasn't this meant to be
much simpler well um i do want to add we have in the notes you have a docker django example repo
Poe, where your take on how to structure all this, which I think is very helpful to folks.
But the thing I really want to talk about is our last major topic is deployment, which
Docker ties into that.
But you have thoughts.
Carlton's been working on button.dev, which you can sign up for, which is a simpler Django
deployment story.
So maybe, Nick, deployment, with or without Docker, how do you like doing deployment these
days?
And let's have a discussion about, you know, Flask.
How do you like to deploy it?
Because deployment is always pretty individual, right?
So I'm a really big advocate of keeping it.
it's funny that I say this now, like keeping things simple, you know, until they don't need
to be simple. So for me, I'm a big fan of just using Docker Compose as much as I can. So in dev,
in CI, and in prod, I'm totally cool just doing a Docker Compose app, you know, dash D or whatever,
and get everything up and running on one server, like one VPS, doesn't matter which provider you
happen to use. Because I really don't mind the idea of having like three seconds of downtime,
if I'm deploying my application like three times a week. And even, I mean, I've got some clients
I can't get into like super details, but like, you know, these are clients making like 80,
$90,000 a month running it on a single $40 a month VPS. And yes, they have like five seconds
of downtime when they deploy their application. It's not the biggest deal in the world, at least
for the types of applications they're building, right? It's not like a medical device. No,
one's going to die. If someone gets like a five or two, you know, like back in a found for engine
XRs, but yeah. But on top of that though, you know, eventually maybe if your application grows
to a certain size, or maybe you have an organization where, you know, you don't mind throwing money at
the problem and you just have some hard requirements because maybe you're, you're now managing like
bigger clients and like downtime's unacceptable. Yeah. Maybe then you can transition into something
like a Kubernetes or a container orchestration tool that'll just help you minimize downtime.
I'm still on the fence of Kubernetes where it's like, it's almost a meme at this point where the
complexity of that is like ridiculously high. But if you keep it pretty minimal, it's not that bad
of a solution, in my opinion, to get something up and running where you can just load balance
an application, you know, get three or four copies of those running, do a rolling restart,
zero downtime, you know, 200 lines of YAML and you're done. But yeah, there's a lot of ramp up
time to get that to that point. So that's basically how I progress most of my own stuff. And, you know,
if I were to develop my own SaaS app and actually ship it, it's probably just going to be on one
vps maybe i'll use a managed uh postgres server so i don't need to you know deal with that also
makes it easier to keep this state off my server which is a good idea in general in case i just
want to maybe do a zero downtime server upgrade like upgrading from ubuntu 20 lts to whatever
the next one's going to be in a couple of years i don't have to worry about like migrating my
database data from a different server i can just you know flip it over at the dns level stuff like
that yeah no yeah hosted db all day long yep i can't agree more with what you've just said like
is perfect like keeping it simple keeping simple until you need more that was the phrase you used
and it's exactly right it's people not for one i think i think the sort of the the blog sphere the
tech blog sphere kind of gaslights us a little bit it's like no you've got to have this you've
got to have that and you start to doubt your own you know sanity oh is it okay if i do this simple
thing yeah it really is okay if you do that simple thing until it's not and okay you know that moment
where you restart your application server if you if you if you know if you're not switching it to
another running one there will be you know potential of drop requests but meh you know
it probably doesn't matter yeah and if you want to get really really fancy pants about that
if you have you ever heard of uh open resty before oh yeah that's a um um a framework built
into nginx right yeah so i don't want to get too deep into it because i'm not a professional on it
But, you know, think of it as like Nginx Deluxe, like it's an open source version of Nginx that has certain extensions enabled, one of them being Lua extensions.
And once you have Lua extensions available, you can start doing some really, really interesting things, such as like, imagine you have one instance of your app running and no load balancer.
So, you know, you restart your app and it's going to be five seconds of downtime, you know, however long it takes your application to boot up.
But if you're using OpenResty with Lua, you can actually script a solution to where instead
of having those requests be served as like a 502 backend because it's down, you can have
Nginx queue those requests up in order.
And then the user, like endpoint of view user, is just going to have like a busy mouse cursor
on the site.
It's going to look like the page is hanging, but they're not going to get that 502 backend
not found.
And then when your application comes back up, it is going to release those items from
the queue and just serve them as if it's basically zero downtime.
and i think that is such like that's such a fantastic solution for the one server deploy
without introducing like massive like kubernetes or load balance or auto scaling groups or crazy
stuff like that yeah no that's that's a good idea because one thing i like to do is just use a um
an application load balancer in front because i think it's good it's like um like a post
a managed postgres right it's it's i think it's money well spent because you can just sort of
spin up the new one and just change it at the load balancer level and it's kind of nice but
exactly yeah you could you can configure nginx to hold that hold those requests so the load
balancer approach is definitely awesome but um i don't know if you've experienced this firsthand
but it also becomes a little bit more difficult to reason about your app if you are under uh the
universe to where v1 of your app and v2 of your app can be running at the same time like suddenly
you need to be very careful with your database migrations to make sure that they're compatible
with both versions of your app running like there's a lot of can of worms that you need to
aware of i'm sure you know yeah no i mean that migrations is one of the great issues like so
people always one of the great um advantages of uh you know containerization is that you can roll
back you just deploy the last image but you can't roll back a migration right so it's like you know
because once you've migrated you if you roll back to the other version it hasn't got the migration
so you can't revert the migration it's like no i've there's only once you start changing your
database structure is only forwards and that's just a difficult topic i think i think that's
oh yeah you know suddenly it's like you want to rename a column and it's like 17 steps to do it
with no downtime yeah yeah yeah no i mean you know it's the reason why people make a living
specializing in that kind of more difficult thing so nick you're so your deployment story that
sounds like most consultants i know and that you've found a deployment story that works for
you and then you can apply it through a lot of projects um one of the cool things so carlton
has this button.dev that i mentioned because you know for someone who wants the benefit of that
without all the years of experience and client work it takes to get there yeah where he's kind
of rolling this all up into something that you know someone who's new to django or flask who wants
the benefit of that and just wants it to work can kind of have it you know a layer on top of aws to
start right yeah so i mean it's um yeah so btn button btn.dev is the idea is exactly that it's
Like, look, you want a simple story, here it is,
you've got it, and it's, you don't have to,
the trouble is, you're going,
fire up the AWS console, right,
and you're gonna get an anxiety attack
because the 2,000 services that appear.
For, you know, a mortal getting started,
that's not an approachable way.
And I know, you know, there are other options
like DigitalOcean and, you know, Roku and things like that,
But, you know, deployment comes up week after week on this show.
And it's always like, you know, I've been working on this 10 years and I finally got it mastered.
Or, you know, finally got something that works for me.
It's like that's too far from where the beginner is.
Or for me, you know, I just want to get my app online.
I just want to get my app online.
Deployment's like the great thing that it seems harder than it should be.
And there's just a total gap from a completely hosted, maybe a Heroku thing to AWS expert.
But you've made that journey, Nick, right?
So I'm just curious, what was that like for you?
How did you have to do that?
Or what was the process that forces someone to spend all these years learning about the
ins and outs of deployment?
Yeah, I guess it just came out of necessity.
So it's like, I have this application on my dev box.
Now I need it to be running on the interwebs, like on a domain name that I can access that
everyone else can also like, how do I get there? And yeah, it was a very long journey, probably
like seven years, I want to say, but it wasn't like seven years of like 40 hours a week,
just focused on like learning stuff. It was basically just like, okay, cool. My app is
ready. Let me deploy. Okay. What needs to be done there? Okay. So what cloud hosting provider do I
use? DigitalOcean, Linode, AWS, like there's a hundred different ones that you can choose from.
And now it's like, okay, cool. I have the host or I have the hosting provider. Now,
like what operating system should I use? Should it be Ubuntu, Debian, something else? And then
that's just like, that's like, that's like a three-day rabbit hole now, you know, where you're
reading like 15 different blog posts, like 20 YouTube videos trying to like, but it's tricky
because you're not an expert in the thing yet. So it's like, you have to cross-reference this stuff
and just see like the common ground. Like, okay, this thing was repeated like seven times. This is
probably a good choice. Okay. Debian, let's roll with that or Ubuntu LTS, whatever. Great. And it's
like yeah then you just need to learn um more about just how linux works right it's like just
understand at least that you know the very basics like how do i lock down a server with ssh like
what about uh port forwarding and you know firewall rules and stuff like that should i use ip tables
or something else like and then you know cloud hosting providers have their own uh version of
that on top yeah so it's just like rabbit hole after rabbit hole and honestly it's almost never
ending uh depending on how deep you want to go but like long story short yeah i went through that
process and you know once you go through the process and you set up your first server uh then
it's like well how can i automate it next time okay cool i'm gonna write my own documentation
and here's all the steps to do it and you're like wait no no no let me just make it into a script
because that's way better than documentation because now the script actually works and then
it's like well but there's so many like edge cases and like if conditions and you know blah blah blah
blah maybe i should look into something else oh there's configuration management that's actually
a thing. And then it's like you learn about using Chef or Puppet or Ansible or Salt or 10 other
ones. And then that's another rabbit hole of years, by the way. Ultimately, I ended up choosing
Ansible, by the way. And yeah, I've written like 10,000 lines of Ansible YAML over the years.
I don't want to go super deep into Ansible, but configuration management, it's a way for you to
be able to run, let's say, one command, and then suddenly your whole server is set up ready to go
based on, you know, YAML that you've written also, by the way, Ansible is written in Python.
So that's kind of cool too. Yeah. And then after that, it's like, eventually you get to the point
where now you have the server provisioned. It's like, what's the next step? Like maybe I want to
run this on AWS, but it's like, I need to set up like IAM policies and security groups and EC2
instances and RDS. It's like, well, maybe is there a way to automate that? And then you're like,
well, there's a thing called Terraform. Now I can do like infrastructure as code, like Ansible,
but for my infrastructure. And then like, before you know it, yeah, you, you get all this code
written and you're like five years into it. And finally it's like, I can set up a single server
now in an automated way. Cool. Like it, yeah, it took a while to get there, but it was a,
it was a journey worth going down, I think, because one, I kind of like that stuff. Like
the upside, I think like most of my contracting work now is actually just more focused on that.
so i actually found to be i sort of like that but i understand there's so many devs i think i'm a
minority and most of them are just like man i have this thing in my dev box just get it up on the
internet i don't care how it gets there so i appreciate services like that's more that's more
me so like i wish we had the video because carlton was nodding to everything you just said there
because you can you two can relate in a way that i can't fully like i have done it a little bit but
i have not done the years that the two of you have on it i'm just like just someone else solve it for
me like i i've got enough to deal with at the app level i remember spinning up my first vps and it
was oh yeah i've got a vps and oh god what's the difference between all these you know between the
different linux distributions and i had no idea what the difference was between them and when you
get hacked right mine was hacked right away like within you know 20 minutes on linode i think okay
you know i got a thing being like your thing is spamming something it's insecure and i was like
why would you let me set something up that is you know unsafe so it's a very scary thing yeah and
very frustrating thing less scary more just like how does anyone do this but it's literally days
of reading tutorials on you know yeah stuff and so i have no desire to go to where the two of you
have gone and then there's like a whole nother thing too it's like you have everything up and
running now there's like all this like post deploy steps like well you know how should i keep my
database backed up like should it be every three hours every six hours every two days like yeah
there's a lot of things to keep how many how many nines do you want to have for your uptime
well so maybe i don't know is that a future course from you nick about you know all those
steps and oh yeah everything else or is that yeah that's that's the current course that is cooking
now basically just like deploying to production but it's going to be focused on you know the
individual or small teams who you know they don't want like a thousand node kubernetes cluster it's
like let's just get this up and running on one server using docker compose but let's not skimp
out on making this like production ready right so we're still going to have best practices around
like file uploads will go through to s3 or you know some compatible object storage can you be
using environment variables like it'll make it easy to transition to using something like
kubernetes if you wanted to in the future that sounds super it's hard to call something you know
truly production ready or professional because that's like decades of a career like i i have
that a little bit i have a jenga for professionals book which is a big step up for my other two
but some some of the feedback i get is well it doesn't go you know into all these things and
it's like well that's a thousands and thousands of page book that nobody could write and maintain
but um there's that so there's that you know that slope and one of the things we i try to do and i
think we do in this podcast to try to give a sense of like what is the context of production ready
and it's like yeah it requires there's a reason why dropbox has so many engineers right it's
mainly ops um same with any other big company because it's you know like we could all build
an instagram clone over a weekend but at their scale then you need a lot of other things um it's
not the yeah so so the point of you know we often say django is really more of a front end thing
actually in terms of you know the back end is this deep endless abyss of configuration and uptime
it's funny though because yeah it's like finishing developing your application it's almost like
that's where the journey begins like you know and you're not done yet like now it just starts
well and you know for me personally like i am of the opinion like that's enough for me to focus on
so i'm happy to pay button.dev or heroku or whatever and if i get to the point where my bill
is more than a devops engineer like great that's a problem i want to have i'll pay whatever but
that's a long long way off like i think people also think that they need to jump to that until
they're yeah as you said you can run a million dollar business on a 40 box a lot of people do
actually yeah um i think that's the that's the sort of thing is that the temptation is to over
engineer to begin with like you know you build something that you could deploy a hundred times
the application that you've actually got on on what you've provisioned and that's all just wasted
totally yeah it's like you got a ui problem instead you increase the uptime you know 0.001
because that's doable and feels better that's sort of an engineer's curse a little bit
definitely yeah
It's super easy to get lost in the woods there.
Carlton, do you have any other questions for Nick?
We're coming up on time.
Well, I mean, I, you know, we did, I had imagined we were going to talk about Flask a little
bit more than we did, but, um, so I don't know if it would work to cut back there at
all, um, or if we've got anything to discuss.
Um, well, Nick, what can we do to bring you over to Django?
You know, how do we, how do we convert you?
Like what, when you look, when you, from where you sit, when you look at the two ecosystems,
what kind of keeps you in flask as opposed to you know something with more guardrails because a lot
of people are in that boat too so i'm just sort of you know curious the django community what does
a flask developer think of django so i don't know enough about django to like i've never built like
a quote-unquote production really like large-scale django app so i can't give a perfect like
comparison but for me like when i got started doing all this web development stuff in the early
days of PHP, it was really cool just to have PHP standard library. I literally didn't install a
single dependency ever. So I ended up rolling my own stuff. And, you know, you think about that
and you look back and you're like, that's horrible, though. Like, why would you put in all that effort
when other people have solved the problem way better than you will ever be able to solve it?
And it's been vetted by like, you know, a million other people. Of course, there's nothing better
than that. But in a funny way, in the back of my mind, it's always like, well, I created this mess,
but it's my mess. Like I know exactly where to go when things go wrong. Like I still have like
these like 11 year old PHP apps that for other like ancient clients where, you know, it's everything
bad, right? It's that one, uh, PHP file. That's like 6,500 lines and there's like PHP and there's
like SQL statements in line. They're probably not even like secure, but it still somehow works and
no one ever got hacked. But yeah, I don't know. So flask is kind of neat for me because it's like,
it sort of gives me that feeling of like, I can actually do things. I don't want to say like my
way or the highway, but like I can do things a certain way and maybe it's not the best way ever,
but it's like when I need to go back there in two years and maintain something, it's like,
I know exactly where I'm going now. That's not a super fair comparison because you can just learn
the Django way of doing things. And now you don't even need to worry about making decisions. You
can actually just start putting your code, your business logic, where Django tells you to put it
and do all this stuff. And you know, there's definitely value in that. Well, I see a little
head shake in there because it is a video call but don't you want to expand on that yeah yeah no i
was i was just gonna say i agree with that um even within django so we have on the django forum
there's a topic about where to put the logic in django so even with django's guardrails there's
a couple places you could put it um and i think there's general agreement but it it depends so
you know so for example many people would put it in the view um you can also put it in the model
there's model managers you definitely don't want to put it in the templates um but there's a lot
of subjectivity around optimizing that depending on how you cache it i think generally and carlton
you're the you're the expert i would say generally logic starts in the view and if you can you want
to move it to the models um but it sort of depends but that's the general pattern i i find myself
getting into yeah what do you say mr jango fellow oh i what's the canonical answer the canonical
answer for me is that the um the the view is for turning http requests into http responses so if
the logic is to do with that it belongs in the view um but if it's like i don't know you know
sorting sorting you know something alphabetically yeah then you want to probably tuck that in your
model and have either a model method or a manager method to you know encapsulate it so and and like
if you've got a manager method that's responsible for creating an instance and some dependent
objects and all the rest and what's that going to take in it that's going to take validated data
that came through the form layer and so you know they you know logic about data validation that's
going to live in the formula you know so there are for me there are kind of places but you know
then within it it's like well do it do i use a model method or do a manager method or do i
you know yes there's room for you know lots of different approaches there i like what you were
saying nick about um building it yourself it's like driving a corvette right it you can it's a
manual manual shift you can feel like you have more control or more fun or more freedom like
the thing that came to mind was um you know the the starlet and fast api that people are
you know getting into now um for that same sort of reason it's small and you know i think i can
bolt together my little thing. I don't know if you've used those frameworks as well.
I haven't, but I mean, on the flip side, right, there's still a ridiculous amount of value in
having very strong opinions made for you because that just makes it way easier for people to
operate almost as like, uh, people instead of an individual person. Right. So if like,
once you solve the problem a certain way with Django, it's very well documented. Like everyone
can benefit from that standard or opinion that was created. It just makes it a lot easier to
one, learn the framework, even though there's like maybe more stuff to learn and, you know,
it's not just a single file or whatever, but it's much easier to keep everyone basically
on the same page, onboard new people into the framework or, you know, especially like
a big application, right?
If you are a company and you're expanding and now you have a couple of employees, getting
them up to speed on a Django code base is probably going to be a lot easier than a random
flask one because yeah, it's just going to look more like the docs, I guess, versus an
individual like whoever the cto decided to make the flask up i think as well in a django app there's
a tendency for it to go wrong in the same ways as well so they yeah there'll be too much logic in
the in the view and it'll be like you know what are you doing this in the view for that's fine
though because you can move this bit that can go into the form layer and that bit there can go in
and it's kind of like predictable that that's where the problem will yeah yeah well you can
also i uh so carlton has a talk from uh most recent django con and there's a whole i have a
blog post and a project on you can have a single file django um project so um django can do what
flask can do um we have a whole thing on that um but i'll i'll put those in the in the the show
notes right um i don't think it's a competition though like i was so pleased to see the announcement
that the flask 2 flask 2 was coming and that it was going to have the async and all the rest
because I didn't know that that was on the cards
and it was like, yes, thank you.
That's brilliant because it's really important
that Flask is able to move forward
and, you know, have the new shiny features.
I think that's, you know, it's vital for the,
not vital, you know, frameworks come and frameworks go,
but for something with as much weight in the community
as Flask has, if it hadn't been able to move forward,
it would have been a really sad loss, I think.
I'm a big fan of, I don't want to say competition, but I feel like it brings the
best to everyone when you have multiple choices where Flask is good, Django is good, Rails
is good. It's not all or nothing. There only could be one winner. There's three winners
there.
The frameworks will learn from each other. It's like, ah, that's interesting
what so-and-so is doing over there. Let's see what we can do over here that's similar.
In the front-end world, we've talked today about Turbo and HTMX and various approaches
to Live.
That's quite an exciting area, and there's all these different things experimenting with
different options.
The result of it being five years' time, there'll be mature and established stories for all
the frameworks there.
Right.
Then I can sit back and create my server-rendered applications with sprinkles of JavaScript
here and there, and then I'm a very happy person.
Yeah, I think, I think it's getting there. Um, yeah, I mean, Carlton, so as Django as a micro
framework, um, was Carlton's talk and it's, I think 10 lines of code. Um, so it's not quite
as quick as Flass Hello World, but you can get kind of close. It's really a question of where
you put things. Um, but we had, I mean, maybe as a concluding thought, we had, um, DHH of Rails
fame on, and, you know, we, a lot of the discussion was why is Django and Rails, and I guess Laravel,
Why are there so few batteries included frameworks?
And he made the analogy of like, you know, those are trucks you build out of Legos, whereas
Flask and others are a bag of Legos you dump on the floor.
So it sort of depends on how you want to spend your time.
But I have to think that part of it, too, is it's these full stack frameworks or these
batteries included, they're a little bit all or nothing.
You can add Flask to a Rails app if you want to.
So in that way, it's easier to kind of add things on, especially in a larger company
we have lots of teams and um it's perceived to be easier to add on a micro framework as opposed to
django though you can also do it with django but i'm curious i guess if you see this i see this a
lot of times it's oh yeah we use flask because it's like to add sprinkle things on to something
that may not even be in python to begin with but it kind of works quickly for a specific case so
do you mean like spinning up a separate microservice that maybe a couple hundred lines or
whatever to do some functionality yeah yeah if you have it and it could be you know whatever
other framework or programming language but or even just in a larger thing um it's easier for
a team to just spin that up and you know kind of glue it on as opposed to you know if it's if
you're a solo developer you'd have it all within one roof it's like once you go off the guardrails
you're kind of fully off right or at least i anecdotally i see that and so that sort of makes
sense to me about part of why flask has so much popularity is it's used in that way in a way that
django is not people are less likely to add in django later on to something so you're saying
like in the django ecosystem you're seeing more people just build like single monolithic
applications where everything is in the single django app like not necessarily django apps like
it can separate your application at the application level but i mean like services yeah i mean just
django is generally not used as a micro framework in the same way that that flask is though it could
be but part of that is the documentation part of that is just how it's being used how it's presented
nice i feel like that's not a great that doesn't sound so great when i say it again i get that
feeling you know somebody i don't know a data analyst say is um you know they've got their
pet they've got their pandas data and they want to somehow just get it online and you know a bit
of googling and it's like oh yeah the flask example makes really like makes sense quickly
so i can just knock it up in flask if it's only a couple of end points it's easily done it's there
bam and then they're a flask user and then i carry on and this is nice and that's fine that's super
yeah i see that type of pattern too um well nick any concluding things you want to mention or
our plug as we round out the show? Uh, let's see plug wise. So I do write, um, a weekly blog post
at nickgenotakis.com. I also have a YouTube channel there as well, where most of those
blog posts are now have been videos for like the last year. But yeah, besides that, there's like a
list of courses on that page. Uh, there's always the running and production.com podcast where half
the episodes are Django. So you may want to check that one out. And, uh, yeah, and we, we put them,
we we put i think hopefully all of them in the django news newsletter um oh yeah there's a podcast
section which is basically this one and yours and a couple times there's some other ones but those
are kind of the two main ones yeah i really appreciate that by the way because i always
see like an uptick in traffic when uh that newsletter hits so thank you yeah no yeah well
and if anyone i doubt it but if anyone listening doesn't know there is a django-news newsletter
that's weekly that i do with jeff triplett and um trying to promote the small but valuable
community of Django and people pumping out good content because it can be hard to find
on your own so so this isn't so much a plug but it's more of a request so Carlton if you ever
want to come on that running in production show to talk about button.dev like how you built it
and deploy it uh we'd love to have you on okay yeah um so it's DjangoCon coming up next this
will be with this show will probably come out after that and then um but the next the next
phase after that is buttons launch um time so yeah marketing really you should tell i mean
marketing i don't yeah shiver i'll just come on and talk talk for you i'll say all the positive
things carlton you can underplay it yeah yeah okay i'll underplay it that's fine i yeah i mean
i'm still in um building phase i just gotta get through jango con and then that's the next that's
the next thing so i'd love to come on and talk about it nick thank you it's one last quick thing
Um, so doing the podcast, Nick, what have been your takeaways, right?
Cause sometimes people say, yeah, podcasts would be fun to do.
Like how, how much work is it?
And what have you gotten out of doing it?
Cause you've, you've done it for a while now.
Yeah.
I started in October, 2000 or October, 2019.
So I'm at like episode 85 ish.
And, uh, yeah, it is a lot of work to be honest.
So I don't outsource any of the process because you end up in like a chicken egg type of scenario
you know, where the episodes aren't sponsored because the audience isn't big enough. So,
you know, you kind of have to put the burden on yourself to do all of the work. So it's like
finding the guests that you want to have on, then recording the show, scheduling the show,
et cetera. And then it's like editing the show, creating show notes and stuff like that. So I'm
probably putting in like five or six hours a week on this one, like end to end to produce one
episode, assuming I don't have to try too hard to find a guest. But, you know, it's not just
like a monetary gain for me or trying to get a monetary gain out of it. I kind of like the
process of just, uh, the interview part. So if I can outsource everything else and just do like
show up for an hour and then be done, that'd be amazing. Uh, hopefully one day I'll get to that
point, um, through sponsors, but yeah, if you are thinking about starting a podcast, don't like be
very aware of how much time you're going to be spending, especially if you don't have prior
knowledge of like video editing and, you know, or audio editing. And so I had a big background
of that already because I did like, you know, I literally recorded like 500 videos for my courses
before that so yeah there could be a ramp up time like i want to talk about rabbit holes like the
audio stuff is uh also never ending so before our first episode we must have spent like you know
two months trying to get it all right you know just being able to record a you know a simple
chat but the takeaway overall of the show like i'm really happy uh with it because i like talking
to someone new every week and you get a really good perspective of what people are actually doing
not just talking about because yeah if you're just on hacker news all the time it's always like
kubernetes this kubernetes that like make this thing do this and yeah but really at the end of
the day like there's so many people out there just using heroku using maybe a service like
button.dev when it's available we're just throwing up one server and it actually works
we're at small scale and you know medium scale as well exactly right that's this podcast came
out of django con and the hallway conversations and thinking how how can we keep that going and
share that with other people um and so that's why it's a chat about django um great so we have
links to everything in the show notes. Do check out Nick's podcast, Nick's site, Nick's courses.
Thank you for coming on, Nick. Yeah, thanks a lot for having me. All right, everyone,
we're at DjangoChat.com, ChatDjango on Twitter, and we'll see you all next time. Bye-bye.