219: Building Django Apps & SaaS Pegasus - Cory Zue
47:44 Share

today on python test um i have asked cory zoo to be on the show and i'm excited i'm super excited actually i'm like totally stoked because um cory has done he's a django like guru and has done a project called sas pegasus hopefully i'm hoping that sas pegasus will help me get a sas project off the ground so um we're gonna talk some django

Welcome to Test & Code. This episode is brought to you by HelloPyTest, the new fastest way to learn PyTest, and by the PythonTest community. Find out more at courses.pythontest.com. Thank you, Corey, for being on the show. Yeah, absolutely. And I'm also hoping it helps you get a project off the ground. I wouldn't necessarily describe myself as a guru, especially compared to some of your past guests, but I've been using Django for a very long time. So how long? How long have you been using Django?

Oh, jeez. I mean, pre-1.0, I'd have to look it up on the calendar, but it's probably somewhere between 12 and 15 years at this point.

OK, well, I just looked it up, and the thing is only 18 years old. So I think that counts as a long time. Yeah, yeah. But I've never committed code to Django itself, I guess. I'm a big power user of Django. I love Django the framework. I know how to use most of it.

I'm not in the internals, I guess. I guess you're way more humble than I am because I am a power user of PyTest, but I definitely consider myself an expert. Yeah. Well, you did write a book about it, did you not? I think that probably qualifies you. Okay, but you have one of the very few. What do you call what Pegasus is? Yeah, there's a bunch of...

Yeah, there's a bunch of names for them. I think the common ones are boilerplate or starter kit. But essentially, it's a product that you can use to start a Django code base with a ton of other stuff built in. So not just your stock Django application, but a Django application that's all set up and ready to build your app on top of. OK.

Well, I know we want to let I'm just let's just talk about that for a second. So it's a project that you you have as a as a is this your full time thing or do is this a side project for you? It's a full time. It's basically my full time job right now. So I I run a portfolio of sort of indie projects, I would say. I started doing that on the side about six or seven years ago.

And Pegasus was my third attempt and the one that has sort of grown enough to be able to work on it full time. So I had two other small Django projects. Are your other projects still going?

They are, yeah. So the first one I did was a-- I always feel a little sheepish when I talk about it, but it's a wedding place card generator. So basically, you upload a CSV file, and it will generate a PDF file for you that is formatted so that you can print it and cut it up and make little place cards for the table settings at a wedding or at an event or something like that. It's a very simple application, but it actually

Yeah, it actually made reasonable amounts of money and was kind of my foray into this sort of indie products world. I think that's great. I think small, that's kind of what I'm trying to target is a small focused thing. Yeah. Just, I'm a software person. I should be able to write some software that might help some people out. Right? 100%.

and get paid for it maybe. Yeah. Does your place card holder thing still running? Does it still making a little money? It is. Yeah. It's, it's, uh, it's called place card me. It's, it's just cause I got the dot me domain. So it's like this card dot me. And, uh, yeah, it does. It makes, you know, maybe like a thousand dollars a month, which is nice. Nice.

Not bad. It runs completely on autopilot, which is quite nice. Every once in a while, I get an email from someone saying, oh, can I add meals to this thing? Why isn't this emoji working or something? But more or less, I never have to touch it. And it's just running in the background. So it was a sweet taste of, oh, you can just make money passively while you're sleeping. This is really cool. And then I got the bug and decided to try to figure out how to do that full time.

So my thought process was I could make some extra money by writing a book. And that's a lot of work, actually. It is. Anyway. OK. And it's mostly kind of front-loaded, I guess, right? My understanding with books is there's a big sort of marketing promotion thing that happens sort of right at the book launch, and then a long tail. Is that right? Yeah.

Yeah. And with tech books, there's a long tail and a steep cliff at the end. Um, um, I think, uh, I don't know. The, uh, I, I think I've been fairly, I think the, the pie test book has been fairly good, but it's still, um, uh,

