Transcript: Django vs Flask - Michael Herman

Hello, and welcome to another episode of Django Chat. In this episode, we're joined by Michael

Herman, the founder of TestDriven.io. I'm Will Vincent, joined as always by Carlton

Gibson. Hi, Carlton.

Hello.

Hello.

And Michael. Hi, Michael.

Hello. Thanks for having me.

Yeah, happy you could come on. So the title of this episode is going to be From Flask

to Django because you've spent a number of years writing production-level flask code

and recently switched over to Django.

So we're going to spend a lot of time talking about that switch

and differences you've seen between the two frameworks.

But first, can you give a quick background on who you are

and how you got into programming?

Sure. I'm an engineer slash educator from Denver, Colorado.

And yes, I am the founder of Test Driven I.O.,

which I will talk about in probably just a bit.

So my background, I started web development in the late 90s,

competing with a friend in Missouri.

We were building PlayStation websites and eventually moved on to the LAMP stack and got into hardware during high school.

My undergrad years I spent at University of Missouri, started in computer science, moved to philosophy, ended up getting a business degree.

After undergrad, moved to New York, got a job at Yahoo, ended up getting transferred out to San Francisco,

Quit Yahoo, got a master's degree, started working at startups, got into a lot of Python, web scraping, testing, and that's what led me to co-found RealPython with another friend of mine.

So RealPython is a...

Well, it's a Python tutorial site, right? Or that's what it was initially when you were involved.

Yeah, so, yeah, RealPython, I started as like a Kickstarter, basically, for teaching practical Python, learning by doing, experiential type learning Python.

And this was back in 2011.

We ended up kickstarting two other courses, a Flask web development course slash web fundamentals course, and then a more advanced Django course.

And so, yeah, again, the philosophy behind it was learning by doing, experiential learning.

There was nothing really out there at the time in terms of beginner courses that had that experiential learning philosophy.

And so, yeah, we kick-started RealPython.

I got more into tech education that way.

Taught full-stack JavaScript for a couple of years at a boot camp called Galvanize.

And that was in Denver?

Yeah, that was in Denver.

And so after Galvanize, I had to deal with a bunch of imposter syndrome.

Can I build anything other than just a basic CRUD app?

So I went back into the industry, focused mostly on flask development.

And at the same time, started TestDriven.io, which focuses on teaching mid- to senior-level developers how to build, test, and deploy microservices to AWS.

wowza got a big tail so what were you using back in the 90s you said you started off

was that pearl or php or what geocities well good yeah i trump your php

just straight html and css yeah good a lot of tables yeah good so maybe so let's talk about

um test driven because that's built with django and maybe um what was that process like so without

going too deep dive into Flask. I mean, if listeners don't know, it's a micro framework

with Python. What kind of struck you? And you'd used Django before, but I think it'd been a couple

of years since you'd used it on a large project. Is that right? Yes. How did you choose Django and

how did you find that transition to be? Yeah. So, I mean, Django, it allowed me to move a lot

faster than with flask so i wanted to you know build a full stack uh web application with server

side templating and so with all the pieces there that you get from django out of the box i was able

to move a lot faster uh with django over flask well you said you'd been doing full stack um

javascript development as well so you've been using presumably a some kind of micro framework

and the JavaScript world, like...

Express.

Express or...

Right, Express?

Yeah, Node and Express, yeah.

So did you give that a thought, to use them,

I guess, to get to Carlton's point?

Well, I did have a transition back to Python after Galvanize.

So, yeah, I did teach full-stack JavaScript.

I worked on the dev team there, and that was a big Rails app,

and they had some microservices in Node and Express that I worked on.

But after leaving Galvanize, I worked for a company that was all Flask.

And so I got back into Flask that way.

So really the decision for test-driven kind of came down to Flask versus Django for me.

Right, because you were in the Python mindset at that time.

Yeah, yeah.

So when you started with Django, do you recall, had things changed since you last used Django?

Because it had been a number of years.

Did you have a sense that there had been a bunch of changes like migrations and stuff?

Or had you used those before you switched over to JavaScript and Flask?

Yeah, not much had changed, actually.

