Since this app isn't collaborative it's not clear to me if there'd be any benefit of doing any long-lived SSE vs. just sticking with the request-response model I'm already doing with htmx. Also since various parts of the app do take 100 - 1000ms to render/query, so rerendering the whole page on any change I don't think would be a good fit. But even just having the signals part baked in is pretty nice.
Yeah seems super fun. I've added it to my source reading list.
100% you can just do request response. What's nice is it can still be used to notify a user. Say they make a request that kicks off a background job, you can return UI that says the job has started, keep the connection open (cheap with v threads) and then when the job completes return the notification.
I honestly, wouldn't go down the CQRS road unless you are planning on adding multiplayer/coop/global notifications.
For the slow queries in a CQRS context I mostly solve that with caching. You can of course get fancy with datomiclike transaction queue/notification/listen fine grained pub/sub if that's your thing.
Yeah that makes sense! Once I'm done with the rewrite I'm planning to go through the app and convert the remaining htmx portions to datastar--should be a decent learning exercise.
I'll see if I can go back and figure out where I lost track of things. I believe it was right around when making the message entry box functional. I ended up having to dig into the repo to see what I was missing.
Good to know--I'll do another run through the tutorial sometime and see if I notice anything. I know there are a couple things I need to update in the example repo at least.
I applied 9 times and never got an interview. I've moved on from entrepreneurship (for now?), but would love to know what percentile I'm in for consecutive rejections as a consolation prize ;)