the first couple of revenue checks come in and I'm like, Oh sweet, this is going to be awesome. If this keeps up, it doesn't keep up very long. Yeah. And at least it hasn't for me. It's been, it's been steady and it's been steady enough that I will keep it up. That's why I rewrote it and I rewrote it with the intent of making sure that it was, it wouldn't go out of date fairly fast and then it would, I could be able to keep it up and it does reasonably well. But,

That's not like I can quit my day job or anything. Okay, so that was number one. What was number two? Number two, well, let's see. So I made a bunch of apps that sort of were just to scratch my own itch, most of which never even had a way to monetize. One of those was like this...

this another kind of silly one where um i had some group chats with my friends and i wanted to see analytics on top of it like i was just curious kind of like who's sending the most messages and all this stuff so i built this again a very silly little django app to show you some of this data and just send it out to my friends they thought it was funny and and we had a good laugh about it and then i was like well maybe other people would be interested in this so i posted it on

like Reddit and a few other random places. And then just a small number of people, again, just sort of started using it. And I needed to ingest a bunch of data. So then I was like, OK, well, if you're ingesting half a million messages, then I should probably charge you something for that. So then I just added a little $10 a year.

thing to that. And then so that one also kind of runs by itself and I never really think about it, but it doesn't make much money. It makes like a hundred bucks a month or something like that. And then after having done a handful of these things and then copy pasting the code from user accounts and setting up my front end build pipeline and blah, blah, blah. I was like, oh,

I keep doing this again. Maybe there's a product in here to help other people launch all these Django apps the same way that I'm trying to launch all these Django apps. And that was kind of the birth of SAS Pegasus. And I should say, it wasn't a novel idea. These boilerplates existed for other frameworks. There was one, a very popular one, for--

Laravel, and there were a couple for Rails, and I looked for Django, and there was just nothing that was any good. I was like, okay, there's definitely an opportunity here. Well, and I've heard from, I guess, people I trust in the Django community that it's well-respected, even by some of the Django people. So that's good. Yeah, I was definitely the first, and

Obviously, in my opinion, it's still sort of the best and maybe by a good distance. Again, keeping in mind that I'm very biased about it.

But I have, I mean... You have a rocket there, so there's that. I'm kind of pro-rocket, so... Rockets are good, especially when they're attached to products, I guess. But I mean, one thing that's true is that I have been working on Pegasus full-time for almost three years. And so just by sheer amount of sort of effort that has gone into it, I think it's likely sort of the most...

had the most i mean work isn't always a metric of quality uh but it's at least got to be correlated somewhat so there's there's been a lot of investment into pegasus and and it's got a pretty good user community as well we have a slack of about it's approaching 100 uh people who are in there kind of talking talking about building their apps talking about building their startups and um and giving me lots of feedback that i can then incorporate into the product as well so

It's a nice kind of cycle that way. So you get, when, when I signed up for signed up, uh, I think I signed up last year. Um,

I haven't, I think I've, I've attempted to go through a couple of times, but I, um, realized that I think I needed more Django experience, uh, first. Um, but, uh, I've done, done some tutorials, so now I'm ready to get started again. But, uh, for people that don't know what it is. So if I, I signed up for, uh,

signed up for SAS Pegasus. And then I go through some, a little questionnaire of what I want in the app and different features. Um, and, and then, then it down, it gets, it gets something ready for me and I download it. And then, um,

That's my starter app. And then I can put that in GitHub or whatever to do version control at that point, right? Yeah, exactly. And as of last month, actually, you can skip that download step as well. And you can push your project directly to GitHub from Pegasus. Oh, really? Okay. Which is a cool, fun feature that I added recently.

But that's exactly right. And behind the scenes, I'm guessing a lot of your listeners who are familiar with Django are probably also familiar with Django Cookie Cutter, which is a library that kind of allows you to do this type of thing. And Django Cookie Cutter is a Django thing built on top of another library called Cookie Cutter.

