Transcript: Docker & Flask - Nick Janetakis

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

This week we're very pleased to have Nick Janatakis join us to talk about Flask, Docker programming.

Um welcome to the show, Nick.

And well done on the last name.

Many people don't get it right.

You you nailed it.

Um, we could just plug that right now, running in production, which has a number of things on um Django, actually, but you're not limited to just Django on it.

That's correct, right?

Although at this point, I think half the episodes are Django.

Well, I think because well, so we'll just dive into it.

So um, so I think we first met because I took your dive into Docker course um after reading.

Well, you have a lot of Docker stuff um 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 d are you were thinking about the podcast, and 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.

Um, but maybe if you could just talk about the podcast, you know, why, why, why do it and kind of what are the topics that you cover?

Because it's different than this one.

And we just go over their basic tech stack, like how they built their application, how they deploy it, lessons learned, best tips.

And 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 they 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.

There's they're using still, is it Pylons?

Or they started with Pylons, right?

But I 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 like for whatever business dooming you're in.

And while the framework is important, you know, helps you out, et cetera, but for like a really big project that's like long long-term one, then uh yeah, it looks like pretty much anything you can do.

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.

That's you know, one of the things that if you stay within the rails of, say, Django, you get for free.

Um so I would think that's a pretty I don't know, did you talk about that in the with the Dropbox folks?

Like how they, you know, because 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.

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 or 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 uh a great thing to have.

Um, but we always like to ask guests, you know, how did you get into programming?

You know, what's how'd you how did you get to where you are today?

You know, as as much or little detail as you like, and then I'd love to ask you a bunch of stuff about Flask.

So we can focus the whole hour on that, I think.

Because but no, I guess like the super TLDR version is 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 build a competitive gaming ladder, and uh yeah, like that was my intro to programming.

From there, you know, uh 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 uh I did that for a whole bunch of of many years, and then uh eventually learned about WordPress, then eventually learned about Rails, then eventually learned about Flask, and uh here we are present day.

So I've been using Flask since about 2014, just to give some timeline on where we're at.

What what did it do for you that the you know Rails and the other frameworks hadn't?

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 uh languages too, like Phoenix and Elixir.

But yeah, I mean I from 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 not like ragging on them, but that was like not something I wanted to deal with.

So when I started to get more complicated client work, like you know, building a SAS app, et cetera, uh, I just wanted to start writing my own code to do that.

And uh 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, uh, and why I specifically chose Flask, like maybe instead of Django or 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 uh Ruby is sorta 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, that but that's all like subtractive 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 easier to jump into other people's code, see what's going on, open PRs, understand it better, and then uh ultimately write better code that I can maintain and understand like six months later.

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.

Like, you know, with Rails and Django specifically, you get so much out of the box, so many guidelines to work with, not guideline 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 it's mainly like a learning process to get there.

Where it's like one more thing you need to think about basically.

So you're so you're the Flask course that you have, a video course, you build a very um full-bodied SaaS app.

Um, I guess how did you or how how have you learned, you know, the best practices that you then teach to others?

Like were there certain uh open source apps you saw that worked well, or like what was that process for you that you now distill, you know, for others?

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 you grow into the best practices over time.

So when it came to creating that Flask course, the Build a SAS apple Flask one, um, 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 uh a course around that sort of and uh 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.

You find this, you find yourself doing the same thing.

Oh, I've done this before.

Oh yeah, okay.

If I structure it the other way, it's a bit more fiddly.

And so you go with what works.

Yeah, for sure.

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 um.django project and conferences, but Flask is Flask isn't as developed in that sense, is my my sense.

Yeah.

Honestly, I just use the IRC uh 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, a Sunday morning at like 6 a.m.

I mean with Django, all those, and then there's also um I'm sure I know Carlton.

I mean there's the Django developers list on Google Group.

And then um what do we have?

We've got the forum and we've got the the mailing list as well.

Yeah, so

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 that seems more structured than Flask, but it's fairly unstructured.

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 uh I

