I would like a gallery of projects currently using Electric ⚡️ Is there such a list?
👋 I was a bit frustrated by the current way of tracking changes with the "dirty" atom when using Postgres + Electric, although there are better ways / more performant alternatives, they often require extra infrastructure. To bridge the gap, I made pg-realtime. A simple Clojure library to create "live queries" for PostgreSQL - you provide a SQL query, and get back an atom that automatically updates whenever the underlying data changes. It is an early release, so not battle-tested yet,. I'm hoping to get some feedback & suggestion on the API, the approach etc. If you want to try it out, it should just work with your existing PostgreSQL database. Heads up, it will create new objects in your DB (triggers & functions). https://github.com/jazzytomato/pg-realtime Example usage with electric:
(e/server
(let [status (e/watch !status)
sub-id (str user-id "-orders")
!orders (pgrt/sub sub-id db "SELECT id, status FROM orders WHERE user_id = $1 AND status = $2" {:params [user-id status]})]
(e/on-unmount #(pgrt/unsub sub-id))
(dom/table
(e/for [{:keys [id status]} (e/diff-by :id (e/watch !orders))]
(dom/tr (dom/td (dom/text id)) (dom/td (dom/text status)))))))nice work
so it’s just a regular atom? nice, it should work out of the box with my Ripley library as well
one comment about the new objects, many apps have a separate pg account for doing DDL changes and regular query/update operations (that doesn’t have permissions to do schema changes), so it would be good if you could pre-create all the triggers with some function.
Very nice. I’m wondering if it wouldn’t be more flexible to have the basic mechanism just be a callback function. If it is a callback, you can still get updates into an atom (assign the callback to be a reset!), but it would also give the possibility to use m/observe, which can then handle subscription mounting and cleaning up afterwards (`unsub`).
yes just a regular atom @tatut, I'll check out Ripley, I haven't come across it before! The new objects are created with a separate pg account. The one used when starting up the system, i should clarify this on the readme.
@henrik I'll have a think about adding an option for a callback instead of an atom
Sure. I mean, it’s still perfectly possible with the current API: you just do the add-watch step. But I imagine that in this case, the atom isn’t strictly necessary and just ends up being busywork for the GC, which probably hints at a callback being the more general solution.
The case for m/observe is that it comes with resource cleanup semantics, and is also useful if you want to do other things before hitting the Electric layer. Eg. like stack other transformations on it with m/eduction etc.