Yeah, South, the old migration system, you know, was now in the core, which is nice.

But I was already familiar with how the ORM worked and the data models and whatnot.

So there wasn't that too many changes.

And I think that's really nice with Django.

It moves a little bit slower than, I would say, some other Python frameworks.

But because of that, it's much more stable.

Well, like the core ORM operations have been unchanged forever, right?

So, you know, if you know how to build a model and you know how to filter and you know how to do those core operations, that's the same from, you know, day one to now.

And there's all this other stuff that you didn't know about, not that you didn't know about, but oh, there's annotations now, oh, there's search now.

And when did that appear?

So given your background in teaching, now that you're fully in the Python world, if someone comes to you and says they want to learn web development, but they haven't worked with a framework before, how do you think about that choice of Flask versus Django, which often comes up for that beginner?

Yeah, it sort of depends on the end goal.

I mean, I would say regardless, in general, regardless of whether someone is wanting to learn Flask or Django, I generally start or I recommend that they start with Flask.

And Flask is just a great tool for learning web development fundamentals in general, like HTTP, routing, that sort of thing.

And those things are common, you know, across all web frameworks.

So I think also one thing that I often overlook is that the source code for Flask is much smaller.

It's much easier to read.

And so diving into the source code of Flask is really nice.

you can see what's going on underneath the hood.

Yeah.

What about for APIs?

Are you using an API with test-driven or not at this stage?

I have a couple endpoints, yeah, but I wouldn't call it an API.

Have you done – because I wanted to ask, you know, Flask,

especially for how do you build an API endpoint?

Flask can do that in a couple lines of code, yet Django REST framework is very elegant.

I just wondered if you had a chance to play around with DRF recently versus doing it kind of raw with Flask.

I have looked at DRF.

So one of the courses on the test-driven site is a Django course that deals with Django channels.

It's all the asynchronous fun and Angular on the client side.

So I had to kind of dive deep into DRF to really understand what was going on there, especially with the authentication.

So are you, for local development, are you using Docker these days with test-driven?

Yes, yeah.

And how do you find that?

Because I think you'd been using that at work beforehand, or even you've been using Kubernetes.

Is that correct?

Yeah, yeah.

So, yeah, Docker, you know, it just simplifies the development process.

Yeah, there's definitely, you know, hurdles in the configuration and 12-factor with settings and whatnot, .m files versus hard coding, you know, environment variables in the Docker Compose file.

But, you know, once you sort of figure out how Docker is working and figure out how that you want to get those environment variables inside of your container, then it just makes the process a whole lot easier.

Yeah. And are you, what are you doing for deployment?

You've used a host of services that we've talked about offline before.

Yeah, I'm using Heroku, so it feels like 2014.

And are you deploying with containers on Heroku, or you're just doing it like Pro-C file way?

So yeah, right now I'm just using Git and the Slug compiler.

So I am in the process of moving everything over to the Docker deployments, but right now I'm just sticking with the Slug compiler.

And then, so why did you make that choice? Because clearly you know how to set up a server and do it, you know, on a VPS if you wanted to. How did you think about that choice of using Heroku or, you know, a platform as a service as opposed to infrastructure as a service, given that you have experience with both?

Well, Heroku gives you everything out of the box. It gives you logging and monitoring. You can set up cron-like jobs. All these different services that I would have to set up and manage and upgrade and maintain on my own, Heroku just does that all for me.

So I can just pass it Django and Green Unicorn or whatever and then set up all those different extensions and I'm good to go.

That's the saving, right?

It's all very well maintaining, I don't know,

your Chrome file, your crontab file,

but that's not the most fun in the world.

No.

And it doesn't take long per se,

but there's that job, and then there's the other job,

and then there's the other job, and then there's the other job,

and all those add up to more than your Heroku build.

So what was the process for prototyping and then building?

And I know you're still working on test-driven.

Can you talk about how you prioritize features and again,

Because I think this is a trap sometimes when you go from working in a production environment, it's easy to want to over-optimize everything because you're just familiar with it.

But there still needs to be some sort of process to getting to this optimized point across the board.

And maybe we can talk about some of the optimizations on Django's site.

But do you recall what was the MVP and then how you layered on complexity?