You've got it 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.

Or could 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.

I don't want to say exact dates because I don't know, but it was like May 12th or 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 decorator syntax, like convenience things.

Um yeah, I haven't gotten super deep into the async stuff, so I don't know how much we're gonna be able to talk about that one.

Um, but I know there is async in 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 or like ORM, etc., or no?

Uh it's a good question.

So if you want like the full, massive um, I'm gonna 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 WISGI, 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 uh concurrency going without any big changes, and then we also have the the the the ASGI side of it, which is the the async um standard, like whiskey was the 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 gonna 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.

Um, but I think what's nice is that 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 the 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 doing because there was a there 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?

But it sounds like um 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.

Um, and you know, obviously if you you know if you if you if if throughput on a single thread is your you know Sanaqua non, then you have to go for a you know async framework like Starlet or whatever and be fully in that world.

But I think for the the vast majority of cases we don't need that, right?

And so it's 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 Django, uh a Django-like API, right?

It's like where you can divine 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.

Um you know, be but that's fine.

That's yeah, yeah, yeah.

Which is nice is that it's being because like so ASGI was added to 3.0, 3.1 had um views and then models in the ORM as the was there was there another one?

Views and was there a second one?

And you could run you could run with an ASGI server, but it was it was kind of foundational for something.

There was no there's no real benefit to that at all.

With 3.1 and the view and the view layer being um async compatible, that was kind of a nice addition in that you can you can divine these async death views just within your WISGI environment, or you can you know run a full ag ASCII pipeline down to the view.

The next phase, the the real, the one that will really change everything, I think, is um getting async down to the ORM.

I think that'll that will enable a whole different because at the moment, let me take it, let me give you a concrete example.

Um you can have an A you can have an async um view, could say, but let's say you want um the request.user, you want to access the session.

Well, in Django, request.user comes from the database.

And so the middleware that pop the session middleware that populates the session has to be wrapped in um a thread executor.

And because of the way database connections aren't async, aren't thread safe, they're not async aware, um, all those database connections have to essentially be done on the main thread, on a single, on a single main thread.

All those so every so essentially it's it's it's not concurrent whilst you're accessing the ORM.

Essentially it's still single-threaded.

And that's a real blocker.

Um so as soon as we can get a a proper story there at the ORM level, then it it the potential to increase the throughput becomes you know much higher.

So I guess I 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 uh transactional email service.

Uh 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?

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 um 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.

So kind of what what like what happens if the email fails to send, you know, you can't, you know, the 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've 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 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 and if you can do that um concurrently, you can reduce times.

Um it it comes with things like proxying servers, it comes with um and yeah, handling, you know, handling more more in in theory, handling more requests on a single threaded worker, on a single worker.

Um but it it's not gonna eliminate the need for say queuing systems, I would say.

It's not gonna 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.

Like it's sort of the same, but it's they're gonna be separate.

Probably, you know, eventually when it is all built out, you'll still need both, depending on

Yeah, I mean I I think the advantages right now are what um making requests out to third-party services and then things like um server-center events or web socket communication that you can do, that's you know, that's when it starts to make more sense, you know, when you you don't want to hold open a thread for a connection if you've got you know multiple, you know, you start scaling up WebSeccuit connections, you can't hold open a thread for every single one.

Because I don't know if if you've looked into using hotwire turbo yet or no.

But go on, tell us about what you're excited about with hot wire, 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.

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 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 uh 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 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.

So async would be very nice there instead of having to use, you know, like a third-party WebSocket service or uh run an extra server on your own.

They're the sort of is there is there much point in just replacing the the traditional um request response cycle?

No, not really.

Like that per that works perfectly well for you know the vast majority of cases.

But then 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.

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.

So those things are are coming in, and yeah, it's pretty exciting um to not have to write JavaScript yourself.

Yeah, yeah, yeah.

So that's so there's also the package called Django Unicorn, which is um 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 WebSockets to then again do this live HTML updating.