And Cookie Cutter is basically the thing that powers both Django Cookie Cutter and Pegasus. And it's basically a framework and language that allows you to add and delete and modify code, essentially, based on a config file. And so behind the scenes, when you're changing all these things in Pegasus, the adding features, choosing what CSS framework you want and all that stuff,

It's then using cookie cutter to generate a completely bespoke code base for your project so that you get all the stuff that you wanted, but you don't get all the extra craft. You don't have to manage the config with settings or anything like that. The code base that you start with has been designed specifically for your project, which for me, that was a big requirement building Pegasus because I had seen some other things that

you know, you, you install the thing, but then the first thing you do is you like edit 50 variables in a settings file and then like huge swaths of code in your code base never get called because they're, you know, in this project that, uh, that was designed to accommodate all these different use cases. Whereas if you do it this cookie cutter way, you don't end up with all that extra code and you kind of just end up with exactly what you need. I love that. I, that, that sounds great because I don't want, well, one, I'm,

I'm going to want to read all the code. And if I'm reading all the code that I don't need, that's kind of a bummer. Yeah. I mean, deleting code is my favorite thing to do in a project. So the opposite would mean that having all this extra code is the worst thing that a project could have.

Well, I mean, or the best if you enjoy deleting. Yeah, if you want your first 10 hours on your project to be deleting code, then I guess you could do it that way. How long do you think it would take somebody that's comfortable with Django, how long to get their first beta version up after running Pegasus?

Well, so it's a really tough question because what Pegasus provides is all of the scaffolding. It'll provide your front end, it'll provide your build infrastructure, it'll provide your CI, it'll give you a big head start on deployment. But you still have to code user accounts, billing, all these things. But you still have to code the business logic of your own application. And that's where pretty much all of the

work comes right so if you if your application has dead simple business logic then like let's say it takes you five hours to code that up and then on top like so if you did that on top of pegasus then i'm guessing you could have it in prod in you know maybe three hours after that this sounds awesome okay so that one of the things that intrigued me is um uh is the subscript the

the billing part because I didn't want to get that wrong. Um, and so I was like, okay, I need to find something that can help me with the billing part and user accounts because I don't want to get that wrong either. Um, and, and, uh, the rest of it, maybe I didn't even care if it was really that pretty to begin with. Um, because, um, because I can, you know, I can throw,

I don't know, something at it, CSS at it or something. And I hire somebody to help out maybe, but, um, but getting the, getting the subscription, the, just the user flow wrong. Uh, I, I wouldn't know how to fix that. And also like the tutorials, I gotta, I've, I've, I've talked to some of the Django people and I know that it's hard to do a tutorial from like from zero to working website, but,

Come on. Like the, the, the, like the, the getting started one gets you to a, like a whole, the polls app. It's good to sort of understand some of the internals of Django, but, um, also it's not, there's no, there's no user authentication yet. There's no, um,

There's didn't talk, it doesn't really talk about deployment much or anything. And I'm like, I, I'm still way there. It's still at the now draw the rest of the owl phase. Right. And so,

I'm glad. So let's, I don't know how to transition, but let's, some of the things I'm confused about, um, you, before we recorded, you said, let's talk about some of the things that aren't just specific to Pegasus, but are just generally in Django apps. And I, I totally agree. So the first right off the bat, I'm thinking about, I'm going to have to decide lots of stuff. So I don't know. I don't know what I needed to decide first. Do you have any ideas? Um,

Well, I mean, probably some of the biggest decisions that people talk about these days. A lot of it is front end. So there's some decisions that there is pretty much consensus around in the Django community. So database, 9 out of 10 developers are going to tell you to use Postgres.

