Releasing https://github.com/mpenet/drip โ a transactional job queue for Clojure backed by your existing database (PostgreSQL, MariaDB, SQLite). No external services, no message brokers. Jobs enqueue inside your own DB transactions โ commit means the job is submitted, rollback means it disappears. That's it. - Transactional job insertion and atomic claiming - Priorities, scheduling, retries with exponential backoff - Unique job constraints, queue pause/resume - Per-kind retry policies and execution timeouts - Periodic jobs, outbox pattern - Virtual threads (Java 21+) - Web UI and CLI/TUI included ... and more https://github.com/mpenet/drip
This is fantastic. I've been looking for something just like this. Definitely going to give it a try. ๐
I am eager to get some feedback, let me know if you hit rough edges
It'll take a while before I get to it, but will do!
๐ Well done! Great docs, Web UI and CLI - I'm impressed. I've made https://github.com/msolli/proletarian/, which has more or less the same value proposition as Drip. It has fewer features and fewer dependencies but the same general shape. Nice to see more competition and choice in this space! It's good for the community and ecosystem.
Hi! I had no idea about proletarian, I should have done my homework. I will definitely check it out. Thanks for the kind words.
It's good that you didn't, then you might not have made Drip! ๐
my laundry list was basically https://riverqueue.com/#features (plus/minus some things). I shamelessly re-used their schema for pg basically
I also implemented at least 3 versions of something quite similar at work.
this is great... something that many people make ad hoc implementations of in their projects, great to have a drop in library
Cool. Looks like this shares some properties with https://docs.dbos.dev/?
I'd say it's complimentary, dbos is a durable workflow execution engine afair
In my context I often have some queue (drip like) that ends up being consumed out of band that will then cause scheduling of durable workflows, sometimes I have to wait some condition to be met to allow scheduling for instance. workflows are a different thing. For me they are about ensuring a unit of work will run to completion/failure, with possible interruptions for whatever reason (network, reboots etc), and they can take ages to run to completion potentially (ex deploy a vm, then transfer a multi tb volume on new host, etc etc). You can build a workflow engine on top of something like drip, but I don't think I would do it this way (folks in river did, but I don't agree with their approach).
temporal and dbos are more related to each other
A coworker recently started a temporal inspired lib implemented in clojure if you're interested: https://github.com/mping/intemporal
Temporal is really impressive otherwise. If I could choose I would use that for the workflow execution part.
Thinking about the outbox pattern as a mechanism for causing extra effects after some transaction was what led me to discovering Temporal and durable execution as a concept (and similar engines like dbos, restate, resonate). Thanks for the explanation and pointers, will take a closer look soon.
Nice work. Here's some more prior art that I've considered using in the past. Not exactly "drop in" or even Clojure native, but comes with a different set of tradeoffs. https://github.com/pgmq/pgmq
https://clojurescript.org/news/2026-05-07-release
After 10 years, it's finally time (warning it's preliminary). https://github.com/day8/re-frame2
i kind of wish that the spec was a single file i could copy into an agent without cloning. like a skill file? but that would be too big/disorganized for the repo source... im also intrigued by the build-in handling of queries/invalidation. query invalidation is a key part of frontend for me
@thmorriss If you need re-frame query cache & invalidation you should look at https://github.com/shipclojure/re-frame-query Has support for that, infinite lists, polling & more
This is such a great read! If nothing else, just the {:doc :platform} initial map is huge
I'm starting 04-views-and-frames now
Currently it feels tha re-frame2 by default isn't aimed at other react wrappers compatibility, ex uix since views are expected to return hiccup and a view injects subscribe whereas in re-frame1 there would be some extra plumbing to get subscription reactivity, see https://github.com/pitch-io/uix/blob/master/core/src/uix/re_frame.cljs
Note: I haven't finished reading the guides so this might be a misinformed opinion
@ovidiu.stoica1094 I've tried to keep the spec as general as possible but because of time constraints it has ended up a bit too biased towards Reagent and ClojureScript. But I have no doubt whatsoever that you could get an AI to bend the spec in another direction pretty easily. After all I want this to be the base for people to "Roll your own" ... even JS and Typescript ones. But I wouldn't do this just yet. There is still a bit of churn. Two more days should have it stable (famous last words) The reference implementation (Reagent) is already functional which means the specification is getting close to complete. My 20x max plan is coping a beating.
@asier.galdos It's already worked. I have a working version. And only 7K lines of code :-) For context, the original re-frame was about 600 lines of code) plus poor tests. Mind you re-frame-2 includes an entire state machine implementation, routing, SSR, v good JVM integration, etc
Scary. Thanks!
Since this is a spec-driven, AI-focused rethink, you may want to look at things like Lemmafit and the underlying dafny-replay. It seems to me that the reframe model should be amenable to the same concept of small proven kernels for the state engine that would allow the developer to write invariants on the application state and the actual application state traces could be used for post hoc analysis/verification of application behavior against a spec similar to PObserve. https://midspiral.com/blog/introducing-lemmafit-a-verifier-in-the-ai-loop/ https://midspiral.com/blog/building-a-react-app-with-formally-verified-state/ https://github.com/metareflection/dafny-replay https://p-org.github.io/P/advanced/pobserve/pobserve/
"AI-oriented" does this mean there's no existing library?
looking at the repo, i think the answer is "yes". there's no library, merely a specification that each user's "AI" will now attempt to reimplement
There is no existing implementation, no. Soon.
I wouldn't burn tokens on it just yet.
Reminded me this https://www.youtube.com/watch?v=xE9W9Ghe4Jk > -- You wouldn't want to publish that. Wait, where are the docs? You don't even > have a readme. > -- I don't even have a repo. Congrats @mikethompson you have a repo and you have a readme. Seriously, I'm very excited.
README driven development has worked for me before. Let's see how we go.
any time Pratchett is quoted is a great time ๐
I think I see it. Iโm sorta winging it like this for a zero + refx setup. Most of my initial time is setting up docs for the ai though lol. Making it REPL-able with next to no effort, testable from clj only, and adding some good utilities (like the ability to REPL record in a vector the values of a sub) is taking my time right now. But, I think it'll pay off
Love it. If this works my views on AI are gonna change drastically.