We'll we'll put a link to that in the

show notes.

Like, you know, and I don't know.

So you have a course on Docker.

Docker is 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.

It was like 2014, I want to say.

Like Docker has already been, it was one-o'd by then, I think it was like 1.4 is when I started.

But we're talking like ancient times in in the tech universe.

And um back then, yeah, the 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 it slowly gets better over time.

Like right now, Docker, uh 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.

Uh 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 Mac OS and stuff, but you still need to manage like a virtual environment.

And then um, you know, maybe if you're using something like Postgres, you're pulling in the PG package, which is gonna have like a C dependency that you need to install, uh, 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 Mac OS and Linux, that's a way different experience.

And uh, 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 Elasticsearch or whatever you you know your app happens to need.

And before you know it, you're in this like like uh 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 of 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 gonna get out of date 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 part of a time where I can actually use that stuff because I've used the alternatives and it just it wasn't good.

I've I've I've cr I've cried plenty of blood.

Um but what would I say?

I you know, I don't know how to do it.

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 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 my little my little Django app 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, Gone, why don't you like Docker?

I'm like, oh God, do we have to do that?

It's yeah, it's I mean if you don't need it, it's a massive

It's mass m like so it when you're when you're when you have complexity, uh it yes, it can be simpler, but you then you trade off the the getting the packages installed for um you know building containers and you know managing all of that nonsense, and it it's not it's not time free, you know.

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 gonna 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 add up.

And it's like at that point, it's like hang on, I wasn't this meant to be much simpler.

But the thing I really want to talk about um is our last major topic is deployment, which um um Docker ties into that, but you have thoughts.

Um Carlton's been working on button.dev, which you can sign up for, which is a simpler Django deployment story.

Um so maybe Nick, deployment, um, with or without Docker, how do you like doing deployment these days?

And let's just have a discussion about you know, Flask, how do you like to deploy it?

Um, because deployment is always pretty individual.

So I'm a really big advocate of keeping that it's it's funny that I say this now, like keeping things simple, you know, until they don't need to be simple.

Um 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 Prad, I'm totally cool just doing a Docker Compose up, 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,000, $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, and no one's gonna die if um someone gets like a 502, you know, like back in a found for Nginx errors.

But yeah.

Yeah, maybe then you can transition into something like uh Kubernetes or a container orchestration tool that'll just help you minimize downtime.

Um 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.

Um 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, uh 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 gonna be on one VPS.

Maybe I'll use a managed uh Postgres server so I don't need to, you know, deal with that.

Well also makes it easier to keep this date 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 gonna be in a couple of years.

Um 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.

I can't agree more with what you've just said, like it's perfect.

Like keeping it simple, keeping it simple until you need more.

That was the phrase you used.

And it it's exactly right.

It's people not for one, I think it 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, uh 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.

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're you have one instance of your app running and no load balancer, so you know, you restart your app and it's gonna be five seconds of downtime, you know, however long it takes your application to boot up.

But if you're using Open Resty with Lua, you can actually script a solution to where instead of having those requests be served as like a 502 back end because it's down, you can have Nginx queue those requests up in order.

And then if the user, like endpoint of view user, is just gonna have like a busy mouse cursor on the site.

It's gonna look like the page is hanging, but they're not gonna get that 502 backend not found.

And then when your application comes back up, it is gonna release those items from the queue and just uh serve them as if it's basically zero downtime.

So 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 all crazy stuff like that.

Because one thing I like to do is just use um um uh an application load balancer in front because I think it's good, it 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 it's kind of nice.

But exactly, yeah, you could you can configure Nginx to hold that hold those requests.

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 uh you need to be aware of.

I'm sure you know that.

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 it, 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 ac I there's only once you start changing your your database structure, there's only four words, and that's just a difficult topic, I think.

I think that's oh yeah, you know suddenly

No, I mean then if people you know, there's a reason why people make a living specializing in that kind of more difficult thing now.

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 Ray Carlton.

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 go in, you know, fire up the AWS console, right?