Authentication-- I mean, Django has the auth system built in. And then most SaaS products will layer Django all auth on top of that, which is a library that gives you a lot of functionality on top of the Django auth system. So social logins, you can log in with Google and GitHub and Facebook and stuff, and password reset, and email confirmation, and a bunch of that sort of standard stuff on top of it.

Those are some of the things that, I guess, every app needs, but is pretty much decided in the Django world, or at least there's a very strong leader in the space. Front end is probably where there's the most debate. So does Pegasus use all auth? Yeah. So Pegasus leans somewhat heavily on a small set of libraries that

My criteria for picking libraries to put into Pegasus are just-- they have to basically be one of the top five libraries in Django, and then I'll use them. So yeah, so Pegasus uses AllAuth behind the scenes. AllAuth comes-- it's great. It comes with a ton of functionality. But you have to set up a bunch of stuff yourself. The templates don't look great. The emails don't look great. And so Pegasus, on top of AllAuth, will then configure it, customize it, and provide

sort of much closer to what I would consider to be a finished, polished experience on top of it so that you don't have to fiddle with everything in all auth and customizing it for your own application. Because all these open source libraries are designed to be customizable and meet all these different use cases. And so out of the box, it's kind of analogous to the cookie cutter thing I was talking about. But they're sort of built to support all this stuff.

But they don't have just like, oh, this is the default configuration that's good, and just use it this way, which is one of the things that I think Pegasus tries to do is configure these things for you, set them up nicely, and give you something that works right out of the box so you don't have to just wrestle with it. And then if you want to customize it from there, you still can. But you're not going to go long in the journey, I suppose.

Because a lot of this stuff, especially with the first project, I don't know what the choices are. And I guess I don't care right away. I just want a good one. Somebody pick a good one for me. Yeah. So how about Docker? Yeah. I mean, Docker is an interesting one.

So I grew up-- I did development in Django. Like I said, I've been doing this for a long time. And so Docker just wasn't a thing when I learned Django, when I got comfortable doing coding. And so I think I don't personally use it all that much because I know how to do all the complicated things that Docker sort of makes easier for you.

That said, I think I recommend Docker for most people because of, I guess, a few reasons. But the most important ones are sort of like portability and consistency. And the thing that Docker does really well-- and I don't know if you know this, and I'm just sort of telling you something that you already know-- but is it-- you have essentially a single file, and that file can build

something in an incredibly consistent way that you can run on Windows, you can run on, you know, Mac and Linux, you can give it to a platform as a service company, like a Heroku or something, and they can run it for you. And so it provides this remarkably consistent way to run stuff. And that can be really useful in development, because like, you know, everybody's got a different version of Python, everybody's got a different operating system, everybody's got

you know, everybody's environment is a little bit different. And Docker just sort of solves all that and says, Okay, if you're using this file, you're going to get like this version of Python and this version of blah, blah, blah, and it's going to run, you know, you can you can be very certain that if it runs in this environment, it's almost always going to run in any other environment. And so, again, like if, if you've never done web development before, and you just want to, like, you don't want to be fiddling with libraries and virtual environments and

and I mean, I know you could hold your own in virtual environments, but you basically just run, you know, like Docker compose up or whatever the thing is, and it'll spin up a database, it'll spin up, you know, a cache, it'll spin up your web application, and then you're off to the races and you don't have to sort of install anything besides Docker. That's where I think the value is in terms of the development experience, getting up and running, and then in production, it's that portability can be useful too.

Because you can be sure you're having sort of a very consistent-- So then during deployment, am I deploying a Docker image then if I choose the Docker versus-- Well, so in Pegasus specifically, deployment and development are separate. So you can choose whether or not you want to enable Docker for development. And then you can also choose whether you want to do deployment on Docker or on your own. And it's-- I mean, most of the--

hosting companies or the platform as a service pass companies will use Docker under the hood. And then the main question is just sort of like how many layers of abstraction exists between like what you give them and, and the underlying like Docker container that's running. Okay. So, uh,

