← Back to Show Notes

Transcript: Event Sourcing - Chris May

This episode is sponsored by Hacksoft, your Django development partner beyond code.

More on their services later in the show.

Hi, welcome to another episode of Django Chat. I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

Hello, Will.

And we're very pleased to have Chris Maid join us today. Chris, welcome to the show.

Hello, Will. Hello, Carlton. Great to see you guys.

Hello, Chris. Thanks for coming on.

We've known you for quite a while now through conferences and stuff, and so much delayed having you on, but maybe you could tell us, what are you up to these days? Then we'll dive into your previous talks and backstory, but how are you using Django today?

Mostly for my website, honestly.

I've built that, I don't remember how long ago.

It's been definitely over a decade since I've put it on top of Django.

And now I use Wagtail to power it.

And sadly, that's the primary way I'm using Django right now, except for all my little experiments at work.

We're mostly FastAPI or Starlet.

I keep saying, but Django, Django's a really good option.

So I guess you could say I'm a polyglot for Python web frameworks.

On your personal site, so you can make that however you want, right?

Like, are you on 5.2 or planning to?

I mean, that just came out a couple of days ago as we record.

Right.

This is the shame part.

I do not know exactly what version I have.

I had it open yesterday, but the numbers don't stick in my head.

But it's definitely not.

I don't even think I'm on the latest LTS, honestly, mainly because my local setup.

Um, ever since I got my new computer, I, I just haven't like spent the time to get it

set up correctly.

You know, I'm kind of in some ways in maintenance mode on my, my personal website.

Um, but, uh, you know, just trying to clear up some time to upgrade everything.

Yeah.

Well, that's how, you know, you're a professional, right?

Like you don't have, you don't have time to fully perfect everything.

So yeah, the web developers website is never up to date.

No, it doesn't have to be.

Yeah.

As long as it's running, right?

Carlton, you must have a take on that.

Well, I'm just sitting here smiling as Chris tells this, you know, oh, no, Django is not quite up to date.

You know, it's still going.

It hasn't fallen over.

Why would it fall over?

That's the great thing, right?

You can update it when you're ready.

Yeah, absolutely.

And if it's well architected, then you don't have to think about it.

I know we talk about the latest versions and features, but the reality is a huge map of what you actually have to do.

And yeah, not having to keep up with Django is a big reason why we use Django because it's there if you want it, but it's probably not going to break on you.

Can I swing back quickly, Chris?

You talked about talking about your work.

You're doing using Starlet first API there.

What's the what's the applications that you can talk about?

So I work for a company that makes software for the health industry.

And so I've been on a couple of projects like the current one I'm on is kind of a essentially like an internal tool.

that, you know, it's funny, like, I've joined this company for less than a year, so I don't

understand all the organizational aspects of it, or even all the offerings they have. But there's

one tool where it's related to people who have post-acute care. So essentially, a patient comes

into the system, they have a giant document of their medical history, or at least recent medical

history and as a part of the flow a nurse has to go review each one or you know a nurse has to

review some of them they have a team of nurses and so my services the point of it is to one

to get that packet of information and leverage ai to ask it a bunch of questions and summarize it

for the the nurses so so that yeah they don't have to they can they can you know it's funny

Because, like, one of the best things about it is we're trying to figure out how reliable is this, you know, with.

And thankfully, it's been incredibly reliable.

So that's, you know, we keep doing blind tests and stuff like that.

And so, thankfully, for at least this application, the AI is doing good.

Okay, so my sort of take on this is that if you're getting them to reduce, if you put in more context than you're asking them to output, they are very reliable.

Because they're taking, they're summarizing an amount rather than, whereas if you only

give them a little bit and try to get them to output a lot, that's when you're in big

trouble.

Exactly.

Yeah.

I'm here in Boston.

And so there's several startups just in my co-working space doing similar things, you

know, so one is using AI to tap into Athena Health to do like the, for doctors or nurses,

I guess.

But when you do like get your blood work and stuff or things like that, right, it pass

it through AI first because it will flag if something's off. And I guess I think I've talked

to them quite a bit over the months, and a lot of things in medicine are somewhat routine,

and you have these nurses and doctors who are just completely overworked. And so something

that saves them time that they can still review and sign off. There's still a human there for a

variety of reasons but ai is great right it's not like nobody's building an agent yet for health

care right whereas coding like somehow we're all replaceable but you know maybe it's maybe that's

to do with the billing and the insurance i just realized we're a bit going wrong as well because

we just said that uh you know if you give them a big context and ask for a small one out you

can do quite well whereas the other way around was i'm like can you you know can you write my

ui for me and they give me the shoe it's like i got the ui was more than i gave it so i perhaps

i need to up my prompting but i mean but but you know but coding is such a broad yeah it's sort of

kind of infinite right if you said hey build a django front end there's i mean what are you doing

are using htmx are using react are you you know blah blah blah blah blah right whereas in the

context i would imagine in a medical one it's much more specific but actually i have a question on

that so are you using uh or are they using um not off the shelf but you know like chat gpt kind of