And you're gonna get an anxiety attack because the 2,000 services that appear.

I don't for a more you know, a mortal getting started, that's not a 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 always sounds it's always like you know, I've been working on this 10 years and I've 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 from in the you know, the I just want to get my app online, right?

I just want to get my app online.

There's and there's like just a total gap from a completely hosted, you know, maybe a Heroku thing to AWS expert.

Um, but but you know, you've made that journey, Nick, right?

So like I just curious, what was that like for you?

Like, how did you have to do that?

Or what was the process that forces someone to spend all these years, you know, learning about the ins and outs of deployment?

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 it can access, that everyone else can also.

Like, how do I get there?

And uh 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 it.

Okay, what needs to be done there?

Okay, so what cloud hosting provider do I use?

Digilotum, 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.

Um, or I have the hosting provider.

Now, like what operating system should I use?

Should it be Ubuntu, Debian, something else, something else?

And then that's just like that's like a that's like a three-day rabbit hole now, you know, where you're you're reading like 15 different blog posts, like 20 YouTube videos, trying to like, but it's tricky because you 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 it 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 they're like, wait, no, 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, 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 Popular Ansible or uh Salt or 10 other ones.

And then uh that's another rabbit hole of years, by the way.

Uh ultimately I ended up choosing Ansible, by the way.

And uh, yeah, I've written like 10,000 lines of Ansible YAML over the years.

Like, you know, I I don't want to go super deep into Ansible, but uh configuration management, it's a way for you to be able to run, like 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.

Um yeah, and then after that, it's like eventually get to the point where um 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 app side of thing.

Like most of my contracting work now is actually just more focused on that.

Uh 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 on my dev box, just get it up on the internet.

I don't care how it gets there.

So I appreciate services like that.

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.

Like, I I've got enough to deal with at the app level.

Mine was hacked right away.

Like within you know 20 minutes on Linode, I think you know, I got a thing being like your thing is spamming something, it's insecure.

And it's like, why would you let me set something up that is you know unsafe?

So it's a very scary thing.

Yeah, and it's a very frustrating thing, less scary, more just like, how does anyone do this?

It's like you have everything up and running, and 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 back.

Well, I well, so maybe I don't know, is that a a future course from you, Nick, about you know, all those steps and everything else, or is that yeah,

But it's gonna 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 uh Docker Compose, but let's not skimp out on making this like production ready, right?

So we're still gonna 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 turn just into using um something like Kubernetes if you wanted to in the future.

Like I I have that a little bit.

I have a Django 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 is 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, is 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 to 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

Like, you know, and you're not done yet.

Like now it just starts.

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.

Like, you know, you you build something that you could deploy a hundred times the application that you've actually got on on what you've provisioned, and uh that's all just wasted.

That's sort of an engineer's curse a little bit.

Definitely, yeah.

We're we're coming up on time.

Well what else?

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 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 you think about that and you look back and you're like, that's horrible though.

Like, why would you put on 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 that 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 there, 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 um 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 the stuff.

And you know, there's definitely value in that.

Well, I I see a little headshake in there because it is a video call, but Dod, do you want to expand on that one?

Yeah, yeah.

Um, even within Django, so we have on the J 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, um, depending on how you cache it.

I think generally, and Carlton, you're the you're the expert.

I would say you 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 what do you say, Mr.

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

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 gonna take in it?

That's gonna take validated data that came through the form layer, and so you know, date, you know, logic about data validation that's gonna live in the form layer, you know.

So there are for me, there are kind of places, but the you know, then within it, it's like, well, do I do I use a model method or do I man 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 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 the starlet and fast API that people are you know getting into now um for for that same sort of reason.

It's small and you know they think, oh, I can I can bolt together my little thing.

I don't I don't know if you've used those frameworks as well.

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 uh it's much easier to keep everyone basically on the same page, on board 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 employees, getting them up to speed on a Django code base is probably gonna be a lot easier than uh a random flask one because yeah, it's just gonna look more like the docs, I guess, versus an individual, like whoever the CTO decided to make the Flask app.