okay so specifically for pegasus there's a use docker checkbox does that use it at that oh it says right there i if i were to read better uh it's whether or not i use it for local development okay yeah yeah i should probably not put that in the help text and put it in the in the label instead so it's a little clearer it's it's it's clear it's just i didn't read

Yeah. Users don't read, right? I should know that by now. I guess maybe you're right. Maybe if it said use Docker for development, maybe. But anyway, it's fine. And I'll say...

The way that I like to develop and the way that I might recommend you do it too, if you're well-versed in Python but it's your first foray into web, is you can also use Docker just to run your services, so like your database and your cache, essentially. And then you can still run your Django code in a native virtual environment. That's actually how I do all my development. I think it's kind of the best of both worlds because you don't have to fiddle with

databases and stuff like that. But then you can still use all the native tooling with your Python environment. OK, so if I want to do that, do I hit the Use Docker for Development button? In Pegasus specifically, I think no.

OK. And then I have a Docker Compose file that is on my GitHub that I can share with you. And that will run Postgres and Redis. And then you can use your Django app to run against those.

Do you deploy Docker images then for everybody? Or does that depend on which deployment target I choose? Yeah, it does depend on which deployment target you choose. But they're mostly Docker-based. And they kind of go into two or three high-level categories. One is like a platform as a service, so like a Heroku or a Render or a Fly.io.

And those will typically just take either like a Docker config file or some other abstraction that generates a Docker config file, like a proc file or something. But they basically are running Docker containers for your application, and then they'll provide a managed database and a managed Redis and so on. And then the other option is to sort of roll your own.

And then in that world, you're more installing on a server that you control. And in that world, you can still be running Docker containers for everything. You can also use mix and match with managed databases. And if you want, you can also just run Python in a virtual environment, Nginx, G-unicorn. That's sort of the classic stack that everybody was doing maybe five, seven years ago.

And it still works great. So most of my projects are still set up that way because they're relatively old. But it's not a bad way to run Django apps. Well, so do you have a favorite for people, the things that you support right now? Well, so I kind of recommend-- I try to tailor my recommendations to the individual.

And so for you, if you're just getting into web, you don't feel like you want to be doing a lot of sysadmin type of stuff, then I would just pick something like Render Heroku or Fly.io. And they're all relatively similar. They'll be priced differently depending on the details of how much resources you end up needing for your application. But they're all relatively sort of like

point and click, configure a few things, have a CLI and a dashboard console where you can kind of manage stuff. And they'll mostly hopefully take away the DevOps burden from you. And they just kind of like deal with that on their own. Okay. What if I throw the wrinkle in that it really needs to have like the best uptime that I can? Does it matter then?

I wouldn't expect it. I remember you had emailed me saying that you had heard there were some uptime issues with Fly. So one of my apps is hosted on Fly, and I don't recall having any issues with them over the past nine months or so since that app has been live. They should all be reliable. And it would be a big-- I mean, these are like,

100 million billion dollar company. I mean, I don't know how big some of these companies are, but they're like, you know, they're serious companies and I think other serious companies rely on them for infrastructure. So like it would be that really not a good sign if any of them were going down with any regularity. Okay, well, let's say I choose one of them and decide later to do something else. Is that, is it, do I have to decide completely now? Is it something I can change my mind on?

Yeah, you can change your mind. So the one thing-- I mean, with Django, there's a small category of data that is persistent. The most obvious is your database. And the other category would be media files, which is essentially if users upload files to your application, those get stored somewhere, usually like S3 or something like that. But so the process of switching would basically

It would depend a little bit on where your database was, but worst case scenario would involve backing up your database, migrating it somewhere else, and then turning your application back on somewhere else. And you could do it with minimal downtime, but if you're willing to tolerate an hour or two of downtime, then you could do that pretty easily without too much work. OK.