Because I think you initially had a Jekyll site before, so you weren't starting from scratch with the test-driven domain, right?

You knew you were going to have traffic.

Sure. So, yeah, I did start with a Jekyll site, just a static site generator, and was selling the course as just a PDF.

And I wanted to move to more of like an interactive web application where the end users, instead of downloading a PDF and then never coming back again, always have to come to the website and log in and go through the website.

It's more interactive for them, and it's also customers will continue to come back, and I can upsell them and whatnot.

So, yeah, I basically wanted to port over the main functionality from Jekyll, and then from there needed to add on, you know, authentication authorization and then some sort of payment provider to, you know, handle payments.

And then what are you using for the payment provider?

So I'm using Stripe for that.

And had you thought about, because these days, what, it's Braintree as well, I think, and Stripe are the two.

Was there another one that you considered at all, or was just Stripe the one you thought you'd go with?

Yeah, so, you know, there's Stripe, there's Braintree, there's a whole, there's a number of different startups that have been built on top of Stripe.

Right.

So I was thinking of, you know, sort of abstracting that out.

So I did initially start with one of those, Gumroad, and I was using that when I was just selling the PDF.

But now that I'm not selling a digital download anymore, I moved away from Gumroad.

Got it. And then for email, because you must have both transaction and potentially marketing emails, did you set up sort of any async process for that?

Or maybe you could talk through how you set that up in a Django context.

Yeah, so I do have transactional emails for password or email confirmation, and also for other sorts of things.

So, yeah, I'm using Django RQ, the extension, for Redis Q.

And so to get the process out of the request response handler, it just puts a job into the queue, and then I have a separate process constantly looking at the queue.

is their job is their job if there's a job it grabs the job and then sends it to

send grid and then send grid will send out the transactional email got it carlton i've dominated

the discussion are there any questions that come to mind for you yeah just on the queue choice i

mean like um so the big beast in the room is celery right um and i'm just wondering why you

chose rq over celery i mean you know i've got my own views there but it'd be interesting to see

what you've got to say i've used rq um pretty extensively the the past like three or four years

and i was just familiar with it i haven't touched celery in a little while uh i didn't really need

all of like the robust like um scheduling and retrying that i know that you get from celery

uh so it was just sent basically sending transactional emails i have a couple other

things i'm using the queue for but yeah i mean just from a functionality standpoint i didn't

need everything that Celery gave me. Yeah, exactly. Okay, brilliant.

And what about, again, because I think this is a great chance for listeners to go through the list

of, you know, building out from scratch a Django site, you know, with the knowledge that you have,

was there, you know, testing? So how did you find, I guess, doing tests with Django? Because

it'd been a little while, and then are you using any additional services as well to test your

application? Yeah, the testing pyramid has really changed for me the past few years. So

So testing pyramid, most of your tests are going to be unit tests, and you have some functional tests.

And then at the very top of the pyramid, you do a bit of end-to-end or browser-based testing.

So a testing tool came out a few years ago called Cypress, and that's for browser-based testing.

So it's really actually good for testing out asynchronous-type single-page applications.

So I would say Selenium is great for server-side templating-type applications and page refreshes.

It doesn't handle all the asynchronous-type stuff really well.

Cypress handles that really well.

So what you get out of the box with Cypress is basically end-to-end tests or browser-based tests that are a whole lot less finicky and a lot easier to write.

And so because of that, the testing pyramid is, for me, I write mostly browser-based tests and unit tests.

I kind of steer clear of, like, a lot of the functional tests at this point.

Interesting.

So what would you call a functional test in that context, then?

Because, you know, obviously, like, running a browser automation, that's obvious.

And then unit tests, you're probably, you know, testing individual bits of logic.

And how would you, what would you call a functional test, and how would you run that?

Yeah, I guess a functional test in, probably what I'm meaning more is, like, integration tests.

Okay.

So, like, just if you have to hit a database or, you know, you have to test, like, multiple functions or, you know, multiple views or whatnot.

Various components working together.

Yeah.

So, related to testing, I assume you're using some form of continuous integration as well?

Yeah.

So, I'm using Semaphore CI for that.