stuff or are they using because there's now a lot of these more targeted domain specific llms

we're using uh we're on the gcp platform and i think we're using vertex ai to do the rag

questions and stuff like that the processing okay do you get to play around with with that

whole part at all or you're more on the website i'm not more on the website i i yeah i have a

very small team there's three of us and uh one the the kind of the senior the architect of of

our area he's like this is my baby i want to play with this yeah so i get to look at his code um but

i'm handling all the the the web stuff which is my baby so that's wonderful right well one of i mean

And again, just going off of my discussions with people I know here doing something a little bit similar, some of the things they've mentioned that didn't occur to me at first is that, you know, because the prompts are, you know, in English and you get it to work, but it's specific to that model.

So, you know, like a new model, there's constantly updated models, the process of, you know, it's not as smooth an update from like Django 4.2 to 5.2 as it is going on whatever version with the LLMs because you're sort of back to square one.

So I guess I'm just, I imagine that's also the case for your colleague that you're, you're really kind of, it's harder to switch because the LLMs and the prompts, it's, yeah, it's not code.

It's sort of English.

Yeah.

Yeah.

And we definitely have, have a tool that we, we have a few, you know, trial PDFs that don't have, you know, patient information or, you know, we have, it's sanitized, let's say.

And so we have a tool that I can, you know, we essentially have a Python script that you aim it at a PDF file, tell it which model you want it to do.

It'll do the whole process so that we can test each new model as they come out and see how they perform.

Right. That's the trick, the engineering trick, it seems, is to have some kind of test harness which can validate whether your prompts are still working.

Yeah, and we have a team of, you know, a few project managers and other people on the team that we're serving who are former nurses and things like that.

So there's a lot of industry knowledge.

So we pretty much run this and go, here, is this good?

You tell us.

I was going to just say, you've been at the engineering a while, right?

Because, you know, we're going to go on and talk about your talks, which is just super.

But you come at it with quite a lot of background.

I mean, I've been building websites since 1995, so that's, you know, a couple of years.

But I graduated with a degree in graphic design mainly because I thought I wanted to be a computer scientist but couldn't understand what they were trying to teach me.

So I switched to graphic design.

Absolutely love that.

You know, I, you know, just the, it's like I often, I used to say that I'm really the product of my parents.

My dad is an engineer.

He thinks about how things work and things like that.

My mom is an artist, and so I'm very much using both sides of my brain.

And so I love the graphic display of websites and trying to figure out how to make a really great user experience and then having the engineer prowess to actually make it possible and to make it as smooth as possible and have well-readable, well-understandable code if I can.

Yeah. And so, so yeah, so essentially back in roughly around 2007 is when I started using Python and just a few years later, I started using Django. And yeah, that's kind of been my passion is, is, you know, making, yeah, the user experience as best as it can be both for the users and for the developers. So somewhere in there too, I, since I learned to program as an adult, I had a lot of, you know, feeling like I didn't belong.

and I did a lot of learning from the people around me. And as I, I tried to like, whenever I'd learn

either through a blog post or a podcast or, you know, somebody on my team, I would try to make

a habit of like sharing it with another colleague of mine. Cause I figured like, if I just learned

this, then, then they might want to learn too. And about third of the time they're like, yeah,

yeah, I already knew that. Yeah. Thanks. Sure. About a third of the time they were like, wow,

well I didn't know that thank you but the best part was like a third of the time people would

be like well that's true under these circumstances but here's a thing that you might want to know

and um and so kind of by doing this I also felt like I've kind of as I grew as a developer also

grew as a coach because I got to you know share with people and uh and then eventually like when

I became a lead developer, which was a major anxiety point in my life as an imposter. I didn't

know what to do for a couple weeks until I finally thought, what would my podcast say to do? And I

just tried to invest in those around me. And that's kind of what I've been doing for the last

few years. And I've been really enjoying that too. I like that little story because as you began it,

I was thinking, well, you know, the teaching is learning kind of thing. So, you know, you come

across something new if you try and teach it to a third person then you know you you ground that

knowledge a bit deeper in your in yourself but then when you get that feedback of that third

of the time and someone says ah but have you considered this it's okay that's the circle

the strong opinions loosely held kind of thing is what i try to strive for well i think it's

if you learn how to program within these organizations because you're coming from

the graphic design side you had you had those colleagues i mean i think a lot of people

you know don't have that at all i didn't have that when i was learning how to code

um and it really hinders you you have to find if not a community a group right where you can

bounce ideas and have some give you know give and take um it's a little bit easier now with

discord and the forums and stuff but you know back when i learned how to code it was stack

overflow and oh you didn't want to go in there with a question that wasn't perfect you would get

lit up. Yeah. And actually to that point, um, in the first programming job I had, uh, you know,

I was learning Python. I was loving it. And one of my colleagues, uh, was also very passionate

about Python. And so the two of us were like, wait a minute, Richmond, Virginia needs a place

for Python developers staying out. So we created PyRVA and, um, we've actually, wow, we're closing

