Folks, it's not like the old days where there were just a couple of web frameworks for building applications with Python.
These days, there are so many web frameworks to choose from.
One of those is the Masonite web framework created by Joseph Mancusio.
Joseph is here today to tell us all about Masonite, what makes it special, its core value proposition for web developers, and much more.
This is Talk Python to Me, episode 233, recorded September 11th, 2019.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
Joe, welcome to Talk Python to Me.
Thank you. Thanks for having me.
Yeah, it's great to have you here.
I'm really excited to talk about Masonite and sort of do a quick survey and dive into these modern web frameworks.
That's going to be a lot of fun.
I think a thousand flowers are blooming these days on the Python web framework world.
We've had some stalwart web frameworks, primarily Flask and Django, but Pyramid and before then some others like TurboGears and whatnot.
But those all have been around for a really long time and slowly growing or, you know, really slowly maturing.
And I feel just like every month there's a new interesting framework.
Yeah, yeah. I think that's exactly right.
And when I started Masonite, I thought I was doing really, really good.
And then I guess it's because I got into the ecosystem.
And then all of a sudden I saw like a whole bunch of other frameworks start like blossoming from that.
And it's probably because I just wasn't, you know, in it, in the ecosystem more.
So I just saw it more.
But yeah, there's, it seems like every, every couple of months there's something new coming up.
Yeah.
It's really positive, I think, but also creates some confusion.
We'll talk about that in a bit.
Before we get to it, though, let's start with your story.
How'd you get into programming and into Python?
I always never know which story to tell, like the long story or the short story.
But the medium story, I guess, would be that in high school, in ninth grade, I got kicked out of school for a bunch of stuff, like fighting and stuff like that.
I was a bad kid.
And I had, I was homeschooled for like eight months after that until the next school year.
And I was very, very bored.
And I didn't really know what to do.
And at the time, when I was 14, I was actually into Pokemon too.
So I was like, you know what, I'm gonna, like, I'm gonna just play this Pokemon game.
And then I got into, and I wanted to like build websites too, because I had a lot of time on my hands.
So then I got this website, you know, I started learning like C and then like C++, and I didn't really like it.
And then I was like, you know what, I'm gonna start trying to develop websites, maybe.
And then I got into PHP, because I found really good documentation.
I mean, good YouTube tutorials about PHP.
Yeah, and it seems like PHP is like a real quick and easy way into web development.
Like a lot of folks go that route, and they kind of, I don't know, graduate to like more formal languages.
Python.
Yeah.
Intermediate level, I guess there.
Formal languages.
Yeah, sure.
Yeah, so I got into PHP, and I watched, you know, the new Boston.
I don't know if you've ever seen so many tutorials.
Yeah, right.
They did a ton of tutorials and stuff.
I haven't seen a lot of stuff from them lately.
But yeah, they were on all over YouTube for a while, weren't they?
He hasn't made a video in like four years.
He sort of just dove off to 50,000.
But at the time, he was huge.
He only had like maybe 40,000, 50,000 subscribers, I think, at the time.
And now he's probably at like three or four million.
But yeah, I went from there.
And then I took sort of this Pokemon thing.
And then I used that as my base of a project to build like this website.
And then I built, you know, this website.
And I had people on Tumblr, I think it was at the time, like start using it.
And I thought it was like amazing that you could build something and have people use it.
It was like, it was crazy.
So I got into PHP.
And then from there, I really just took off PHP.
Like from like ninth grade to when I graduated high school, you know, 18 years old, I just coded nonstop.
I didn't do any homework.
I didn't do anything else besides like go to school, come home, and then just start coding.
Oh, that's pretty cool.
Like it was just your deep passion, huh?
Yeah, it just clicked.
And I had like this entrepreneurial spirit.
And I realized that I can create these websites and sort of make money from them.
I can monetize them.
I can put ads on them.
Did you have friends who were working, like making like $4 an hour minimum wage?
And you're like, you know what I'm doing?
Yes, I cut them checks.
I cut them checks for like $1.25.
And I gave it to them in class.
Yeah.
How'd you know that?
Did you, I feel like.
No, no, no.
I just mean like they had other jobs, like minimum wage jobs.
Oh, yeah, yeah, yeah, yeah.
And you had like these businesses making real money.
Yeah, yeah.
I didn't know they were actually working for you directly.
But I imagine that you probably in high school had, like I had friends.
And even for a while, I worked at like a pizza place.
I think I made like $3.25 an hour, right?
It was the minimum I could be paid, you know, to go there.
And I mean, eventually I went and did some other really wild stuff that is like super funny and
outrageous and not probably, it'll be too much of a diversion to cover now.
But it's just really funny to probably contrast like you and like high school building these
sites, you know, running interesting things and folks going, well, you know, I'm bagging
groceries.
Now there's anything wrong with that, but it's quite the contrast.
Yeah.
That's so true.
Even my stepbrother now, he does like marketing or something for like, you know, a big like
a corporate guy.
And he's like, dude, he's like, I wish when you were in the other room, just coding nonstop.
He's like, I wish I like, I did it with you.
And like, we learned coding together.
He goes now, because now you're, you know, you're off doing this job, doing this great big
project that you're, you know, your job.
And he's like, I'm sort of sitting here like at a cubicle, you know, like just banging
paperwork.
You really got into it.
It sounds like you just really independently went after PHP and Belize sites and that's,
that's super cool.
So where'd Python come from?
When I was 18, I joined the army and I came back and I was still sort of doing programming
within the army because it was, you know, it's a passion of mine.
It's a hobby.
And then when I got out, I wanted to build a POS ordering system that you see like a, like
a kiosk almost like a pizza place.
So I wanted to build that.
So I wanted to learn something new and do it.
So I picked up Python just because it was just something new.
It was cool.
They seemed to be rising at the time with like the whole data science thing and machine learning.
So I thought it was cool to sort of pick it up.
And then from there I built, I needed to pick a framework and the obvious one at the time
seemed to be Django.
So I picked up Python for about a month.
I learned on like Code Academy.
I did like all the basics and then I picked up a framework and then I started building this
thing out.
It took me about probably eight months or so to build this thing.
And then I actually said, all right, you know, I'm going to start trying to sell this
thing.
In hindsight, it was actually crap.
But at the time I thought it was super cool and I wanted to create a company.
And one of my all time goals in life is to have a 100 person software development company.
Yeah, that's a good goal.
I put that in the same ballpark as like...
It's nice.
It's concrete.
Yeah.
It was like Gary Vaynerchuk's like want to buy the jets sort of thing.
So I sort of put it there.
Like it probably never happened.
Even if you look at like Basecamp, like even they have like a couple dozen employees,
I think.
And they're like a huge company.
So like a hundred person software development company is gigantic.
But anyway, I digress.
So I built this thing and I even went like door to door to like businesses to try to sell
this thing.
What was that experience like?
Were they receptive?
Were they just like, what are you doing here?
Like you're from the internet.
Why are you in my place, my pizza place or whatever?
That's exactly what it was.
But actually my whole philosophy is that I'm really not afraid to fail.
And even if I fail, I learned something from it.
And it was super nerve wracking to like walk in, just cold walk into a business.
But I figured like even if I fail, like I'll probably learn something from this guy.
And what I actually learned, which was interesting is that when I went in and I asked them if they,
if you know, is your manager there?
I tried to like, I had like a whole pitch like lined out.
And they basically said that, oh no, sorry, we've already tried some and it just, it just
doesn't fit us.
And I thought that was interesting because I was walking into companies that didn't have
it, you know, online, but it makes sense that they've probably been around for five,
10 years.
And if they don't have one, they had to have tried one already.
So I use that failure to sort of repitch into, oh, I know you've tried something before,
but maybe you should try this instead.
I see.
It didn't work before.
And here's why it's going to work this time.
Right.
And something like that.
But nobody really went for it.
And I'm not really a sales guy.
I'm very introverted sometimes.
I call myself an ambivert.
So I'm like, I'm sort of introverted, but I'm extroverted in comfortable environments.
Right.
If that makes sense.
I think that describes a lot of tech people, honestly.
Yeah.
That's probably true.
I think this is the start with most people in general.
I mean, very few people I think that I've, I've experienced are really introverted.
Like once you get familiar with them and they get comfortable with you,
they're just like off the wall.
Yeah, for sure.
This is a really cool way to get into Python.
And where did you go from there?
So from there, I learned a, I wanted to learn a new technology.
Each year I try to make it a theme.
That year I wanted to learn frameworks.
So I learned like Django and Python.
And then I wanted to, I already came from PHP.
So I wanted to learn Laravel because I never learned Laravel all the time.
So then I created a new site.
You know, us, we just have a bunch of side projects that we try to create businesses out
of.
I created a new side project, which was basically like a textbook rental service.
Okay.
And I built like a whole business model out of it and how I was going to do it.
And then I built the site in Laravel and I used like Google API and all that stuff to
try to build this thing out.
And I actually really liked Laravel.
And then from there, I worked with Laravel more and more.
And then finally I got a job locally working with Laravel at the company I work with now.
And that's what I do right now.
What are you doing day to day?
What kind of work?
Sounds like more web development.
I continue web development right now.
Day to day, I work for a wholesale military supply company.
It's actually a pretty big company.
It's like 150 person company.
The web team is probably about like six strong.
And we run this basically this multimillion dollar website that does all the wholesale
processing and all that.
I also am in charge of a four person software development team that we're working on a large
scale ERP project to basically run this whole company.
Yeah, cool.
So I'm taking a lot of those concepts and trying to come home, apply them to Masonite.
Yeah.
Excellent.
All right.
Yeah.
So let's dig into the Python web frameworks.
So speaking of Masonite, if you go look at the usage stats, we've got
40% Django, 40% Flask, plus or minus a couple in there.
A little bit down from there, we've got like Pyramid.
I think it's like 6% was the last usage I saw there.
You know, that rounds out a significant portion of what is Python and web frameworks.
But like we talked at the opening, it used to be, well, Flask, Django, which are you?
It's kind of was the greeting or whatever amongst the Python web developers, right?
The last two or three years, there have been so many different frameworks.
We have Jepronto, Sanic, Vibora, Starlet, FastAPI, Hug, Falcon.
It's not even a super clear connection.
API Star, for example.
So there's Starlette and there's FastAPI.
FastAPI?
Which one?
I think there's a handful of websites that actually use Starlette underneath.
I think Responder from Kenneth Wright, for example, is one of those.
So there's just, there's like this layering on of what people's different ideas of the Python
web world should look like.
And how would you summarize that?
You know, is that looking at trying to make type hints do interesting things?
Is that async?
What are the trends that you're seeing in all of those or, you know, kind of in general there?
So this is mildly controversial.
And I actually argue a lot with like the people inside the community.
Well, not argue, but, you know, debate a lot with people inside the community of the correct
answer is that the trend is moving towards asynchronous frameworks itself.
Like the actual framework code is built around some kind of ASBee server or asynchronous server.
That's the trend.
I'm not entirely sure I agree with the trend because I feel like it forces a lot of people
that are new to all of this to sort of see the trend and sort of prematurely optimize their
application.
So if their application is like a blog framework, for example, they're like, yeah, this blog framework,
I mean, sorry, this blog application can handle 15,000 requests per second.
But like, does it need to?
Does it really need to do that?
Like, I mean, that is really cool.
And especially if you try to like load balance across two of these applications, like you can
handle like thousands and thousands of requests per second.
But I feel like it's more of a premature optimization.
Like if you want to use and then when they when they use these frameworks, like a lot of times
they have to start writing their code with the idea of it being also asynchronous as well.
Like, you know, thread safe, I believe in this and all that stuff.
And they can't just take any any ORM off the shelf.
They have to use like an asynchronous compatible ORM.
It basically narrows down a lot of your your decision making.
And I'm not entirely sure if you need to create an API or something, some kind of small microservice,
just hit API endpoints, get information from a database.
That's 100% the way to go.
You need if you're creating a bunch of microservices, maybe for one monolithic application,
then that's 100% the way to go.
But that's not the way I like to create my applications.
Right.
Yeah.
So most people just want to create, you know, like a service like a like a SAS or something.
It's an interesting point that you bring up.
I would certainly say that there's a trend to see what the cool hot frameworks are doing
or what the amazing web companies are doing and try to emulate those way too early.
Right.
You know, you talked about these websites that you were creating.
Like when you're, let's say you're creating your, if you're creating your, your textbook rental
company, you know, you're playing it like, well, we're going to have all the campuses around
America in September.
They're all going back to school and getting their books.
It's going to be crazy.
And there's going to be all these orders.
And it's just, you know, and the reality is probably one campus.
If you were lucky joins in and it starts, you know, like it starts real slow.
Right.
And you've got all the, all the time in the world to see the analytics to, you know, you
scale your web server potentially, if you even have to like a standard web app, it can
take millions, millions of data-driven requests per month on like a $10 server before you have
to start worrying about all that stuff.
It's definitely true that you can just not worry about it for a good long while.
I mean, if you build your app poorly and it's super slow, then you're going to want those
features more.
Right.
But if you build it well, write indexes on your database and things like that, it should,
it should fly.
And it should be able to go quite a long ways until you have to worry about that.
That certainly seems like a reasonable philosophy to me.
The other one is, you know, I do training and write courses and do other presentations to
helping people learn things like web programming.
And it's super overwhelming.
As you know, I mean, you learned when you're young, so maybe it didn't feel as overwhelming.
You just like, you just like, this is how computers are.
This is what I do.
Right.
That's probably, that's probably right.
But there's HTML, there's CSS, there's databases, there's query syntax, there's Python, there's
the templating language, there's Linux, there's deployment.
I mean, there's just so many things, right?
And if you say, oh, by the way, why are you trying to learn all this for the first time?
You know, you need to learn asynchronous programming too.
So don't forget about that.
I mean, that's a tricky level.
I feel like certainly that's, it's a really great thing to have for a web framework, but
it is not necessarily a great starting point.
Right.
Yeah.
And that's what I would say on that.
tool that you should reach for if you need it.
But it's not something that you should default to just because it handles more requests per
second.
That's my take on it.
Cool.
Yeah.
So I do see like quite a number of those that I mentioned, like Starlette and Sanic and whatnot,
focusing FastAPI or whatever, focusing on this async aspect.
But another aspect that I see being used a lot is things like type annotations and some of the other Python 3 features to try to make some of those features help with the web framework, for example.
Does Masonite do any of that?
We'll probably talk about this when we get into the Masonite part.
Masonite has something called an inversion of control container, an IOC container or a service container, which utilizes type hints.
And the short answer, and we'll do the long answer later.
The short answer is basically in the controller code and the controller method, you can type hint a class and Masonite will inject that class for you.
Right.
So like this controller takes a database derived class or whatever, and then you say that as a type hint, and then the IOC container will like push that in for you.
Exactly right.
Yeah.
If you do like a sort of like a base class or something.
So if it's an instance of a database base class, then inject the base class or the database driver that you have defaulted or something like that.
Right.
What if you've registered?
Yeah.
Okay, cool.
Yeah.
So I think this is kind of unique and new that so many of these like last couple of years frameworks have really tried to embrace Python 3, right?
Like Python 3 has been a struggle for Flask.
They're not there anymore.
But like for a while, they had a statement saying basically, we don't work on Python 3.
Well, we probably work on Python 3, but we don't guarantee it.
Something to that effect.
Like four years ago or something like that's pretty rough statement given, you know, the date that it was.
And then, you know, Django as well, just and 2.0 drop support for Python 2.
So, you know, they've been kind of carrying that baggage around.
They can't do things like this with their API, right?
If you fundamentally said you must have type-ins, well, you know, there goes your Python 2 support, right?
Straight away.
So all these new ones, though, they seem to be coming along with like a fresh look.
So I think that's pretty cool.
Masonite, I noticed that a lot.
So like it's pretty hard to support multiple versions of Python that don't work well with each other.
So like, for example, 2.7 and 3.4, for example, to support both of those.
So what I wanted to do with Masonite was one, yeah, start with Python 3, but also only default to the latest four versions of Python.
So currently we support 3.4567 and 8's coming out soon.
And so far the tests work for 8, so that's good.
But when 8 comes out, we're going to drop support for 3.4.
Yeah, that seems reasonable.
Yeah, my philosophy basically is if you really need to create something in 3.4, then you're going to have to use Masonite 2.2.
And if you want to use the latest, this way we can sort of keep up with the trends as it goes on.
Yeah, well, for the moment, Python is released on an 18-month release cycle.
So that gives you like six years of backwards compatibility.
That should be enough.
Right, exactly.
That should be enough, I would think.
There's actually a PEP out, I forget the number, by Lucas Lange, to move to yearly releases.
But that would still be four years.
That should be good.
Yeah, yeah, definitely.
This portion of Talk Python to me is brought to you by Linode.
Are you looking for hosting that's fast, simple, and incredibly affordable?
Well, look past that bookstore and check out Linode at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Plans start at just $5 a month for a dedicated server with a gig of RAM.
They have 10 data centers across the globe, so no matter where you are or where your users are, there's a data center for you.
Whether you want to run a Python web app, host a private Git server, or just a file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24-7 friendly support, even on holidays, and a seven-day money-back guarantee.
Need a little help with your infrastructure?
They even offer professional services to help you with architecture, migrations, and more.
Do you want a dedicated server for free for the next four months?
Just visit talkpython.fm/Linode.
I'm really excited about all these web frameworks, Mason and I included.
However, I have this new problem, right?
I could go and look and see Flash Django Pyramid.
Let me compare those and sort of see the things I like or don't like about them.
And then I can look at history and say, well, it's probably this much supported, so it's probably going to be about that much market share in the future.
Flask is about 40%.
There's a good chance Flask is going to be around next year.
But I don't get that sense with these new frameworks, right?
Like, Responder was cool.
I don't know if anything has even been done with Responder in the last, you know, little bit, right?
It seemed like not a whole lot had been going on with it.
It took off in like the first like two months and then it sort of died out.
Exactly.
I mean, it is super cool and it's great that people are working with it.
But how do you think about going through these frameworks?
I mean, obviously, you're just working on Masonite.
So you're just, you know, going forward and keeping things going.
But what would you say to people out there about how they should consider the stability of one of these projects?
Is this like a super cool one month idea or is this an actual thing?
Masonite itself?
Oh, yeah.
It's definitely an actual thing.
I always sort of think about what Masonite is going to like.
Masonite is really, really cool now.
But what is it going to look like in five years?
Like, what is that Masonite going to look like?
And I sort of work towards what that's going to look like.
And then maybe in five years, I'll look for another five years and do the same thing.
But basically, what I really like about the PHP ecosystem is that a lot of the time, these frameworks, like if you look at Symphony or Laravel, there's faces to them.
There's people that you can, there's like leaders, you know, like even Django is sort of like, I don't know if it's just me, but it's sort of like this nameless, faceless organization type thing that like, like maybe like this Marvel type organization that like controls like Django.
Like, I think it has like a committee and stuff, but there's not like one specific person that I know, like, oh, they own it or something like that.
And like with Laravel, like the guy, Taylor Outwell, you know, he's all about Laravel and, you know, he works on it full time, obviously.
But I can look at him and I could look at his future and tell the future of Laravel.
So like me personally, like Masonite is going to be around for like a super, super long time.
It's, this is basically, Masonite is going to turn into my side project that turns into like, you know, that business.
Like for example, maybe that text, what that textbook rental service might've turned into.
That's going to be what Masonite is.
So, you know, once Masonite becomes profitable, either through sponsorships or partnerships or basically SaaS is around it, it'll just take off from there.
But I mean, Masonite is going to be around for super long time.
That's awesome.
One of the metrics I use is when I go to these projects, obviously I look at how many stars does it have, but also, you know, maybe when was the last commit?
Is that three years ago or is that two days ago or an hour ago, right?
Like, what does that look like?
The other one is, probably the biggest one for me is open PRs that are not being addressed or barely are being addressed.
That seems like a real big red flag to me, right?
If you go there and there's like five people who have put a bunch of work in to add some new features and they're just, all you got to do is just verify this is all right.
And then just accept it and the people running the project can't even be bothered to respond to it.
As a contributor, that's a crappy feeling, but also that's not a super good sign for the project, I don't think.
That's right.
Yeah.
So the reason I bring this up is when I go to Masonite, there's zero open issues and there's zero open PRs, which is pretty cool.
So here's like the weird thing with Masonite and maybe in future versions, this will be different.
But Masonite is really broken up into two different repositories.
So there's the Masonite repo that everybody goes to and they see has a thousand stars, but like people talked me into, actually, did people talk me into this?
I'm not sure.
But at one point I extracted all of the framework itself logic out and I just created an application.
So people can basically, when people run their craft commands and they run craft new project and it creates this project down, it actually creates that, basically a copy of that repository down onto their computer.
But if you look at, if you go to the Masonite organization and you go to the core repository, you can see the actual core code.
That's the actual real code.
Okay.
Got it.
Yeah.
That's the actual, what's actually driving the Masonite application.
Basically the Masonite that you see on the one with a thousand stars is basically just a shell of Masonite that I took all the, basically the framework code out and I made it in its own repository.
And then I made that a package that the shell basically requires.
So I basically, what I really wanted to do was take out as much.
So when I first posted Masonite on Reddit, it was at like one version 1.3 and everybody hated it.
And they said it was crap and it was dumb.
You know, typical Reddit stuff.
But the weird thing is that they were right because the original version of Masonite was like a basically one function that like did everything.
So basically from there, I extracted all the logic out and I kept that repository up because I had so many stars already.
I had like a hundred at the time or something.
And I basically created a new package and tried to make it as modular as possible.
Yeah.
That makes a lot of sense.
That sounds cool.
Seems like there's at least activity on, you know, all the various items there, which is pretty cool.
Right.
It's not like three years ago.
There's a lot of activity over there.
Hanging out there.
That's good.
All right.
So maybe we could dig into some of the features of Masonite.
You talked a little bit about why you started it, but maybe give a little bit of clarity on that.
And then let's just talk about some of its major features.
Like why would people choose it over the other frameworks and what were some of the goals there?
So I needed a winter project because I was going, you know, in college.
So I went to recess.
I needed, you know, something to do because I'm home all day and programming is a passion.
I can't just sit home and not do anything.
So I need to code something and I didn't really have anything to do.
So, and I was going through my year of learning frameworks.
So I was like, you know what, let me learn how to, you know, build a framework.
And so I looked up, you know, how to build a Python framework because that would be cool because the Laravel, I mean, the PHP ecosystem seems, was seemed to be too hard of a competition to penetrate.
Yeah.
And I saw a lot of holes that I tried to fill with Masonite in the Python community.
So I thought it'd be good to build a Python framework.
And getting a WSGI server takes like maybe seven minutes to set up and running and getting some kind of response.
You're in some kind of dynamic response, which is probably why so many pop up.
Right.
So you're basically, there's like one function you implement.
There's, they pass you the request and you return the response or something along those lines.
Yeah, exactly.
Yeah.
It's just a, it's just a normal WSGI application that takes two variables and then you basically return.
You use one to set the headers and then the other one to return the response.
Super simple.
So from there, I basically had it up and running and I was like, okay, well, I'm coming from Laravel.
So I think it would probably be cool to write my routes in something I'm familiar with if I'm going to start building this framework because I don't want to learn something new even though I'm building it.
So I took what I'm familiar with and I made the routes look like the modern day routes that they are now.
And I added that feature in and I was like, oh, that's pretty cool.
I mean, I wonder if I could add like controller logic too.
Like that'd be, that'd be cool.
And so I added the controller logic and the methods and, you know, swapping between different methods and calling certain classes.
I was like, oh, that'd be cool.
And I was like, what if I had something like super awesome, like, like built-in email sending support?
So like I built that in and then I tried to build it all modular.
And I basically just went from there, like a little, little bit by a little bit.
I just kept on putting more and more features in until just like out of nowhere, people started joining the community and like contributing actually.
And we basically, we teamed up me and me and a couple of early adopters and we built into something really, really cool.
And then we released 2.0 on June of 2018, I think.
And then from there, it just shot up.
It went from like 80 stars to like 500 in like a couple of days.
Wow.
That's cool.
Yeah.
Featured in the right places.
A lot of people came to check it out, huh?
Yeah.
I basically, I think I put it on Reddit and it got like 20,000 views in like three days.
And it was on the top of our Python and it was on like Hacker News, I think.
And it got like a whole bunch of, you know, tweets and stuff like that and people talking about it.
And it basically shot up from there.
Yeah.
Super.
You started out this conversation by talking about routes and the routing mechanism and controllers.
So let's maybe dig into the code story around that a little bit.
Now, talking about code in audio format is kind of not the easiest thing to do.
But if we keep it simple enough, I think we can give people an idea.
So it looks like you have some pretty interesting ideas around creating routes.
And it looks like you are sort of embracing this HTTP verb type of world as well.
Right?
So if I'm going to create some routes, I would go and create a, I would import a get.
Is that a class that I'm creating?
Or is that a function I'm calling?
No, that's a class.
A class.
So I would create like a list of classes and I would say get like a forward slash.
And then I would say welcome controller at show.
So the welcome controller is a class that is handling this request and show is a method
within it.
Or maybe welcome controller is just a module.
I don't know.
You could name it and so on.
No, that's correct.
Yep.
Yeah.
So I can create these gets and posts and it seems like a really nice way to build up
from sort of naturally understanding HTTP verbs and the way the internet and websites actually
work.
Something early on in Mason, and really in my code in general, even when like I create my
method names, these method names are like, it seems like a whole sentence long.
Because I like when I read my code, I like to read it in English.
Like I like to read it from left to right as if I'm thinking it and I want to show it to
like a little kid almost and like have him understand it basically.
Like it's just reading.
It's like reading a book almost.
So originally it was actually normally it's get.
And then inside the get, you have the URL that you want to send to, like you said, and then
the controller method.
But previously it was actually get.route.
So when I read it, it was, I want to get route.
And then I pass in the URL and stuff like that.
And you can still do that actually.
But we basically shortened it down to, yeah, just a list of get routes, post routes, option
routes, put routes, delete routes, stuff like that.
That's super cool.
How do you pass variables in through the URL here?
So I don't see any examples of that.
Like if I do this show, I probably want to show like, you know, slash some blog post with
the URL or something like that.
Yep.
So in your URL, it would be, say you want to do like a slash blog post slash maybe one
or a two, or you want that to be a dynamic.
Sure.
That'd be, that'd be fine.
It would be slash dashboard.
And then you would do another slash and then an at symbol.
And then the name of the variable that you want to retrieve later.
So maybe it's blog ID.
So it would be blog underscore ID.
And then you'd put that there and then that's, that'll be the dynamic part.
Or you can add sort of what I call regex compilers, which is basically, maybe I only want that
to be an int.
So it would be at blog ID colon int int.
So it'll only match integers or I could do strings or I could do some kind of super complex
one where I do like a website.
And then I could actually pass a website in with slashes as well.
And it'll actually match that as well.
Yeah.
You can do a lot of complex things with it.
I love that, that simple way of doing constraints for types and stuff.
Yeah.
You create really nice things like on our website, you can say talkpython.fm/ two, three,
three, I think would be this episode, right?
If I got the number right.
And that would actually only match for integers and then it'll go look that up and take you
to the real location.
So it's like a really nice way to create short sort of CLI almost feels here.
Web app.
Yeah, exactly.
I try to write everything first.
So I actually, when I created the routing engine, I actually wrote down, I don't know,
piece of paper, every single variation I could possibly write for a routing engine.
And then I basically crossed out all the crappy ones that I thought looked ugly.
And I only went with the one that looked nice.
And then I worked backwards to the actual implementation.
Like I had no idea how I was going to create this thing.
But then I worked backwards to actually creating the class and creating all that stuff.
That's how I actually write almost everything.
I want to use it this way.
I don't really know how.
Right.
We're going to make this happen somehow.
That's cool.
The other thing that you have here is you have classes.
And the classes like capture the request object.
And then you have the methods that run for the view.
And I actually really like this pattern.
I use this pattern in some of my websites as well, even though I have to kind of fight
against the grain a tad bit to make it happen.
I really like it.
And you have the word controller.
Do you consider Masonite a model view controller framework, a model view template?
I don't really even understand why there's a distinction between those things.
But it seems to be in the Python space there is.
So I do consider Masonite an MVC.
But it's not.
I try to make it not constrained to just control logic.
So I try to sort of assist the developer who's working with Masonite to sort of take a lot
of that logic and add, you know, extract it into like maybe like a mail class, which is
ejected into the controller and stuff like that.
So it's not a strict MVC, but it does use basically the wording to sort of help you
structure your code.
I like that pattern.
It's cool.
You talked about the injection stuff and I do want to cover that.
That's fairly unique in the Python space.
But before we get there, so the way that I would, if I was a Masonite developer and I
was starting a new web app based on it, I would create a virtual environment and I would pip
install some stuff, Masonite and whatnot, right?
And then I would start issuing command line or CLI behavior commands to Masonite to help scaffold
build up and start building my app.
So you could say you have this utility called craft.
Tell us about craft and some of the commands and what's the story on that?
I think it's incredible, actually.
I think that's actually what makes or breaks the framework.
So craft commands.
So think of like Django, because a lot of your listeners are probably familiar with Django.
So in Django, you might have a class based view and you might have that, you know, return a couple of templates, maybe some kind of context and stuff like that.
And then you want to create another one.
We usually end up doing is you either maybe create a new file and then instead of creating the whole class, you probably sort of copy and paste that old one that you already created into the new one.
Yeah, certainly a copy and a paste is a solid start.
Yeah, exactly.
So what craft does is it gets rid of all of that boilerplate.
So in Masonite, if you want to create a new controller with, you know, a couple of imports and you want to import the request class, the view class, you want to create a method.
What you do is you do craft controller and the controller name.
So maybe craft controller blog.
And it'll actually create you a blog controller.
It imports the request class, it imports the view class.
It makes a default show method and it type hints the view class and it type hints the request class.
Like it creates all that boilerplate for you.
And it does the same thing.
Like if I want to create a middleware, craft controller middleware, it creates me a class, imports everything I need.
What's an example of middleware?
Like why would we, why would I create one of these things?
What does it do?
A middleware?
Yeah.
In the Masonite terminology.
So a middleware is basically a piece of functionality or code that runs in between the request class or in between the incoming request and your controller method.
So for example, maybe you want to have some kind of authentication.
So if the user is not logged in, I don't even want to hit the controller.
I just want to redirect to the login page.
So I might create that.
Or maybe I want to create some kind of after middleware.
Like I want to take the HTML response and maybe minify it and then return it.
Something like that.
So you create these middleware that run in between your controller, in between the incoming request in the controller, and then in between the controller and the final response.
And you sort of inject these things.
That's actually really, really simple to work with, with Masonite.
But yeah, you just use these craft commands.
You can create, you know, migrations.
You can create jobs.
You can create listeners and tasks.
And you create all these things, all this boilerplate.
So the objective really is that I don't want to focus on writing things that aren't crucial to my application.
So if I have a thought that says, all right, I need to start sending out an email.
Let me make a new controller or something like that.
I just create the controller and I go to the controller and I'm still focused on sending out my email.
I drop down to the method and I start coding, sending out my email.
Like I never break my train of thought with what I actually need to do to get my business logic set up.
That's cool.
And it seems like it follows some really nice conventions.
So for example, you said maybe we want to create a blog controller as a show method.
So you would say craft controller blog, but it actually creates the controller, a controller class called blog controller, not just blog.
It puts it in slash app slash HTTP slash controllers, and it initializes it all correctly, right?
It has an initializer, which has a type, you know, request object that has a type annotation of requests and things like that.
Yep, exactly.
This portion of Talk Python to Me is brought to you by Datadog.
Datadog is a monitoring and analytics platform that unifies metrics, logs, and distributed traces from your Python applications.
Datadog's tracing client auto instruments popular frameworks and libraries such as Django, Flask, PostgreSQL, and AsyncIO,
so you can quickly get deep visibility into your applications.
Trace requests across service boundaries, correlate traces with logs and metrics,
and plot your application architecture with the service map.
Get started today.
Sign up for a free trial at talkpython.fm/datadog, and Datadog will send you a free t-shirt.
Yeah, one of my pet peeves around some of these projects is they give you zero guidance about any organization.
And maybe even taking it farther, like sometimes they even accentuate their ability to not have any organization or any structure.
Like, look, you don't even need that.
Look, you don't even need one file.
Just like put it in this file, and you're good.
This is where it goes.
It all just goes in here.
And like, no, it doesn't all go in there.
You're going to have, you know, so many view files or controller files.
You have, you know, 50 templates.
Like, you need organization.
And this, like, selling the lack of it as simplification seems to me like pushing at least beginners down, like, the wrong path.
Right?
So I like that your craft commands take, like, a natural structure and just say, this is the convention we use, and we're just putting it here.
Right, exactly.
And like you said, it creates that file, and then it puts that controller in it.
But it's only that one class.
And that is opinionated.
That is the way I like to work, mainly because in my VS Code editor, if I need to go to my authentication middleware.
In order to do that, you know, I hit the command P thing, and I go to authentication middleware, and I click enter, and I go to that specific class, that specific method.
I'm not, like, going into, like, some kind of middleware.py file, scrolling down a couple hundred lines so I could find that middleware class or anything like that.
Yeah, yeah.
So it's just the way I code.
I just hop around files, you know, all day until my app is done.
Man, I'm with you.
I love it.
That's the way to do it.
Having, like, these huge long files with everything crammed in there, it just means it's so hard to find.
I think the choice of editor somewhat influences the granularity of, that you're comfortable with here.
But I'm kind of, it sounds like you and I would have a similar style.
Yeah, exactly.
Like, I feel like it's almost like when you give a kid, like, a guitar, and he grows up to be a rock star.
Like, whatever sound that guitar made is probably what kind of rock he's going to play, you know?
So, like, it's almost like that.
Like, whatever editor you use probably dictates what kind of applications you're going to build.
Right, right.
Something like VS Code is very natural at handling many directories, many files, and, like, seeking between them really quickly.
Right.
The other thing that you talked about when you talked about that flow there was injecting things.
Now, I definitely think dependency injection and the open-close principle and all those things have some really interesting places in the Python world.
But I also don't see them used very often.
So, this is kind of a unique aspect of it, of what you're doing.
But so, for example, like, if I've got my show method from my blog, and maybe in order to get my blog, I have to go to my database.
And I want to work with MongoDB.
So, somewhere previously at the app startup, I said, when I asked for a database, give me the MongoDB implementation of my repository thing or my database service or whatever I called it.
Right.
So, I can go to that view method and say, you know, like, show self, comma, view, colon, view, comma, DB, colon, repository or database class or database service.
And then I'll just automatically just start getting my database instance passed into me by Masonite.
Yep.
That's exactly right.
Or what you can really do, where Masonite really shines is being able to basically swap out what I call interfaces or contracts.
So, like one of the other principles, interface segregation principle, right, where you want to really code to an interface and not to a concretion.
Yeah, we can hit all the solid principles.
Right.
Yep.
So, what you can do is you can, Python doesn't have like an implements keyword or anything.
But if you have like a base class, say you have a, what would be a good example, like a payment base class, you can type in that.
Yeah, payment service, whatever.
Sure.
Right.
Yeah, payment service.
So, you type in payment service.
And even though you have no classes called payment service, it'll find an instance of payment service and return that as well.
Right.
Maybe you wrote a class called Stripe payment service and it drives from payment service and it actually talks to the Stripe API or something like that.
And it'll just find that and inject it.
Yeah, exactly.
And what's even better, I think, is that, and this might sound confusing to people who don't understand IOC, but what also it does is when it resolves that payment service class, it'll resolve whatever is in the initializer of the payment service class as well.
So, basically ties every single class that that payment service relies on, ties it all together, initializes everything, and then returns everything as an object already set.
So, you don't know longer do you have to sort of import a class, maybe get some config variables, maybe pass it in, construct that thing, and then pass that thing into something else that needs it.
Everything just ties together sort of seamlessly.
And then you can also swap out functionality as well.
That's really what powers an IOC container.
And the funny thing with Python and IOC is that even if you Google, why doesn't Python have an IOC implementation or something like that?
I forget the Google question.
But you go there and it says, you don't need an IOC container.
I think it's like because Python is like duct typed or something.
Like it was, it almost like made no sense.
Like, like that's not really the reason for an IOC or anything like that, or even for like interfaces or anything.
So, it was very strange.
But I think IOC is more of a architectural decision that just, you have to build applications.
Like we're building this large scale ERP system at work.
There's probably going to be a two-year long project, probably thousands and thousands of classes.
And like if you didn't have an IOC, like how do you manage all those dependencies between the classes?
Like it's crazy.
It gets tricky.
That's for sure.
I would say for sure that Python does not, as a general rule,
the people in the community and the libraries don't generally embrace IOC.
But yeah, I see it being really useful here.
So, that makes a lot of sense.
You know, like your payment service, your Stripe one also takes a logging framework or logging service.
And it takes a database service or something like that, right?
Like you just register them all and it all just, you just go to your view and say it takes a payment service
and you get the Stripe service all set up.
As long as they're all in the container, they all can communicate with each other.
That's cool.
And probably use that for testing as well, right?
Like you could swap out the database with like a mock database and the logging with like a null logger
that actually doesn't do anything or something like that.
Like prints.
Even Masonite itself is strictly based around this container.
So, if you want to change out the request class, for example,
and you want to make it a different request class, you could just do that.
And everything else will sort of follow.
As long as you follow the contract of the class,
you could just sort of swap every single piece of functionality out of Masonite and inject your own.
That's cool.
One of the challenges I've had when working with IOC is I'll be somewhere in the middle of the system
and I'll have all these dependencies that were put together by the IOC container.
And I'll be like, all right, I have no idea what actual database I have or what logging thing I have
or where it came from or any of that.
And I do see that as one of the drawbacks of IOC is it's kind of hard to see where it all gets started.
Yeah, I mean, I guess if you sort of lose yourself, then I guess you're sort of lost, I guess.
But as long as you have like a good file structure and you have like maybe good documentation on your project
and stuff like that, you can sort of, there are caveats, I'll admit.
But it's definitely a pretty good architecture.
Yeah.
One of the things I like about your craft commands is, you know, I'm a fan of things like cookie cutter.
And I think cookie cutter is a super way to get started, right?
Like the right way is not create an empty .py file and start typing it.
I don't think like, you know, I already talked about the structure, but there's also tons of static files.
There's just, there's a lot of stuff that would be nice if you could start farther from let's enter character one and get going, right?
And I think cookie cutter is a nice way to do that, right?
You could say, okay, I'm going to use, I'm going to create a flash project that's already using SQLAlchemy.
So it's got the requirements set up.
It's already got a database structure.
It's already got a connection string for SQLite database for getting started and, you know, that kind of stuff, right?
What falls apart with a lot of those systems is you get to run them once and that's it.
Right.
Like I have a super cool.
I was just about to say that.
Yeah.
I have a cool cookie cutter template that will actually generate the final code from this course I have called Python for Entrepreneurs.
And it's like super involved.
There's so much stuff going on and you can type in the name of your project and whatever and run the cookie cutter.
And it will just, boom, out drops this really well formed project that looks just like the final project of that course, but with your data in it, right?
The problem is that's great for getting my first controller or whatever is in there.
But if I want the second one, cookie cutter is not going to help me.
That's where copy and paste comes in, right?
It seems like with your craft commands, you can start out building pieces of your app and continue kind of adding to the app with that CLI.
What do you think?
Yeah, exactly.
I mean, every, when you're trying to reach for like a copy and paste, like you're wasting so much time.
And not only are you wasting time, but you're, now that you finally copied and pasted it, now you have to be like, all right, wait, what was I trying to do again?
Oh yeah, right.
Okay.
Yeah.
Sending email.
And then you sort of go back into sending email and it takes your mind off.
And it's just, it's just a massive like time suck.
And most people that use Masonite, I don't know about most people, but a lot of people that are in the Slack channel, they say, man, like I built this thing in Masonite in three days.
It would have taken me three weeks in Django.
So I actually get that a lot.
It sort of gets to the point where I almost expect it when someone comes from Django or something.
I just, I basically just wait for it.
And I think a lot of that is because all of that boilerplate code is done for you.
Like we already created controllers and if you need to create a job, you create a job, you add your logic and then you just add it to a queue.
Like it's takes five seconds.
Yeah.
It's huge.
Yeah.
That's cool.
So let's talk about some of the other things that you can make with these craft commands.
You just talked about jobs.
That sounds like an asynchronous thing.
Maybe kicking out to some kind of background worker process.
You talked about email before we've got views and templates and create templates.
So you've adopted the Jinja 2 template system.
Is that right?
Yes.
Yeah.
Do you have any other support like chameleon?
Hint, hint, chameleon?
I don't currently.
I know that one guy came to me and he said he wanted to write in pug.
I don't know if you ever heard of pug before.
No, I only know it as a dog.
Yeah, I think it's called, oh no, maybe I just kept on calling it pug, but maybe a pub or something.
But anyway, it's basically, it looks like a markdown type style.
And he wanted to write in that and it had a Jinja 2 extension.
And then from there, I basically added extension support for the views and stuff.
So you could write, you could basically write in any Jinja 2 extension language.
So it basically just compiles down into Jinja, I guess, and then gets rendered.
But as for swapping out that functionality for chameleon, it's possible.
But there's no documented way of doing it.
Sure.
But it definitely could be.
You could open an issue.
VRs are accepted, huh?
Yeah, of course.
Nice.
Background work.
Let's touch on that real quick.
That's not something every framework decides to take on for itself.
Yeah, definitely.
So a lot of the features of Masonite came by me needing it.
So basically, I'll basically add it to my application and then I'll try to extract it into a framework feature.
And one of the things I needed was sending an email and I wanted to send that asynchronously.
So I created the concept of queues and jobs.
So a job is basically just a normal, simple class that extends queueable.
And you can add your logic of sending an email.
Maybe it'll accept a parameter of an email.
And then you could take that job and then you could pass it into any queue driver that you want.
So if we want to run it asynchronously, we pass it in the asynchronous queue driver.
If we want to...
And then when I deployed to Heroku, I didn't want to run things asynchronously.
I wanted to run things through some kind of RabbitMQ server.
So I coded that driver.
And the cool thing is that in order to create a new driver, it's just a simple class that needs four methods.
And then you take that and you register it to the container and then you have that functionality.
So I created the AMQP driver, which is the protocol for RabbitMQ.
It took like maybe a night.
And then actually last night, I actually created a database driver as well.
So now you could take that same job, that email job, adds it to a database table.
You have a worker that you run as like a separate process, maybe on like a supervisor process, that will basically pull that database and then run the job.
And the cool thing about that is that you can actually delay queue jobs as well.
So you can delay it by 10 minutes.
Maybe after the user signs up, we'll send a welcome email in 10 minutes.
And then you add that and it'll basically, you know, wait 10 minutes and then it'll send the email out.
And that's the way I like to sort of counter the ASGII competition.
So, you know, going to the next page might take one second or a half a second.
But sending that email might take two seconds.
But if you send it to a queue job, you know, it only takes that half a second.
And then it'll just run in the background or in your queue server or something like that.
So I thought that was a really cool feature that I added in Masonite pretty early.
And I use it all the time.
That's cool.
Certainly, asynchronous queues and background work like that do solve a lot of the primary reasons that you need.
Some sort of direct async behavior.
I do think the database stuff, if you could have it as async, once you, and we talked about it not necessarily being a great place to start.
But once you get advanced, like it would be kind of cool.
But, you know, my sites don't have it either, right?
Like both my database access layer can't support it, nor does the framework support it.
And, you know, the thing is super, super fast.
Like, honestly, I don't understand why most websites that I work with are so crappy and slow.
Because I didn't work that hard to get mine to go fast.
Right.
It doesn't do that hard.
Anyway.
But I bet you if it was simple enough, like if you just had to create a job and then add it to the queue, which is already created for you, I bet you probably would do it.
Like creating some kind of queue background work, like a lot of Django projects probably don't.
I did end up creating this type of thing because certain types of operations might send thousands of emails on the click of a button.
And you can't wait for that to happen.
Right.
It's insane.
Right.
For example, if I like I have office hours for my courses that people can come, they take the course, they get the office hours for free.
A bunch of people signed up for those.
Right.
If I enter a new one, I can't just wait to send all those emails because it'll time out.
But other things like putting people on mailing lists.
Right.
They signed up for the site.
They said, OK, you can put me on your mailing list, but they don't need to wait for you to put them on the mail.
There's no outcome from that that they need anything from.
Right.
Exactly.
Right.
So that's a perfect example of some kind of background work.
And adding background work to Masonite literally takes about maybe 10 seconds of code once you get comfortable with it.
I tried to make every single thing as easy, as quick as possible, just to make it like this rapid application development tool that people reach for.
Yeah.
Cool.
One of the things that Django comes with is Django ORM.
And that's been really popular.
One of the things that Flask and Pyramid have eschewed, they've decided we're staying far away from, is defining a database access layer at all.
And it's like up to you.
Typically, the answer is go get Sequel Alchemy or something like Mongo Engine if you're going to talk to MongoDB or something else.
Right.
But it's up to you.
There's no guidance.
It sounds to me like with Masonite, you decided to bring along an ORM, an active record style one, which matches really well with Django ORM.
Right.
And its style, not so much with Sequel Alchemy, which is a unit of work type of one.
Why not just lean on Sequel Alchemy?
So again, it was what I wanted it to look like.
So I wanted the ORM to look like something I was comfortable with using.
And again, Masonite is sort of like a framework for me, right?
Like I knew I was going to use it.
I didn't want to build it for somebody else.
I used it.
So I built it in a way that I would like it.
And I came from Laravel, like I said.
And Laravel has something called an Eloquent ORM, which is another active record style.
And then I found Orator, which is pretty feature complete.
There's a couple of things that can be added to it.
And it was basically influenced by Eloquent.
So it was almost like perfect to bring in because it's super sleek.
You don't have to like do anything crazy.
Like getting all records is like the model name dot all.
That's it.
That's all you have to do.
Getting like where is like dot where.
And then, you know, you can maybe change some where's together.
To get the first record is, you know, dot first.
Like it's very, very sleek.
And I thought that was the same as Masonite's philosophy of doing something as quick as possible
to get what I need done.
And it also had the, what I wanted to do as well was the migrations.
So the migrations are really important.
So in Django, you have like these magic migrations that are basically, I don't even know how,
but they're somehow like taken from like model changes.
And it basically generates these things that run that you should like never edit because
that's probably bad.
And it's probably going to screw up something down the road.
Something will get out of sync.
Yeah.
In Laravel and in Orator, you want to do the migrations.
The migrations are much more explicit.
So what you're doing is you generate as this new migration and you, you know, add a couple
of table columns and there's like an up method and a down method.
And the down method just reverses what you did in the up method, which is usually defaulted
to like a sensible default, like dropping the table, which is usually what you need to do.
And that's what I wanted.
And then Orator also had that too.
So that saved like a whole lot of time.
So it just made sense to go with Orator and I used it and I integrated the migrations
process with it.
And I just really, really like Orator.
I think it's a really great ORM.
So then I just incorporated it and everybody else seems to like it.
So I guess something's good.
It looks pretty interesting.
I can certainly see how it goes with your philosophy of, you know, I wanted to look like this.
How do I make that happen?
Right.
It's a little bit, a little bit SQLAlchemy-esque in some ways, but not in others, right?
Like the way you define the model and the table names and stuff.
That's pretty cool.
One of the things I like about some of your philosophies or styles here is you could go
and say, get a user.
You could say user.find and pass a user ID and that'll give you back the user or maybe none,
right?
Yeah, it's nice and quick.
Or you could say user.find or fail and give the user ID and you either get one back or I'm
guessing you get an exception if that didn't work, right?
Yep.
Yeah.
So what I'm using, say SQLAlchemy, SQLAlchemy has a first and it has a one.
Which one of those?
He's going to throw an exception when it doesn't find it.
You know, I mean, probably one, but is one just the way I get the first one or is first
the way I get the first one?
You know what I mean?
There's just, it's just a little less.
It's very fluent.
Order is very fluent.
Obviously, once you get used to it, right?
First just gives you the first or none and so on.
But this name is super clear and I really like the style of find or fail.
Because like I said, like when I write my code, I didn't write order.
I'll admit it was already written for me, you know, written, almost written for me.
I felt like, but it reads like English and that's how I like to do it as well.
Yeah.
You also have an interesting way of setting up relationships with decorators and properties.
How does that work?
Oh yeah.
So I think this is, this is actually really cool.
So in order, if you have a user and in articles, a user has many articles and then in
article belongs to a user.
So what you can do is when you do like maybe user equals user.find1 and you get your user,
you could do user.articles.
And this is called a dynamic property.
Even though you created a method called articles and you decorated it with a has many relationship,
you fetch it by using this dynamic property.
Right.
It basically is similar to the app property syntax.
And it actually returns a collection of all the, all the articles.
Or what you could do is if maybe a user has one profile, which has one address, which has
one something else.
You could actually, when you fetch your user, you could do user.address.
Or user.profile.address.
And you could just keep on chaining these relationships.
And then eventually you get down to what you need.
Or what you do is you do user with profile address, something else.
And then you actually, what do you call eager load?
And that gets rid of the N plus one problem.
That's a big problem with ORMs.
And I think some people don't know what that is, what the N plus one problem is.
You want to take a shot at describing that for the audience?
Because personally, I am a huge fan of ORMs or in the manga world, ODMs for documents.
But these classes that map back to your data, I think it's a huge benefit.
But this is one of the problems that you need to be aware of.
And it can be one of the performance problems.
So maybe tell people about this N plus one problem in ORMs.
So let's say you get a list of 50 users.
And you want to loop through all those 50 users.
And you want to get the profile of each user, right?
Because that first one where you get the list, that's probably a single query, right?
Users.find state equals California or something like that, right?
And you get 50 results.
So there's your one.
There's your one in the N plus one.
Right.
I'll explain the problem first and then I'll explain the solution.
So the problem is if I loop through the user and I did user.profile, it's going to create
or it's going to fire a query for each time I use user.profile.
And it's going to fire a query.
So that's where the N comes in because you're looping through all 50.
Now you have 50 plus one queries.
And now you have 51 queries.
Probably slow to do that, right?
It's probably not good to do 51 queries when you could do one.
Right.
So what you do is you do user with profile find one and that eager loads, which called.
So that's two queries.
And what that does is it gets the user ID and then it does a where in on the other table.
And it basically saves that information basically in memory on that object.
So now whenever I do user.address, I already loaded that information.
So I just fetch it from some kind of dictionary or something or some kind of collection saved
on that user object.
So now it's only ever two queries that I'm doing it.
So it gets rid of that N plus one problem.
Yeah, that's perfect.
And it's super easy to tell if you just turn on logging, right?
You could tell you have an N plus one problem because you're like, whoa, why is, if you turn
on logging to like every time you do a query, you show me what's happening going to the
database, you're like, I hit this one page and there's like 20 queries.
Why this should be one or two?
What is happening, right?
That's probably an N plus one problem.
Yeah, I've gotten about 750 queries down to like 13 or something like that using like the
with statements.
Yeah, it's pretty crazy.
That's pretty sweet.
All right, Joe, I think we're getting long on time here, but this has been really fun.
It's clearly an opinionated framework, but I also like that you can use these craft
commands to kind of bring in bits and pieces as you want to or not.
That's cool.
Yeah, thank you.
Yeah, you bet.
All right.
So let me just ask you one really quick question, I guess, around the project itself before we
move off of it.
So are you looking for contributors?
People do like take it for a run?
People to add issues, add PRs?
Where's it at?
Yeah, I mean, we're looking for contributors all the time.
I mean, you could be a contributor by joining the Slack channel and saying like, hey, you
should have this feature.
And then I'll probably, you know, either code it that night or maybe a couple days later or
that weekend.
That's even contributing.
I mean, you didn't code, but you still contributed towards the development of the framework.
And Masonite's in a really unique position because it sort of is opinionated and it is
a Python framework.
So it has a lot of people coming in from different ecosystems.
Like people feel really comfortable coming from Ruby.
People feel really comfortable coming from Laravel.
People love it coming from Django.
So when they come in, they have all these like really, really unique ideas.
So if you're not even in the Python community, I mean, that's, I think that's even better coming
in because you're coming with fresh ideas that maybe people from the Python community don't
have yet or haven't seen.
So yeah, just joining the Slack channel is huge to come in.
If you know how to code or you go to a Python, that's great too.
Yeah, that's cool.
How old is Masonite?
So Masonite was developed, it started December of 2017.
And then in six months later, we came out with the main release, which was June of 2018.
So it's probably about, what is that?
Probably really only a year and a half old is really when it really started kicking off.
Cool.
The reason I ask is a lot of these other web projects in the Python space are very old,
right?
They, they've been around since 2005 or 2008 or something like that.
And as a contributor, if you want to participate in that, you're walking up to a highly polished,
careful, delicate balance of features and things and so many people depending upon it.
And if you want to make a change, it can be really hard to do minor things, right?
So these newer frameworks, I feel are maybe better opportunities for folks to contribute
because it's somewhat newer, right?
And it's a little more dynamic and flexible and it's not so set in stone.
Yeah, I think that's exactly right.
And even the Masonite code in general is super, super clean.
Almost every single method is, has doc strings that explain and where each variable comes from
and stuff like that.
So it's really, really easy to contribute.
And since it's fairly new, although it has like a crap ton of features and people actually like are really,
really impressed that it's only, you know, a year and a half old and it has dozens and dozens of features.
There's a lot of easy picking still that can be coded up.
So there's even in the issues, I usually put good first issue or I list a difficulty, easy, medium, hard.
I haven't done that actually with the latest issues, but normally I do that.
So if you want to hop in and see what kind of difficulty you're at and then go there.
Yeah, you can decide, oh, actually, this might be more than I want to spend to get started in this.
The other thing that is interesting and I noticed about your project is you're participating in the GitHub sponsor program.
I don't know if that's the right name for it, but it's something to that effect where folks can contribute through GitHub to Masonite, right?
Tell people about that.
So I think with that button that you see, that little sponsor button, it's really, I think it is called the GitHub sponsor button,
but it's really just a list of other links.
It's really just a button and then you could post links to like a Patreon or some kind of like patronage service.
So it's not anything crazy, but if you click on it, it'll show you the link to the Patreon page where you can either sign up to be a contributor.
If you're a company and you want to sponsor, the documentation page gets, I think, around 10,000 page views a month.
So if you want to go there, it's always good to contribute there as well.
Very cool.
All right.
Well, let me ask you the two questions before I let you get out of here.
Now, I think astute listeners will already know the answer to this question, but that's okay.
I think we kind of touched on it already.
But if you're going to write some Python code, what editor do you use?
VS Code.
Yeah.
That's a good one.
That's definitely got a lot of momentum behind it right now.
Yeah.
And then notable PyPI package that maybe you ran across or maybe Masonite depends upon.
You're like, this thing is awesome.
It doesn't get enough attention.
Maybe tell people about something like that.
Like, first of all, just to get out of the way, you can pip install Masonite as a thing, right?
Yeah.
So there's one notable package.
Can I say my own package?
Like a different package that I created?
If you want.
Something that I created as sort of an extension is called Masonite validation.
I needed, again, something extremely simple to create.
So to create validation.
And I didn't really see anything that was simple.
I saw like, I think something's called pillow or marshmallow or something.
It just wasn't what I wanted.
So I created this validation package.
And you could see it in the Masonite organization on GitHub that you could bring in.
And it's not just for Masonite.
It's for any, it's for Django or Slack or anything.
So you could pull it in.
It'll only pull in the validation part of Masonite.
And you can validate dictionaries.
You could validate multidimensional dictionaries.
You validate, you know, JSON responses and stuff.
It's a really, really cool package.
Okay.
That sounds really nice.
All right.
Final call to action.
People are maybe interested in checking out Masonite, interested in getting started.
What would you tell them?
So if you go to the main GitHub page, GitHub slash Masonite framework slash Masonite, you'll
see a link to the Slack channel.
Yeah.
And I'll link to that in the show notes as well.
Yeah.
I'll link that in the show notes.
Yeah.
The Slack channel, which is, I'm really, really responsive.
It's about, it's almost 350 people in that Slack channel so far.
Everybody's really, really friendly.
So you can join there.
And then on Twitter, at Masonite Project, I post news and tips and tricks and stuff like
that on Twitter as well.
So if you want to learn Masonite on Twitter, then you can join there.
All right.
Well, it looks like a cool framework and it has a really unique way of working with it,
I think.
And yeah, congrats on it.
Yeah.
Thank you.
You bet.
Thanks for being on the show.
This has been another episode of Talk Python to Me.
Our guest on this episode was Joseph Mancusio.
And it's been brought to you by Linode and Datadog.
Linode is your go-to hosting for whatever you're building with Python.
Get four months free at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Datadog gives you visibility into the whole system running your code.
Visit talkpython.fm/Datadog and see what you've been missing.
They'll throw in a free t-shirt.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into
all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our
Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Thank you.