Well, I want, so I want to get through at least a couple more questions, topics this time. One of them is, okay, let's just jump in. I have some like related, I'm a very tangential sort of thinker. That sounds great. But all of these different platforms, if I've got one,

If I'm trying to do it myself, I've got to learn one of them. You've got like six or seven on the list. Is, was this a difficult part of this or was this easy for you to figure out all the logistics of the different platforms? You're talking about the deployment platforms? Yeah. Like for you personally, was this a pain to have this many options? Yes and no. So,

Like I said, so most of these things you can set up with a config file. And so when I was adding support, I was like, you know, I was like, okay, I'm going to work on deployment this month. And I'm going to like, I'm going to go figure out what the top five platforms are, and I'm going to support them all. And each one took like, you know, like a day to sort of troubleshoot and figure out how to get it working. And so adding them was relatively easy. What I did not

fully think about at the time was that like i was going to have customers on all of those platforms forever and all of those platforms were going to change and you know things things were you know api updates the documentation and support documentation and support and all that so now it it is tough like like someone will run into some issue on some platform and then if i don't have if i don't happen to have an environment already running there then i have to go

remind myself, I have to follow my own documentation essentially to spin up a new dummy project on this platform, see if I can reproduce an issue, figure out how to fix it, and ship the fix. So it has been a longer tale of support work

than I anticipated out of the gate, which is-- that statement is true for a number of things in Pegasus. You'd think I would learn my lesson by now. But I kind of keep adding things in hopes that they won't have these long support tails, and then some of them end up having them. OK.

okay well the the other couple talks of topics i wanted to talk about was framework and front end stuff so uh one of the the choices for is the css framework now there's some people that are going to have their strong opinion but i don't so you've got bootstrap bootstrap with material at boom palma palma palma i don't know palma and

And Tailwind. I assume there's probably more choices out there in the world, but you picked those. But somebody for any Django project has to figure that out also, right? So how do you choose? Yeah, I mean, the short answer is probably like many technologies, first pass would be if you know one of them, use that one.

That's a rule that I really like. If you don't know any of them, I would zero in on Bootstrap and Tailwind as your options. Bootstrap is kind of like the Django of CSS, I would say. It's been around forever. It's got an incredible community. There's a huge amount of support and resources and everything else out there. Tons of people know it. It's easy to find developers.

And it's like maybe a little bit dated and, you know, can be a little bit slow at times. You could call it sort of like boring tech or something like that. And then Tailwind is, you know, in this analogy, it's probably more like React or something. Like it's the hot new thing that is super popular these days and everyone wants to use it and everyone wants to learn it. And there's also a huge ecosystem developing around it.

And so it's a little bit like-- yeah, it's almost like whether you want to stick with something boring and stable or whether you want to be on the cutting edge of this tooling. In terms of technical differences, so I don't know how-- if you're familiar with either of them, Tailwind's whole thing is-- it is-- what do they call it?

I forget what they call it. But basically, Tailwind is like, every CSS attribute should be a class. And you shouldn't have any classes-- like, Tailwind is like, you should never have a class for a card or a--

a button. And instead, you should have 20 classes that say, text color red, margin two rems, padding this much, shadow this much. So literally, a button in Tailwind will often have these--

I'm not even exaggerating, maybe like 20 class names, which sounds crazy and is often very jarring for people who start development. It is somewhat mitigated by a library called Daisy UI, which Pegasus uses. Daisy UI is kind of like a bridge between Tailwind and Bootstrap. And so Daisy UI will actually provide a button class and a primary button and an error button and whatever. And behind the scenes, it

it just maps that to the 20 Tailwind classes that you would want. But one nice thing about the Tailwind world is that it's very portable. The only unit of style is the HTML and the classes. And if a product is using Tailwind, then it'll look exactly the same. Whereas when you use Bootstrap, when people want to customize Bootstrap, they'll start