in on 10 years of PyRVA. And, um, you know, we're trying to create a little community where people

can just kind of come together and you know learn together and uh yeah absolutely well there there's

uh i'm not going to say surprising but there's there is quite a scene in richmond i mean several

people we've had on this podcast i mean justin duke from button down uh i believe andrew mishar

um yeah there's you know it's i mean i know i mean richmond richmond has always had what was

it there's there was a a very prominent digital agency that's been there for a long time right

Yes, probably. And I probably don't realize

how prominent it is. Yeah. I remember, you know, 20 years ago, um, cause I went to college in

Williamsburg, Virginia. So that's right. Some sense of the Virginia thing. And, uh, that's

where I grew up actually. Oh, okay. Yeah. Um, anyways, well, so, so you started in the graphic

design. So then did you, did you go into, what did that mean? Did, was that like graphic graphic or

did you, were you have a chance to do a bunch of HTML, CSS and JavaScript before you went over to

python um a little bit of both um most so when i started web development there was no css so but

all my computer science friends said damn it chris your websites are so much better looking than

ours and so i kind of had i you know i had uh i won a copy of photoshop in some high school

you know competition so i was always messing with uh graphics and stuff like that um but then i um

you know through the graphic design thing i essentially got pulled away from web development

And so I was doing, you know, all the print stuff. In fact, at first I had a hard time finding a job because they were like, you have too much web experience. We want more print experience. And so then I ended up getting a job at an advertising agency and did a lot of logo work, brochures, that kind of thing.

but also you know the they realize oh he knows how to do websites and so i would do just at that

time i learned css so i did html and css but not javascript because i thought javascript was java

and i hated java applets and i was like there's no way i'm learning any of that um and then in my

next job um was similar i was at a trucking company uh that's nationwide it's called estes

express lines and uh essentially that was awesome at first like it was you think doing design for

a trucking company would not have much variety, but I got to do everything from, of course,

the decals in the truck and brochures to custom board games and product photography. It was just,

it was shocking. And then at some point they needed somebody to help implement the website

because they bought the design of the website, but not the implementing of it. And I was like,

I'd be happy to help out. And that's when I learned that JavaScript is not Java.

uh, and started reading blog posts and listening to podcasts. And, and then I realized at some

point I was learning all the things that the computer science teachers were trying to teach me,

but I was doing it through blog posts and the way people were, you know, talking about it there is

like, Oh, now I get it, you know? And, uh, yeah. Well, especially front end, it's hard for the

teachers to keep up. Right. I mean, it's one thing if you're teaching the core algorithms course in

Java, but if it's JavaScript and all these things, right. I mean, they're, um, especially if you're

a truly academic setting you have so many other things you have to deal with you

can't keep up really i mean right because they're not practitioners generally yeah yeah i don't know

how many people are learning hdmx in in in college right now well yeah i mean if they are it's you

know some adjunct teaching it yeah right but same same with same with web development right i mean

because my my books are taught at some universities but it's always web is not a core part of computer

science curriculum that's a good point yeah absolutely i wish it were yeah because that's

one thing i've been thinking about too is like you know every now and then i get into a conversation

of like how worth it is college and it's like i think you know in certain ways it definitely is

worth it but it's like you know the computer science is not like you said web development it

is a lot of theory and of course you know great for you know i know some people who are learned a

lot in computer science you know uh courses and you know they're great at all the algorithms and

they are really smart in that way um but you know i guess really what it comes down to is this world

is just so complicated that just a you know the the colleges are trying to do their best i would

think but like computer science is not you know i think that um the college i went to also had like

a information technology degree which was at the time was like how is that different from computer

science of course it's very different and i still don't know exactly how but it's like

it's hard to like you can't have uh you know a degree in every single discipline i guess

well if you if you did it you can fix the problem well i mean the three of us none of us have

formal computer science experience right i mean yeah here we are i mean i think one of the night

one of the things about web that is so helpful that i wish there was a little bit more is that

it's one of the few things you can jump right in and immediately get your hands dirty and you know

carlton's used this analogy of like the grandfather clock with deployments but i think having a

project where you can build this build a site have it interact with people you know add analytics

you don't get that with writing you know python scripts for like a tiktok

or not tiktok toe you know like it's not visceral and it doesn't kind of keep you going in the same

way um totally web is right you can kind of get going and it's just nice to have something to put

a toehold in and i think that's that's the challenging thing about computer science is you

do have some students who web web or ai or whatever they've they already have the context

they sort of see how it can be applied and then you have just bright students showing up being

like what is this thing and you're dealing with people who've been you know a have the context

and B, have been doing it for years and you just don't have that chemistry. People don't walk in

with six years of chemistry experience to the intro to chemistry, right? So I do feel a lot

of people are like, oh, computer science isn't for me. It's like, well, no, you're comparing

yourself in the wrong place and you completely lack the context, which if you, certain minds

love the abstract nature of computer science, but I think most people want to do something with

their skills and you yeah i think it's like only the upper levels you kind of well it depends what