And then why did you choose them, I guess?

Is that a hosted service?

Is that?

Yeah.

Yeah, it's a hosted service.

Okay.

Because there's what?

these days there's there's semaphore there's travis there's circle um i think github has

their own one in beta maybe gitlab has their own what was it about semaphore that um stood out to

you i i'm not sure i don't remember other than you have to pick one and you know right but are

using it just for deploy you're using it for um deployment as well right not just can you talk

about just the pipeline of incorporating it i guess in the project yeah so yeah i am using it

for both CI and CD, so continuous integration,

continuous delivery slash deployment.

Yeah, I guess in terms of the reason why I picked that

is the way that I'm running my Cypress tests in the CI environment.

So I'm not running the Cypress tests inside the Docker container.

I'm running the Cypress tests outside the Docker container,

and they're testing against the Docker container

or the web application that's running inside the Docker container.

so for whatever reason i couldn't get that to work exactly right on travis circle um and i could get

it to work on semaphore i have been meaning to maybe switch over to get lab just because i like

uh having the um the source code and cicd and whatnot built into get lab and get lab has um

vaults for secrets as well so i like that you know one stop you know shop type platform so

eventually i'll probably move over to sim or move over to get lab but for right now semaphore is

just working uh for me and so there's not really a reason to switch no once you got one of these

things going it's really easy just to keep it going right sure yeah yeah yeah and then are you

doing um uh so local production are you using a staging server as well yeah i do have a staging

environment yeah and then um just for maybe and since you're a former educator for listeners who

aren't familiar with that flow could you talk about why why you would set up a staging server

and how that flow plays out?

So you do a local change and then what happens

before it gets to the live site?

Sure.

So, yeah, I do a form of like the feature branch workflow,

sort of like a Git flow type approach.

And so, you know, I create a new feature branch.

I make some changes locally.

I test it out locally.

I do a commit, push it up to GitHub.

That'll trigger Semaphore.

then you know run ci um and if it's on uh for if uh if it's running against just a feature branch

uh it won't actually do any sort of deployments to staging or prod but as soon as i do a merge

request um another merge to master uh merge to develop another uh build will kick off and then

as soon as i merge that into develop that's when another build will kick off and as long as that

passes then it'll deploy to the staging environment so the reason why i do that is because i just want

a place to be able to test it out on heroku and just to make sure that what's happening on my

development environment locally is the same as or as as close to what it will be when it's in

production. Right. And then, so then do you manually go and check before committing to

production from staging or how do you make that leap? I'll do some like manual tests. I mean,

everything's really covered by Cypress at that point, so I don't really need to worry about it

too much, but I'll just do like one last visual check or, you know, if it's a blog post or

something like that, I'll have, I'll send the link to the blog post author and, you know, they can

take a look at it before it goes live. So just little things like that. I like to be able to

view it before it goes live. Right. And so are you, um, as you mentioned authors, uh, so test

driven what started with just you, right. But now what's, what's kind of the master plan, right?

Cause I know you have another course, um, on there and are you, you're adding blog posts by

other contributors as well? Yeah. So, uh, test driven is, you know, starting to scale. I am

starting to bring on more content creators. So whether that's tutorial, uh, authors or, uh,

course producers. So the other course on there right now is written by a friend of mine, Jason

Parent. He is writing another course right now. It's basically the current Django Channels course

with React instead of Angular. I'm breaking up the large monolithic course, the microservices course

myself right now. So that's going to be like four or five different courses, hopefully by the end

of the summer, um, onboarding a couple other course producers, um, right now as well. So

just looking to scale that out. I'm doing some design work right now with, um, some other

companies and, and yeah, hopefully the platform will have a couple more courses and have a nice,

uh, uh, makeover by the end of the summer. Sounds all go.

And then are you still going to stick, um,

do you think to the per course pattern or how do you you know as a content creator how do you think

about i mean because i think about this obviously all the time as well subscription versus um kind

of pay as you go given that you're now building out a platform haven't really thought too much

about that probably just continue to do this pay as you go are you setting up subscriptions that's

a going to be a lot of development work so yeah i'd say if i wanted to go that route it'd probably

