2 ms·

Thank you for sharing. I was hoping you'd eventually publish an article on Yakread's ranking model, I remember you mentioning it tangentially in one of your tal

Thank you for sharing. I was hoping you'd eventually publish an article on Yakread's ranking model, I remember you mentioning it tangentially in one of your talks. Love how concise the code is.

jacobobryant 1y ago
It's a fun part of the code to work on for sure :). I started trying out datastar in another part of the app by the way, mostly for the frontend signals so far e.g. https://github.com/jacobobryant/yakread/blob/8a61443235d1f6f55d0fa69c5ca98bd28115ef73/src/com/yakread/lib/ui.clj#L146 https://github.com/jacobobryant/yakread/blob/8a61443235d1f6f... 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.
- andersmurphy 1y ago
  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.
  - jacobobryant 1y ago
    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.

Thank you for sharing. I was hoping you'd eventually publish an article on Yakread's ranking model, I remember you mentioning it tangentially in one of your talks. Love how concise the code is.

jacobobryant 1y ago

It's a fun part of the code to work on for sure :). I started trying out datastar in another part of the app by the way, mostly for the frontend signals so far e.g. https://github.com/jacobobryant/yakread/blob/8a61443235d1f6f55d0fa69c5ca98bd28115ef73/src/com/yakread/lib/ui.clj#L146 https://github.com/jacobobryant/yakread/blob/8a61443235d1f6f... 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.

andersmurphy 1y ago
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.
- jacobobryant 1y ago
  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.