you want to do right i personally like the the nuance of database abstractions is not my cup of

tea but some people it is i'm just like yeah get the data throw it over here like let's go um and

and to your point you know too i was thinking about how just a couple years ago uh you know

we had a session at pi rva and you went i need to remember to do this but every now and then

i remember like you know we have a session at the theme is this but i also want to add you know if

there's anybody here who has a question about python i'd be happy to you know help or whatever

and so one of these days i remember to do it and this gentleman came up you know young man who

um was working on a really old computer and he was like i want to know how to i want to make a

website you know with python how can i do it and you know over the course of i don't know half hour

45 minutes i i helped him to download django or create virtual environment download django and we

ended up with the you know the the starter page when you get everything up and running initially

and like he lit up yeah because all of a sudden he saw that he could do these things and it does

he can load the web page in his browser and it's running on his computer and it's it was such a

magical moment and then i was excited because just uh uh was it this month or last month he

came back to PyRVA and was like, Chris, thank you for all your work you did. I now have a job

in web development. Thanks to you. And I was like, well, thanks to you because you did all the hard

work. I just showed you how to get started. And, you know, I think that is such a great thing to

be able to experience, you know, like, like you said, like, like doing something and having,

you know, the change and experience it. Yeah. I think of it as the aha moments.

You get a lot in web development, and you need them periodically, or most people need them.

Maybe Carlton's a philosophy PhD, so maybe he can just read the manual and be good to go.

I don't know if that's true.

I can read the manual, and then I can sit there staring at a syntax error for five hours

when I finally realize it was a missing semicolon.

That's because you're not using LLMs enough, Carlton.

That is a good use case for...

Or too much.

well yeah too much yeah no well we don't need to get totally just yeah anyway anyway i mean

like you know llm stories i just want to get to htmx and stuff but i don't know where you were

headed well yeah so i was going to ask chris you said you're interested in user experience and

crafting the thing and we know you've done these talks on htmx and spas and things but i wanted to

kind of back up a second so is that have you you've done the react stuff you've done the the

other things and like where do you think the richness of ui is is best or depends on what

you're doing or you know i'll give you it depends out straight away so essentially yeah i i went

deep into the single page application um environment um as somebody who cared so much about user

experience. I was working at a creative agency at that time and, you know, heard about this React

thing that came out of doing research on it. And I was like, we need, I need to find a really good

use case for this. And eventually found one. Actually, we ended up using Vue at that time

instead of React. But of course, I've kind of dipped my toe into all of them and loved it for

years, you know. And then at one point in one of the podcasts I was listening to, the person was

saying, you know, I realized that, uh, Oh, well, I'm trying to, I mean, no, at one point I think

it was the same person I mentioned in my talk, um, where he realized that all the work he was

doing in, um, I think he was also using view at the time. It's just like so much more work than

he did when he was just using Laravel and that kind of planted a seed in my head. And I started

looking at my projects and thinking, yeah, you know, we're, we're validating things twice, you

know you know as as smooth and as wonderful as the user experience is we're having to do a lot

of work to get that to happen and um and essentially i you know kept experimenting with things along

the way but it wasn't until um david guillot's talk at um jagocon 20 uh jagocon europe uh in

2023 where i was like oh htmx is much more than i thought it was you know and uh and yeah starting

at that point i was like what what that team did was amazing and i need to like do some research

into this and so you know experimented it on my with myself and um you know the for me it's like

i think the biggest where they're essentially you know like i kind of talk about how like it's for

the user experience and the developer experience is really what it comes down to for me a lot

and that initial page load is it hampers the vast majority of single page applications

and so like that's why in my talk i talk about streaming the html so that like

pretty much as soon as the essentially as soon as you start you tell the browser to go to the

page you start getting content back and you can interact with that content i love that um and then

having you know a progressive enhancement enhanced experience so that like you know especially oh my

god i can't i don't know how many times i go to a website and i try to click something or try to

interact with it and it's like nope not yet because you haven't finished loading it's uh

it's maddening um the example which comes to mind is get is github so i mean i'm sure it's fine if

you're in san francisco but i live in spain and so like literally i'll i'll be trying to review a

pull request and it'll be click and multiple seconds will pass before that click does anything

it's like no no no no this isn't this isn't progress yeah yeah and uh our bank just updated

their web presence or their uh you know what the stuff they sign on to and it's just like

okay so i i've now loaded this page i have to wait seven more seconds for a summary of my

my accounts and then i have to click into that and i have to for some reason some reason as soon as

it's live you click on the link it doesn't do anything we have to wait another second or two

before it goes it's just like this is not what we yeah and you know you know which link you want to

click right so if that link just functions you totally you could be on i don't even know if i

a deep link to it now that i think about it that might save some time

hacksoft is your development partner beyond code from custom software development to consulting

team augmentation or opening an office in bulgaria they're ready to take your project to the next

level can i ask you a question about the htmx methodology because i picked it up i don't know

a few years ago now um and i the thing that really struck me was the way it kind of ties into

http how it ties in you know the you use the http verbs you use the gets and the posts and the puts