maybe three to six months worth of development to change that workflow.

Oh, wow. Okay.

Also, I'm not working on test-driven full-time,

and that's part of the reason why that would take a long time.

Got it.

So I think there's maybe a couple more things.

Just on the stack itself, again,

because I think it's such a great chance to look at a newly built stack.

What are you using for, I don't know, for DNS?

Are you using Heroku or using something special to handle DNS?

So it's a combination of – it's actually Frankenstein together.

I hate DNS.

So it's a combination of DreamHost, CloudFlare, Heroku, and Netlify was in there for a bit.

And I got Netlify out of there, so I'm using CloudFlare, Heroku, and DreamHost.

This is just for resolving your host name, right?

Yes.

Right, wow, okay.

Well, so why, you know, why do you have three?

Like what was not working that caused you to add these all in, right?

Because if I'm, you know, I'm a new developer and I read, you know, one of your tutorials or Django for beginners, I just, I can put a site up with SSL and Heroku, problem solved.

Like what's not solved when you're actually at a production level?

Because I bought the domain name through a different company and then started out with Netlify Deploys and then went to Netlify DNS and then wanted to move to Roku.

And so I transferred the domain name once and screwed up DNS for about six hours, transferred it back.

It was, yeah, I don't know if you want to go down this route, but it was definitely a nightmare.

Yeah, just at a high level, I think.

But when DNS goes wrong, it really goes wrong, right?

yeah it's fair enough well as speaking of um uh so monitoring right um are you using any sort of

uh you know app specific monitoring or uptime monitoring because there's a whole you know

suite of tools for that are you using any of those as well yeah for uptime monitoring i don't

remember i'm using the uptime robot or something like that uh the platform doesn't really go down

at this point so uh which has been nice i think i've gotten like one email in the past um like

six months about the site like going down but it was immediately back up so it might have been a

false negative but or heroku something or other yeah so yeah uptime robot um using accommodation

of uh new relic uh century and log entries and you know all that comes from the heroku add-on

um um roku add-ons and then you know post postgres and redis yeah so are you doing some kind of apm

application performance monitoring with oh uh yeah i'm using like new new relic right i guess

new relic is handling that yeah and that gives you a like a breakdown of um request time where

it's spent in different parts of your code and things like that oh actually roku gives you a lot

of that information does it interesting like the the straight heroku dashboard will give you

a number um of nice key metrics like that for logging um because we've we're meaning to do an

episode on logging on the podcast we haven't yet what um like how deep are your logs what sort of

stuff are you logging right because this is sort of an extra step on top of your your tests uh or

can you talk through how you've how you thought about logging in terms of building out the you

know Django side yeah whenever I'm doing a try accept or try catch that's generally I'm throwing

the logger in there you know certain things like you know transactions in terms of straight

payments I'm throwing the logger in there let's see where else it's kind of I haven't really

thought too much about that and that's you know definitely something there's a backlog for tickets

to clean up the logger.

Going back to the application performance monitoring,

I'm using Scout for that.

That just hit me.

So that's another add-on that you get from Roku.

And Sentry is used for like the exception monitoring.

So that's anytime an error is thrown and it bubbles up,

then Sentry will catch that and send me emails and whatnot.

Yeah.

So it's, I mean, it's quite a lot of,

just for listeners to get a sense of all these tools

On the spectrum of a relatively straightforward application, you're using well over a dozen tools, third-party tools, right?

Either free or paid to help you monitor and process just pretty standard web app flows, emails, and all the rest.

Yeah, and I am on the free tiers for all those monitoring services.

They come out of the box with Heroku, and Heroku just allows me to be able to just focus on my application and not have to worry about infrastructure at all.

I would say Heroku gets expensive quick, but I'm a single-person development team.

I'm not going to hire a DevOps person anytime soon, so I'm happy to pay whatever they tell me.

Yeah, that's a great question, right?

that's that's because you know what's your hourly rate what's your how would how much would it cost

you to hire a developer to do these things how much do you save and these platforms of the services

the the sort of the that you do the psalms you know that's quite expensive but all the things

you don't have to do well what did you save and you know we talked to tom dyson and you know he

