I did a quick check for dependency behavior with #babashka-neil. TL;DR: • neil dep add com.hyperfiddle/electric installs version v2-alpha-263-g89da9d11 • running neil dep add com.hyperfiddle/electric again when an old clojars-alpha version is installed, installs the latest clojars alpha version --- Details: 1. neil dep add com.hyperfiddle/electric installs v2-alpha-263-g89da9d11 2. but neil dep upgrade com.hyperfiddle/electric doesn’t seem to be able to update an old electic version to the new version. 3. running neil dep add com.hyperfiddle/electric again when an alpha version is installed installs the new version. neil 0.1.60 changed the default dep add behavior to add the latest unstable version of no stable versions are found. But nep upgrade hasn’t gotten the same behavior. So using neil dep add seems to give the latest recommended alpha version.

what?

oh, sorry, that probably read like it was totally out of context. i was thinking that the recent change in neil behavior might be useful for electric users, since it matches which electric version you want people to use.

what is neil?

Neil is a babashka CLI for installing and updating Clojure dependencies in deps.edn projects: https://github.com/babashka/neil

you’ll need a cross region cloud database like say google spanner not xtdb - it’s not trivial

fack x)

You can use a single central document/tx store for xtdb and deploy the electric instances to the edge. xtdb will store the document and tx logs on each node so you would only have to go to the central db for writes or cold reads. If you're using http://fly.io you should be able to just deploy a single region postgres and use that. you can get help on setting up your xtdb config in #CG3AM2F7V, you'll probably want to utilise checkpointing or the electric nodes will be slow to start

@U7KPK060K please say more and/or ELI5 without XTDB prior knowledge and i will add this to our docs

I'm far from an expert on XTDB so @U899JBRPF correct me if I'm wrong about any of this, but here are the basics as I understand them: • an XTDB deployment consists of one or more Nodes, a document store and a tx store (immutable transaction log of changes to the doc store). You can choose different places to persist these, by default I think they both get stored on the node using rocksdb, but you can also persist them outside the node using one of thehttps://docs.xtdb.com/storage/ • the XTDB nodes usually run in the same process as the host application (in this case electric) and each node connects (remotely via http/jdbc etc or in memory/local disc) to the doc/tx store • when a node starts up it will retrieve a copy of the indexes and store them in memory. queries made on the node (e.g using xt/q or xt/entity) will be executed against these local indexes (though I'm a little unclear about this because I know you can configure the amount of memory available to xtdb for local indexes, so possibly there are cases where the query will have to wait for the node to fetch data from the central store). • Deploying electric to the edge is probably beneficial if the app isn't write heavy, as each edge node will effectively cache the db and trips to the central store will only need to happen when doing writes or reading recently stored data, but electric does encourage frequent writes for realtime applications and in those cases it might be better to have the electric node close to the doc/tx store There is more info available here (and in the guides/tutorials on the same site) https://docs.xtdb.com/concepts/what-is-xtdb/

I just figured XTDB is a drop-in and free replacement for Datomic, is this assumption flawed

Maybe I can just go with Datomic Free, and this will be simpler significantly

datomic free is probably the easiest possible thing

It's still not quite trivial with docker, you'll need to configure a persistent disk for the state if you haven't used Docker before. (IIRC, i can barely keep the container stuff straight) The dead simple thing is to use digital ocean, ssh in, mount persistent disk from digital ocean admin panel, install datomic, run app

Once you outgrow that you can dockerize it

Okay cool. So i can copy the electric-starter-app to my server, link in datomic, and should be good to go?

yeah, make sure the hard disk doesn’t get erased when the box restarts

do you need cloud? we need it because our demos are accessed worldwide; digital ocean by ssh is perfectly acceptable

you can also look into railway, http://render.app, google cloud run - these all involve learning docker, which with XTDB may not be trivial

really figuring how how to run XTDB in prod is the first thing to do, this will determine your options for hosting

I see, I don't need cloud. I just thought it was the next logical step. But if db is whack++ then I can just do a singular local instance based in NYC area or whatever the digital ocean cluster is

post the snippet, did you forget e/watch?

possibly! ty for the idea. will check.