and the leads and it just felt like it was kind of of the web in a way that and for me that was

why it worked so well with django because like the patterns that django wanted htmx just enabled

and it was like okay i think that i don't know we get a lot of return on investment from from

leaning into the web in that way and it's funny too because like i really when i kind of dove into

htmx i also did alpine js at the same time and i really loved you know that locality of behavior

You know, so you can just work on one little component and have everything defined.

Oh, and Tailwind.

I had Tailwind, too.

I like that.

Another story.

And so, like, everything right there in your HTML.

And I loved that.

But I also acknowledge that, like, that is a lot of – that adds a lot of weight to the HTML, which I don't think as far as, you know, the kilobytes across the wire, I don't think it matters that much.

But what, you know, some of the things I'm concerned about is when, you know, the person comes up behind me or me in six months, will I be able to understand that?

And usually I can because, you know, like I have like I think it's called rusty wind.

It kind of sorts tailwind classes so that like I kind of know like, OK, you know, it might take a little bit, but it's like, oh, yeah, each of these things mean specific things.

That's excellent. But like sometimes the Alpine JS stuff, I'm like, what was I thinking?

you know uh that one's a little harder the trouble is it's like um in the old days of jquery when you

could just you know you select your element and then you just do a line of and then your line

would get longer and it would get longer and it would get longer and in the end you'll be like

i've done too many lines this is the same danger applies with alpine right because one line of js

yeah no problem at any given moment one little bit more no problem but all of a sudden it's like

hang on i've written an entire javascript in an attribute on one element that's totally yeah one

of the project one of the experiments i did well i guess i can't really say it's an experiment

because i was doing it for a client um we were doing a uh rules engine and the you know so i

was hired by the uh vice president of the company and um and so he was like okay i'm gonna work on

it in react and you work on it now pine and we'll see like what it how how it comes about and pretty

quickly he was like wow this alpine version is much simpler so he kind of joined me on that for

a little while but then it was just like it's just kind of crazy because like in some ways it was

super cool because we just had native html form elements you know field sets with inputs and

labels and all these things styled to look amazing and and had all these hidden text fields to um

to kind of carry some of the data around with it and so yeah in some ways it was like a technical

i felt like this is amazing because like you we you everything was just in the form the state was

in the html and uh and then you know you submit it and it's just the form requests going out um

but oh my god like all the template inheritance and all the like special cases i was like yeah

there's definitely some kind of balance in between the two that that would be good

so especially right now i'm looking into like web components and trying to figure out how to

kind of what's what's the next stage you know like alpine js is awesome for like you know the

small things that you can handle obviously can handle so much more you can you know you don't

have to tie things straight to the html element you can you know add things through alpine magics

and stuff but um you know i know david gu uses uh stimulus in his projects and so and there's

i mean so many other things in django django cotton i think and i just you know that's one

of the things i'm frustrated with at work it's like i want to try some of these things but

you're not using django so so what's the ui stack at work is it the react type thing

no well so i'm sorry i should say yes uh yeah for like the projects i've been on not not not my

current project uh the current project i'm doing with html and tailwind and um and actually pico

and uh alpine but um but yeah the other projects they have dedicated team to do front-end development

so they do okay i think it's uh it's either reactor actually they're polyglot but you know

they have different libraries that they're using and leveraging into different spa architectures

but um you know so you're that naughty back-end developer who quickly sneaks in a little bit of

htmx on the side when no one's looking oh yeah i just i just built that because i didn't want to

disturb you yeah exactly well and it and we the the company that i work for has a internal uh

conference developers conference uh once a year and so last year i essentially gave my pycon i

mean jango con talk uh to them and was like hey you know there's a better way than the single

page application route and it turned a lot of heads but i don't know that much has come of it

companies are hard to turn around right totally yeah i i want to i want to come back to so you

mentioned it's fast api and starlet sort of the underpinnings um like why do we talk a lot on

this podcast about you know fast and whether django or not is fast uh i guess i'm not trying

to have you like throw a colleague under the bus but i'm curious like if if there are indeed

specific asynchronous things with the workflow that you're doing that benefit from that or

more it was someone who thought speed would be important and maybe like how how does django

lose out in those situations because you know like we would say well you can use django and

something that needs to be fast like you can do asynchronous things like or you know where is the

where's the speed problem um but like when i'm out in the wild because i like you i spend a lot of my

time dealing with non-django people now and you know so i hear about java and kotlin and all this

stuff and then i also hear about oh yeah i gotta be async gotta be you know fast api and starlet and

i i try to push them on like what are you talking about and i haven't really gotten a great answer

i know there are use cases for it but it generally seems to be more of a sense of okay python web

these are faster Django slow and then you know it's a year later and like you know you're using

these tools and they're good tools but um all right so that that's a long-winded thing I just

like as a Django diehard it hurts me a little bit when people say it's slow it's like is it slow

like um yeah and honestly like I don't myself I don't feel like it's slow you know I know I've

seen benchmarks but it's like you know that you can't I feel like the the the difference between