made the comment that you know these from um wagtail yeah um wagtail fame and he made the

point that um you know the if you really do the maths and you include the developer time you can

scale these things quite a long way before they they become uneconomical and i believe um torch

box which you know major major uh agency they use heroku for most of their um client work actually

yeah for exactly these reasons right yeah yeah i mean that's one of the reasons why python came

into existence was like to optimize for the developer time yeah yeah you know exactly um

So there was one other thing I've noticed on your site.

You have for search.

This is relevant because by the time this episode comes out, it will be announced that

I'm giving a talk at DjangoCon on search.

Can you talk about how you went through that process of search?

Because search is such a deep field, and you've got a nice search implementation.

How did you go about that?

I think from the end user perspective, it may look nice, but it's very, very janky in

the code.

So I'm not doing anything fancy in there.

And actually, I haven't looked at that code in like three or four months.

So for me, it's kind of interesting because, you know, there's this kind of pressure.

Oh, you've got to have Elasticsearch or whatever.

You know, you don't have to have Elasticsearch a lot of the time.

You know, you can do it with your database.

And for a lot of sites, that's actually good enough.

Yeah, I'm really just doing straight filters on like the content itself.

And so I guess it is doing a very janky flavor of full-text search,

but I'm not taking any advantage of any of the full-text search features

that you get from either Django or Postgres.

Right, okay, interesting.

Got it.

And yet, from the end-user perspective, it's quite effective.

Yeah, it works fine as just an end-user, you know, no complaints.

Yeah, it's a very, very basic search.

I have complaints about it, but I'm a bit close to it.

But yeah, I mean, it's just a very, very basic search.

There's not really any ordering to it.

So if you search for Docker, and really it's just going to sort that based on the date.

So there might be a blog post with 15 instances of Docker.

There might be a blog post that comes after that that has one hit for Docker,

and it's going to sort that based on the date.

So it's not even like concerned about how many different instances of Docker showed up showing up.

So it's a very, very naive search.

OK, but, you know, I mean, if it's good enough for the size of the content that you've got and it serves for the users, then that's not.

I think this is really interesting just because it's a problem that we see all the time in technology.

We're always tempted to gold plate it.

We're tempted to do the thing which is the absolute best engineering standards when it's a lot of times it's not needed.

Yeah. Given the unlimited amount of time, I would definitely, definitely focus on it. And

I do get a lot of emails, uh, people asking not directly about search, but indirectly in the sense

of like, do you talk about this in the course? Or do you talk about, you know, that and, or where

do you mention blah, blah, blah. And in my head, I'm like, well, use the search. And then I'm like,

well, the search isn't all that great. So maybe I shouldn't tell them that.

Okay. Yeah. That is nice, I guess, versus a, well, I guess you can search a PDF as well. I was going to say you can point them to search and they can, if they have the course, they can search through and find it. Though I guess if they don't, if they haven't purchased the course, they only get what the first, the first couple parts or chapters, they don't get the full thing. So that would probably be why they would ask you that question.

Yeah, that makes sense. Yeah.

Yeah. So something else you're involved in, which we haven't mentioned yet, is your conferences. I mean, you speak a lot, but then also Pi Colorado is coming up this fall, which you're involved with. Do you want to speak by that at all?

Yeah. So Pi Colorado is early September. So that's September 6th, 7th, and 8th. The main conference is going to be the 7th and 8th. That's Saturday and Sunday. And then there's a workshop day that's similar to the PiCon workshops that's going to be on Friday the 6th. So I'm the program chair. So I am organizing all the talks, all the speakers, and all of the workshops.

Wow. Well, that's quite a bit of work.

Yeah. And so the next weekend I'm actually getting married. And so I'm kind of, September is going to be a little crazy for me.

Yeah. And do you know, are you going to be able to attend DjangoCon, which I think is later that month?

I don't know. Depends on what things look like, maybe mid-September. I'm probably not going to make a decision on that for a while.

So we've talked a lot about Django.

Maybe just to circle back to what we started with.

You've worked with so many different frameworks.

You've mentioned Flask, Rails, Express,

how do you think of you know which one to choose like what are some cases where you know flask is