messing with variables and adding their own classes and stuff. And then I don't know if I'm explaining this well, but the benefit that comes with that is that if someone makes a component for Tailwind, you can just copy the paste the HTML into your project, like into your Django templates, and it'll look exactly like that component. You don't have to ever mess with CSS and stuff. So that means that Tailwind has a nice ecosystem of template libraries that are coming out now.

where you can just go onto some website, you can search for essentially all these things that you would want, navbar, card, whatever it is, and then grab these big HTML files and just kind of paste them into your Django project and they start working. So it's a really nice way to build things that look nice quickly. I haven't had a project get sort of long in the tooth enough to know whether that style of development eventually becomes a maintenance problem or not.

Although it kind of works out fine. Are you a CSS person yourself? Do you know the fiddling with it? Or are you leaning on these frameworks to do most of the work for you? I'm leaning heavily on the frameworks, for sure. What I would say is I'm probably better at front end than the average back end developer. But I'm much worse at front end than the average front end developer.

So I can kind of make things look okay and learn the tools and stuff, but it's surface-level knowledge. Okay. So what you do, again, if I were to read the documentation, the little thing says if you have trouble choosing, see the documentation, and then you have a documentation page to talk about it.

So actually your stuff points, it's not the instructions. If I just read them or better, but I'm curious how consistent that documentation pages with whatever I just said. Well, so one of the things that one of the reasons why I'm,

I had not known about this Daisy UI thing, but I had talked with somebody, I don't know, a year ago or something that, that had a side project and they used the paid tailwind UI thing to, to just design some stuff visually, I guess. I think there's a, I don't know, there's a paid paid service where you can get help with designing something. I don't know if it's worth it or not, but yeah,

Six months ago, so I used that. I bought that. I use it on, like Pegasus's homepage and pricing page are lifted from that Tailwind UI. And six months ago, it was 100% worth it. Now there's enough open source stuff out there that you could probably get away with not using it. But honestly, it's not that expensive. And it's made by the creators of Tailwind. And they put a lot of effort into making it.

pixel perfect on every screen size and all sorts of stuff so it's okay yeah i would still recommend that as and that's compatible with uh pegasus yeah the html version is they have some stuff in there that's sort of like react only that is a little bit more permission to integrate into pegasus okay but uh the initial release included was all html templates and those are all

You can just drop those into Django templates, and they'll work out of the box. OK, last topic is-- and this isn't really the last topic, but for now-- HTMX versus React. Yeah. And again, it depends. Yeah.

I would. But for for let's like, let's go with the I don't care. What should I pick? Well, what's your app? Tell me more about the app you're building. Okay, so I want some but I wanted I want to get money from it. So people have to pay me and log in and stuff like that. But basically, it's going to be sort of a list thing. It's a front end for another service, the back end services doing all the heavy lifting or doing the the daily work. It's a signup list, essentially.

Um, so people are going to sign up outside of the app, possibly in the app. I might have like users be able to like look at an event, kind of like a meetup sort of a thing, but not as intense, um, uh, sign up for something. And then before the event, the event holder needs to be able to like look at the list of names that people signed up. That's pretty much it. Um, yeah. So there's like that. I would, I would definitely use HMX. Okay. Um,

And the reason I say that is just that where React really shines is if you're building something really complicated that needs a lot of client-side state. If you were building Figma or something or Gmail, you would want to use something like React so that you can provide this rich user experience. What you're building sounds a lot more like a CRUD app with some

with some tweaks and bells and whistles and a fancy back end or a fancy integration on the back end. But for that, yeah. I mean, you might not even need HTMX, honestly. You might just be able to do the whole thing in pure Django templates. And that would be totally fine as well. Well, none isn't an option. I can't pick none on your-- Yeah, well, so there's a handful of things inside Pegasus where I wanted the UX to function more like a single page app.

So for example, when you're working with a team and on the invitations page, you want to invite five different people to your team. I didn't want that to be a full page reload every time you did that. So there's tiny little bits of Pegasus where I needed single page app-like stuff. And on those little bits, it uses either React or HTMX. But you don't have to use either of those technologies for--