you know say fast api and django it's not worth the you know it's negligible in in real world

unless you if you have experience in one or the other like you know go with it for sure but i've

also yet to see i mean you know maybe if you're doing something truly truly real time like i don't

know chat something or other at scale chat bot at scale or something okay maybe but um i admit yeah

Maybe I just, well, definitely I need to spend more time with, especially with fast API.

Because partly because we, the company I work at supports it and we have integrations, but also it's, I mean, I suspect it's a lot, it's not just the speed element, right?

People like the newness of it and, you know, yeah, you start with something and then you just keep going with it because a lot of these tools are quite good.

Yeah. And in the case of my current project, so I presented a couple options and the person who has been shepherding this project was really mostly reacting against what he found in another project in our group.

they use um i'm sorry let me think what they use starlet on theirs and um my colleague was like i

don't like the way that is handling so let's use fast api which of course i'm like that uses starlet

under the hood he's like yeah it doesn't matter he likes that abstraction better yeah and i think

it's mainly because the um you know this my colleague is i don't know how much python specific

experience he has a lot he's a polyglot he's a lot of experience in java and is you know incredibly

smart um but he was seeing the code that the the the team was creating you know on top of starlet

and my impression was that he was not happy with that um maybe some of the the patterns that they

used to connect the routes to you know the the functions that i call them um i don't i didn't

really dig deep into why but i was just like yeah past api sounds good sure if that that's what you

really want no problem let's go with it yeah i mean well carlton you're the expert here but i

mean starlet is is ascii it's not really a full-blown like i don't know how many people

are writing pure starlet stuff or maybe they didn't realize they shouldn't be what do you

fast api is a well fast api is a nice layer on top of starlet right it's a nice

but why would they use starlet in the first place i guess right like that that's sort of

i'm sure they have their reasons that's okay so i see i so i maintain the channels packages i see

an awful lot of people who are diving into async just because they they think they need to um

and they're creating um people i often see are creating an awful lot of problems for themselves

which they could just avoid by not doing that way so i think there is a certain amount of um

how do we say um it's async is better no matter what belief out there which isn't really grounded

in reality um i think and so if that's the case then well fast api is the is the exciting um

choice there in the space it's like okay that's the one with the mindshare that's the one we'll

go for i don't think it's in most of the cases i see it's not really a technical um but it's not

really a technical choice it's not based on do you know what we've got these three throughput

requirements for these kind of you know none of that's been done it's literally a um a vibe choice

um and so the interesting question is why django the django because it's all because why we aren't

our messaging isn't you know better why aren't we should be out there banging the drum do you

know what django is still actually the best choice for you out there if we want to you know if we

want to stay relevant and stay competing and stay winning the choice in those kind of i don't really

know what i'm doing but i'm going to pick a web framework um i think it's that newness though

again like when i see non-python non-django people they they look around they're like well

Django's been around for forever. Flask isn't featured enough. Fast is like the new Django. It's got a lot of stars. That sounds good. I mean, I think it's pretty much that. And, you know, there's nothing against it, right? But it's, you know, yeah, it's, I don't know if how much of that, is that a polyglot thing? Is that just an ignorance thing?

you know because i mean if i was diving into i don't know rust or something i might look at

something that's newer that has the same amount of stars as something that's older and just like

oh that seems better without you know that's the problem with being a polyglot you maybe you don't

have the depth you might but you probably don't yeah and i i know you know and i think it's also

trying something new out too you know um i do feel like sometimes i wonder if i'm really an

odd duck because I just will create a project on my computer just to try out a new thing you know

new tool and I don't know how many other people really get to do that and so I think when a new

project at work comes around they're like oh maybe this is my opportunity to try this out you know

well I think most people don't have full control over what they do so like you either need to you

know hopefully find yourself in a consulting or other setting where you can try out new tools or

you just need to do it on your own yeah i mean that's why i think like yeah it's you have to

have something of your own that like you can play with like you know like a django thing right like

that was like i had i have this learn django site that i like completely rebuilt last year and like

there were some business reasons but a big reason was i just want to have like a real functioning

thing that like i can do stuff with like i'm coming up on there's a whole bunch of stuff i

want to do around testing and all these things and you get kind of tired i get kind of tired

of just like spinning up prototypes it's nice to have just something i fully control that

you know matters but doesn't matter so much like i made a mistake the other day and i

i i took the site down you know for like five minutes but i have tests that said ah and i have

you know i have tracking and so i quickly fixed it right um thanks but yeah that's that's still

three nines it's easy you know how many nines do you want i just couldn't just hang on before we

go i just want to swim out i think there's two things we need to do we need to finish off the

async story in django it's it's so nearly there but like we need to get the orm async so we've

got the full flow like we've got the full request response flow if we had the if we had a async

cursors in the orm you know we could do everything that would be good and i think we still need to

big up the ecosystem more than we do the one of django's absolute strengths is the depth of the

ecosystem and we hardly mention it and you know if you're starting out and you're choosing why is