very well suited to something versus rails or maybe express are there some examples that come

to mind where you would pick a specific framework for a specific task or would you start with a

language yeah i mean i would start with definitely the language and figure out you know which which

language you're going to be coding in because if you're in you know if you're coding ruby you're

probably not going to want to use Django, but I'm not sure how to answer that question. But,

uh, yeah, I mean, some of the, some of the use cases that I look for, um, in terms of

Flask versus Django, I look at project size. I look at the type of application. Um, I also look

at the, uh, the size of the team. Um, let's say the application type is, is, is, is a big one.

So, you know, a website versus a web app, uh, versus a web service. And I know that not everything

is cleanly bucketed into those three different things.

But let's say a website is just static generated.

A web app is a full-stack web application.

It could be a single-page application.

It could be something server-side templating.

And a web service could be just a basic RESTful API.

So I like to think in terms of those buckets.

And so if it's a website that's just static generated,

probably not going to use Django for that.

So if it's a web app, Django is great for that.

I think the Jam stack over the past couple of years, the JavaScript APIs markup, sort of the Netlify stack, the serverless type stack is kind of eating away into sort of Django's dominance as a web application framework.

and then uh sort of a web service uh i like to use either django or flask for that yeah i i've built

i spent a lot of time playing with static site generators and even jamstack types of things and

found myself constantly coming back to django why because every time i was like oh well now i need a

web form and i know netlify does this kind of thing now but it's like oh now i need a web form

now i need auth and it was like always the case where i just i'd save myself a little bit of time

setting up my django app and writing my first template view by just slapping up my html page

but then i had to go and retrofit it all every time and it was like ah do you know what

i give up on that and i found myself more and more just like i'm not going to experiment with

this static site generated for this project because it's just going to cost me time in the

medium term well partly you i mean that's also given that you know django so well once you know

Any tool, whatever framework it is, you can kind of make it do what you want.

And then do you need to read, you know, relearn the wheel?

No, exactly.

And using like, you know, an alternative micro framework, it's like, it's always more time

for me digging in the docs to learn the other API than is to just use Django.

But again, I guess that's familiarity.

Yeah.

Yeah.

I mean, that's a good point.

I don't think it's ever a good time when you're working on a project to experiment with something

new.

just go with what you're familiar with it's it's easy it's a lot easier to estimate how long it's

going to take to complete something and you know maybe dabble here and there and some uh with some

toy projects uh outside like a you know a project uh that you're doing for for work or uh freelance

or whatever but that's a good time when to like spin up like hey how can i actually recreate

recreate like this full django web application using netlify or flask right and serverless and

whatnot so and it's always worth giving every new framework a run and seeing what it does and seeing

it's the way it approaches things because it you know it makes you a better developer overall

because you know different approaches and different styles and yeah exactly well so maybe as a

concluding point um the title of your course is microservices um with what flask react docker um

how do you think about microservices uh you know when do you because i think i know you've worked

with those professionally, but in terms of for your own, you know, for test-driven, did you think

about a microservices approach or where do you, how do you think about microservices? Just to give

you a broad question. When are they appropriate? Like what problems do they solve and what problems

do they cause? Because, you know, they're typically used in larger companies. You don't necessarily

usually see a startup go with microservices. Yeah. I mean, to relate that back to Django

and Flask. The 2018 JetBrains Python developer survey, when that came out, Flask was actually

slightly ahead in terms of popularity than Django. And I don't know if that's just because that's

JetBrains users in general, but I would say that's more of the web development industry and the trend

toward the smaller frameworks, the microservices and the serverless platforms the past

uh, four or five years or so. And, you know, I guess going back, you know, directly to your

question, microservices, um, I mean, they're, they can be good. They're not, they're not like

going to fix, you know, like if you have a lot of problems in your company, uh, if your development,

uh, uh, if your development teams are very siloed, it's not going to fix that by any means.

Uh, you, you definitely need to address, uh, some of those softer skills first, but

microservices can help it can help scale certain pieces of your application that get a lot of

traffic that can help with you know isolating you know bits and pieces of your application to deep

decouple it from you know other processes and whatnot so that can run independently it can be