And you can, you write and they'll, they'll be there in the background. If, if you're using the pieces of Pegasus that, that use those, but otherwise you'll hopefully just be able to kind of ignore them and, and never think about them. So I, I think that it would be fun to,

uh, to, to sort of wrap this conversation up a little bit. Um, and, and then have me go off and like do some work and learn some stuff and generate some more questions and then come back and maybe like touch bases with you. Um, maybe a couple of times through the process of me getting this thing off the ground. Um, does that sound like fun?

Yeah, that sounds awesome. Awesome. Cool. So for people who want to reach out to you, well, SAS Pegasus is, we'll leave a link, but it's s-a-a-s-pegasus.com. Yep. So pretty straightforward. And with a good rocket.

And, you know, I, I have, if people don't know how would they listen to this podcast and not know, but there's rockets on my books. So, um, okay. Anyway, I didn't know that. So I'm embarrassed. No, it's okay. They, they, the first, they, I got the first comps came out or comp. I don't know if that's the right word. They, uh, the rough up of the cover of the book, um,

was shown to me and and i got to choose the artwork but like most of the choices were snakes and i'm like i i'm i'm kind of tired of the python the snake association with python i know it's there but can we do retro rockets and so i got a handful of retro rockets so the um the django unofficial mascot was it was either a pony or a unicorn or it was like

a unicorn that they called a pony or something like that. But before I had the name SAS Pegasus, the original code name for Pegasus was Rocket Pony, which is why there were rockets everywhere. And then I was like, well, Rocket Pony is-- I think I was trying to draw or find a picture of a pony on a rocket, and it was just impossible. And I forget how I ended up with-- I think I was like, oh, flying horse. OK, Pegasus. But that's why the rockets are still

hanging around. Oh, right. And there aren't any drawings of Pegasi. Yeah. I tried to find them online, and then I tried to get AIs to make them. You know, I should try again because the AIs have gotten a lot better now. Nice AI Pegasus these days. But before, they were like, every time I tried to get an AI to generate a picture of a Pegasus, it ended up looking like it had come from ancient Rome. And even if I tried to prompt it, it had this very sort of like,

mythical ancient greek illustration quality to it so which didn't really vibe with the brand that i was trying to create oh well i mean your site's beautiful so and i like the little logos and their little icons and everything the um the user impersonation little thing is like the secretive dude with the it's pretty cute there's some good good icons there so mostly fun awesome okay

Yeah. Uh, and so, uh, with, with, uh, the little promo, like the whole thing was kind of a promo, but there's a little bit more, um, you've got documentation, you got user guides, you've got videos up, um, uh, anything else you want to plug about your project before we wrap it up? No, I feel like, yeah, I feel like this whole thing was a giant plug. So thank you for giving me the opportunity to come on here and, uh,

And, you know, it's helping me, but I don't feel bad about it at all because I think so the, the, the space where this fits is something I, I think that it's brilliant. I know, I'm sure it fits in lots of spaces, but there's a lot of people I think like me that are like, Hey, I'm a software person. I've got people I know in the community that I'd like to help with a project. And

I'd like to make a little money on the side with it also, but I could help out. But I'm not a web developer full time, so I need some help. And something like this to get me through from... I already know how to code. I just don't know how to do a polished web app. I'm glad something like this is here. So thanks for putting this together.

Yeah, well, I hope it works out. And I'm interested to see where you take it. Yeah, all right. Well, thanks a lot. And we'll talk to you next time. All right. Thanks so much.

Thank you for listening and thank you to everyone who has supported the show through purchases of the courses, both Hello PyTest, the new fastest way to learn PyTest, and the complete PyTest course, if you'd like to really become an expert at PyTest. Both are available at courses.pythontest.com and there you can also join the Python test community. That's all for now. Now go out and test something.