This is great! I sometimes have projects that could use SQLite, but they're just big enough to need a persistent job queue. Great to have an option for that.
I also like that there's a dashboard. That's really important when a project gets serious, and a surprising number of job queue libraries don't have admin tools.
Cookies are more appropriate for whole-site or whole-session data. There's no natural segregation of "this cookie belongs to this instance of this form". You could figure that out, but the additional moving parts cut down on the appeal.
> He just put the sessionId in the form data instead of a cookie.
This does not have the benefit of being usable across different tabs or even closing and re-opening the page.
Besides, (a minor point) shoving all the state in the cookie makes code simple i.e. don't have use URL params.
Unrelated: datastar doesn't use a two-way connection for interaction <-> updates. It uses two unconnected one-way channels: a long-lived long-lived SSE for updates, and new HTTP requests for interaction.
I didn't see guidance in the docs for routing one tab's interaction events to the backend process managing that tab's SSE. What's the recommend practice? A global, cross-server event bus? Sticky sessions with no multiprocessing, and an in-process event bus?
If a user opened the same page in two tabs, how should a datastar backend know which tab's SSE to tie an interaction event to?
It appears to be a SSE channel for each event stream returned, not one channel for all subsequent updates. So a PHP backend for instance could batch all the updates from one request, would open a new SSE channel, send the updates over that, then close it. With an in-process server like swoole or most things not PHP, you could presumably reuse the channel across requests in whatever framework-specific way makes that happen. Would probably need sticky sessions in any scaled-out deployment.
This is just what I can glean from the docs, I've never actually used datastar myself.
With DS (and HTMX) the backend is the source of truth. In the context of the blog post, the state will be made-up of: step no, file content, file path, etc. This can be stored against the session ID in a database.
So when opened on a different tab, the backend would do authentication and render the page depending on the store state.
In general, the backend must always compare the incoming state/request with stored state. E.g the current step is step 2 but the client can forces it to go to step 4 by manipulating the URL.
DS v1.0 now supports non-SSE (i.e. simple request/response interaction as well) [1]. This is done by setting appropriate content-type header.
Amazon sent me a push notification offering me a refund if I promised to destroy it. But notably it was only for one of the several such identical packs I ordered.
Of course... they will. Because there are going to be more outdated results on search engines for Date, instead of the Temporal API. But at least there's something positive coming!
The author also started taking Lumina only 3 months ago, while supposedly it takes 1–2 years to colonize the mouth. Isn't that a very aggressive timeline for severe side effects?
I've written C for years. The only time it is safe from crashes is when the code doesn't churn and has consistent timing between threads. bun has constant feature churn and new hardware it runs on all the time providing novel timings. It is very unlikely going to be crash free any time soon.
It integrates with VS Code, which suits my workflow better. And buying credits through them (at cost) means I can use any model I want without juggling top-ups across several different billing profiles.
I want to make my own music streaming app. Fix all the UI problems, improve discovery, remember all the musical phases I went through.
Unfortunately, you can't just sign up for API access to millions of songs. And the streaming apps either don't provide a playback API, or their TOS limits what you can do with it.
You don't need to do a monolithic design, and kludging things together is just fine. Start with local playback from the server or something equivalently small and work from there. If you need to background play a youtube video and forward the audio stream elsewhere, so be it haha
I've looked into this before. You might be able to pull this off with the YouTube API and Stream Rip using Deezer. Would require a bit of hacking but it could work.
I also like that there's a dashboard. That's really important when a project gets serious, and a surprising number of job queue libraries don't have admin tools.
reply