why is django a good choice well because you you do know that there's this massive depth of

ecosystem oh no i didn't really know that i'm choosing yeah you know the core framework against

the core a fast api framework why would i choose django well it's just older and clunkier well no

But you've got all of these resources just there for you if you want them.

And we don't message that very well.

i think yeah it's just it's a discoverability problem i mean yeah right and culturally like

django itself is not going to pick favorites there which okay that's fine but um yeah i don't know as

much as right there's django packages there's awesome django there's people writing great posts

but it's still hidden to people in a way that i mean you know like like like laravel right like

Blair it's a whole separate beast for a lot of reasons but it just goes oh you want this boom

use this one right it's just all kind of right there and approved even though that we could name

10 20 packages that are kind of official they're just not actually official yeah totally so well

the steering counter is just on this the steering counter is working on an ecosystem page to go on

the site you know hopefully the top banner saying so at least there's like a you know a here's here's

Here's some of the ecosystem go and explore.

Here's where you might look.

Yeah, here's where you might look, which we haven't had previously.

I think if we can at least guide people out into the wider Django world,

we can do a lot of newcomers to the framework a big favor.

I love that.

Yeah.

Sounds good.

Go on.

You go ahead, Carlton.

I was going to ask him about his event sourcing article, but you go ahead.

Yeah, I was going to ask about that too.

All right, you go.

well god so chris the other thing i want to talk to you then is about a fence all soon which is

your new hotness you did a post the other day and it's going to be a whole series right yes yeah in

fact i'm hoping to launch the second one after this pod after we record this so like i wonder

how many will be up by the time it goes out but um yeah yeah essentially you know i uh i mentioned

about how i learned a lot of things through podcasts and roughly a little over 10 years ago

a number of the podcasts i was listening to people were like oh what's this event sourcing thing and

um i started you know listening to it following people bought a couple courses on it and was like

wow this event sourcing thing sounds really interesting the the thing that was really and

actually when i think about it it probably had a lot to do with the whole single page application

pattern because they were um the thing that really made me interesting about interested in event

sourcing was the idea of always having a fast ui because um essentially let me rewind and define

event sourcing uh what event sourcing is is um it's an application a architecture for application

development where anytime you want to change the state of the application you save an event which

essentially represents that delta into a an append only log of other events and then the

the second component of it is anytime you want to know the current state of an item you query those

the the relevant events for that item and then replay them in memory and then you know like

that's the current state and and so as a most event source applications leverage a technique

called CQRS, which stands for command query separation, responsibility separation, which

essentially means, uh, the way you save data to the database is different than how you like read

data to, to display. And so, um, so the idea is every time an event changes the state, then you

have these listeners that listen out for the specific events that can update, you know, database

tables or, uh, you know, Redis caches or a file in the file system, anything like that. So that

the user experience could be blazing fast and um and like i said that was about 10 years ago that

i started listening into that but um and you know a lot of people that i was listening to were really

smart really heady a lot more than i am and they were like you should really if you want to

implement event sourcing or if you want to use event sourcing implement it yourself because it's

not that complicated and plus you'll know all the little mechanisms and so it's like well i'm never

going to do this on a production thing. I'm going to figure it out on my own. Right. And, um, so

last year I got laid off and I was, I, uh, was in the midst of job searching. I was like, I want to

keep my, you know, um, I want to keep sharp. So it was like, well, why not? I've been meaning to do

this for 10 years. Let me like actually do it. And, uh, and so I've created my own little event

source application and learned it was such a hard thing to do for me. Um, but I learned a ton doing

it and of course i've known for over 10 years that there's a package on pi pi called event sourcing

which makes it a lot easier um and so all i have to say is uh i mean i've i've i'm now that i've

actually implemented at work and have a production or we're not quite in production yet but the

project i'm working on is event sourced and i'm just seeing you know all these other well partly

also because there are these two gentlemen, Adam Dmitriuk and Martin Dilger, who they've

been living the event source lifecycle for over a decade each, and they've figured out

ways to simplify working with it, essentially, like how to communicate with the teammates

and the business of what the events are, how things change, how you use the data, organizing

your files in such a way so that you don't step any you can have multiple developers working on

the same thing and not step on each other's toes and then you know simplifying you know essentially

kind of putting guardrails up with event sourcing so you don't get yourself into trouble and uh and

oh my god it's it's i like i hope it's like one of those things where like i've been programming

for almost 20 years this but by following the people that i've you know around me and now that

i'm doing event sourcing i'm like this is so nice i need to i need to share this with people you

know you can make your own decisions but for me this is very compelling so one thing i'm going

to ask you about it is the um the way you kind of um get rid of your model objects in a way because

you've got your models are your events and then you're going to map those to domain objects in

your aggregators in you know your functions which go and get all the events and work out what the

current state is and then those objects come out so it is really a big um kind of shift from the

model first approach it's funny well especially if you're using the event i'm gonna say it's not

it isn't it isn't in that um because the event sourcing community came out of the domain driven

design community so they are very tied to the aggregate uh idea and so therefore the django