scaled independently so i know microservices is kind of a it's obviously a trend these days and

you know there's a lot of you know questions about it and you know how to go about it and

micro micro front-end frameworks or whatever like has been a trend on twitter the past like week and

that seems bonkers to me but maybe uh next year this time i'll be talking more about you know

micro web micro front-end frameworks or you know whatever people are called micro front ends i

think is the term yeah yeah but it's sort of the go ahead sorry i was gonna say so like the

problems that you have with micro front-ends is, and the same with microservices, micro back-ends

or whatever, is that the core state. So how are you maintaining state across those applications

if you need to? And, you know, ideal world, you wouldn't have to do that. You could be able to

scale and deploy all those things and you wouldn't have to worry about shared state, but there's

going to be a certain amount of shared state and that's a huge problem. Well, and I think you had

said at some point, Michael, that you thought one of the things about microservices is that it

shifted the complexity away from the individual developer kind of up a level to the, I guess,

maybe the SRE, the Site Reliability Engineer. Do you recall saying that? Is that something

you want to expand on? Because I thought... Yeah, you can quote me on that.

Well, it struck me when you mentioned that, because it did seem like you do have this issue

of if you, you know, it doesn't necessarily solve the problem, but it moves it from the hands of an

individual engineer who may have, you know, who knows how many years of experience they have,

maybe it kicks it up in a large site where you do have entire teams around site reliability and

deployment. And, you know, they can maybe are forced to handle some of those issues rather than

giving that power to an individual engineer who can do something silly in a monolithic

framework setting. Yeah, I mean, smaller code bases are easier to work with.

And so if you break apart your monolith into smaller code bases, you're going to have, in theory, you're going to have less bugs, you're going to be able to move faster, product likes that, developers like working on things like that.

But then the problem is function calls now become network calls.

And so you have to deal with that at the infrastructure level.

So you're shifting that complexity away from the individual developers more towards the DevOps, the sysadmin, the SRE team.

Well, so as we come to the end here, we've talked a lot about how you built test-driven with Django and your thoughts on Flask.

Do you have any concluding thoughts on, you know, developers looking at, you know, Flask or Django and how to think about that choice?

Yeah, I think that you really need to look at sort of the application type versus time, the amount of time you have to develop something.

And there's going to obviously be some tradeoffs there.

think about what you can absolutely not compromise on, and then base your decision on that. And based

on that, sometimes you'll choose Django, other times you'll choose Flask, and that doesn't make

one better than the other. I mean, they're really used to achieve the same things,

building web applications, they just have very different approaches, or the means are different.

Yeah, exactly. And I, you know, goal of this podcast is not to just relentlessly beat the

drum on Django, but to try to be honest and open about its strengths and why people choose other

things and just let people have that choice, but at the same time, not fall into the trap that I

think a lot of beginners see experienced developers do, which is just to say, it depends all the time.

So I appreciate that you've been, you know, sort of backed up the choices you've made and

building out test driven because ultimately a choice has to be made. You know, many choices,

even for a basic website. Yeah. Like you're going to choose your database. You got to choose your

web server you've got to choose your hosting you've got to choose like these hey you gotta

choose your language you've got it yeah anyway at some level you know it just becomes you just

choose what you're used to as we've mentioned before but it's also worth you know knowing what

else is out there and also having uh if someone says why did you use xyz say oh well you know

sometimes it's good to reevaluate your decisions because things uh frameworks do change um new

features are added um but hopefully django will just stay mature and just keep getting more and

more awesome. Yeah. And Django definitely decreases the amount of decisions you have to make. Same

with Roku. Yes. Yeah. Any, any opinionated thing, it gives you a, it gives you some guide rails

and like, you know, gives you rails. So yeah. And especially as you mentioned, when you're a

solo developer in a small team, you, you, you don't have the luxury of, um, making all those

little decisions. Um, so thank you so much for joining us. If listeners want to reach out to

what's the best way michael so twitter is probably the best way um at mike herman you can also reach

me via email at michael at testdriven.io great well thank you so much for taking the time and

it's been really educational to hear how you've built out test driven with django

yeah thanks for coming on the show yeah much appreciated thank you okay bye