So like there'll be too much logic in the in the view, and it'll be like, you know, we what are you doing this in the view for?

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?

Like I I was so pleased to see the announcement that the Flask 2 Flask 2 was coming and that it was gonna have the async and all the rest because I was I didn't know that that was on the cards, and it was like, yes, thank you, that's brilliant, because it it's really important that Flask is able to move forward and you know have have the new shiny features.

I think that's you know it's it's vital for the not vital, but you know, frameworks come and frameworks goal, but for something with as much um weight in the community as Flask has, for it to, if it hadn't been able to move forward, that's it would have been a really sad loss, I think.

And so

Like there only could be one winner, right?

There's three winners there.

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.

And you know, it in the front-end world we've talked today about turbo and um HGMX and you know various approaches to live.

It's it's that's quite an exciting area.

And there's all these different things experimenting with different options, and the the result of it would be five years' time, there'll be mature and established stories in for all the frameworks there.

Then I can sit back and create my server rendered uh application so it sprinkles a JavaScript here and there, and then I'm a very happy person.

Yeah.

Um yeah, I mean, Carlton, so is 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 Flaskello world, but you can get kind of close.

It's really a question of where you put things.

Um But we had, I mean, uh uh 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?

Um, and he made the analogy of like, you know, those are um trucks you build out of Legos, whereas Flask and others are a bag of Legos you dump on the floor.

Um so it sort of depends on how you want to spend your time.

Um but I have to think that part of it too is it's uh these full stack frameworks or or these batteries included, they're they're a little bit all or nothing.

You can add Flask to a Rails app if you want to.

Um so in that way it's easier to kind of add things on, especially in a larger company where you have lots of teams and um it's perceived to be easier to add on a microframework as opposed to Django.

Though you can also do it with Django, but at least I'm curious, I guess, if you see this.

I see this a lot of times as, 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.

It's like once you go off the guardrails, you're kind of fully off.

Right?

And so that's 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.

Like not necessarily like Django apps, like you can separate your application at application level, but I mean like services.

Nice.

I feel like that's not a great that doesn't sound great so great when I say it again.

So oh I can just knock it up in Flask.

If it's only a couple of endpoints, it's easily done, it's there, bam.

And then they're a Flask user, and then uh I'll carry on and this is nice, and that's fine, that's super.

So I do write um a weekly blog post at nickgenitakis.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 runningandproduction.com podcast where half the episodes are Django, so you may want to check that one out.

And uh Yeah, and

Um yeah.

So thank you.

Yeah.

Well, and if anyone I doubt it, but if anyone listening doesn't know, there is a Django dash news newsletter that's weekly that I do with Jeff Triplet 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, 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.

Um, so it's Django Kong 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.

You should tell I mean marketing,

Shiver.

I'll say all the positive things, Carlton.

You can underplay it.

Yeah, yeah, yeah.

That's fine.

I you know, I mean I'm still in um building phase.

I just gotta get through Django 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.

Um, so doing the podcast, Nick, what have been your takeaways, right?

Sometimes people say, Yeah, podcasts will be fun to do.

Like how how much work is it and what have you gotten out of doing it?

Because you've you've done it for a while now.

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 where the episodes aren't sponsored because the audience isn't big enough.

So, you know, you you kind of have to put the burden on yourself to do all of the work.

So it's like finding the guest that you want to have on, then recording the show, scheduling the show, etc.

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, uh, 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 gonna 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 you want to talk about rabbit holes, like the audio stuff is uh also never ending.

Because yeah, if you're just on Hiker News all the time, it's always like Kubernetes this, Kubernetes that, like you 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 for at small scale and you know medium scale

Exactly right.

That's this podcast came out of DjangoCon 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.

Do check out Nick's podcast, Nick's site, Nick's courses.

Um thank you for coming on, Nick.

Bye-bye.

Bye-bye.