model you know and so it has a lot of that same thing especially the event sourcing package because

you just create a class that works the way you expect it to in python and you decorate it with

some decorators and it automatically creates the events for you transparently in the background

and so if you're just doing it for like you know creating models and manipulating or whatever

it's in a way it's like not doing anything different i mean and and there is an extension

with the event sourcing uh package that works with django and i haven't experimented with it

yet so i don't know exactly how deep or how similar to django it is like i thought it said

you can use the orm and stuff but um i'm not sure yet well you could at least use the orm for um

but i don't know about the width the package but you the obvious thing to use the orm for is your

event lock is your event table right is yeah list of events here they go in that table well yeah

it's really interesting because like um because it's so like this is one of the things i'm most

interested in in a way because with event sourcing being so tied to domain-driven design

there it i feel like in the last few years they're really starting to realize hey we don't need to

use all this domain-driven design we don't need to be tied so tightly to it and so there's like a

one of the things i'm learning now is a what they call um dynamic context boundaries which is of

course a very domain-driven design way of saying um flexible uh um you know you don't have to be

tied to one aggregate, you can say, like, you can create a dynamic boundary to say, like,

these are the type of events that I care about. They might stand multiple, you know, aggregates,

or they might be less than what I would do for one aggregate, you know, like, instead of like,

you know, like, let's say, like, if you have a course, you know, in a college career,

college course, you may not care that the course changed names over the course of its life cycle,

but you might want to care about like how many um what's the max number of attendees a course can

take so you can just listen to a subset of events for that one object that's a nice example

well we're gonna we're gonna link to that i definitely i have played with it the least of

the three of us so i'm i'm looking forward to your new uh your second and how many do you

anticipate in the series is this a series you're thinking of i do i have five drafts right now i

might like, based on the feedback I get from people, like, cause there's tons of questions

about it, which I get. And I'm encouraged because like the more people ask me about it,

the better I can explain it, the more better I can, you know, help people. So I'm thinking about

maybe adding a sixth one. That's kind of like a questions I get asked during this, this whole

thing or something like that to try to, you know, cover up some or not cover up, but, you know,

answer some of those questions right yeah well gosh we're at 50 minutes somehow so i want to

quickly ask you our our infamous question about the magic wand and django do you you've listened

to our podcast so yeah you have one does something something you want to change there is something i

want to change and really in theory i could change it i just need to find the time to do it but it is

being able to stream html like that um i really seeing how much that can affect user experience

um you know i i mentioned sadly in my first talk that you know maybe we'll have that in a year and

i was like why did i even say that like i i practiced so many times not saying that but it

came out when i said it um but yeah you know like i know at one point they i think somebody was

looking into doing it at a google summer of code um but it just it hasn't been done and you know

And I think partly because they need to make the whole template engine async, which, you know, I don't know how hard or not hard that is, but it's just, it's not a priority.

So, but that's something I want.

Is this a steering council priority, Carlton?

I think somewhat, I think we'd have to see a proof of concept for that.

I think, you know, for me, okay, so the 5.2 is out the door now.

DjangoCon Europe is just around the corner.

There will be conversations now that start to happen about, okay,

so what are the two or three things you want to push for 6.0?

There's Django CSP.

There's the async story.

You know, if we could push just the ORM cursors,

that would be an amazing thing.

I think asyncfying the template language is, you know,

going to have to wait a while for it to become a sort of community project but if a community

priority but if somebody wants to push it i think that what would i do in this thing i would split

my um my response into chunks and i would render each chunk and and output it so you know if it

was a list of items i'd you know stream render one item send that render the next item send that

and it's close enough it's not streaming natively from the template but okay on the wire it's going

to look very similar yeah yeah very true but yes that would be a lovely lovely addition someone

listening will uh it needs these kind of things need somebody to sit down roll their sleeves up

and come out sick from their cave six months later with it you know sort of working with a big pizza

tab yeah yeah well chris i'm i feel like we're just getting started but i think we're we're up

on time unfortunately but um people we will link to your your talk if they didn't see it on htmx

and django which was popular at the time has had a resurgence of late and everyone i think it's one

of the best you know if you have questions about both go check it out you i was i yeah i was in

the room when you gave that talk so yeah yeah i was i was so excited to that i was very looking

forward to meeting you afterwards and i was excited that you wanted to meet me because

you enjoyed oh god thank you please yeah no no no i mean that's the great thing about this podcast

is i just learn and learn um so yeah yeah and i'm very much i'm very much looking forward to

you pushing forward the event store sourcing story in django i think that's um it's an exciting you

know extra thing we could have that extra set of tools i think so i think so especially like i said

Great user experience, great developer experience, I think.

I think it's going to be very interesting.

Well, DjangoChat.com.

We have links to everything, including all your resources.

And thanks for making the time, Chris.

Appreciate it.

Oh, any time.

Thank you.

All right.

We will see everyone next time.

Bye-bye.

This episode was sponsored by Hacksoft, your Django development partner beyond code.

Learn more about their services in the link in the description.