Is it better to have a datomic-peer separate from your Clojure app and connect to it via datomic.client.api, or run the peer as part of your app? Until now, I just ran the peer as part of my app, but I found this repo: https://github.com/galuque/datomic-compose?tab=readme-ov-file, where the peer is separate. I assume this makes it a bit more fault tolerant if you have more clients connect to the same peer. What is the general consensus around this, regarding datomic pro? For context, the scenario is that the transactor, peer, and eventual client run on the same VM or under the same VPC
@ovidiu.stoica1094 how did you end up deploying datomic? I personally feel like peer is simpler. It defintely has a confusing deployment story for a hobby programmer.
I ended up having the peer as part of the app. It makes the data feel more local. I’m on mobile now but I’ll post more details when I’m at PC I didn’t experience any issues so far
@noahmjohnstone, sorry, I just saw your follow-up question. Actually, I have them on the same server for now, as I don’t have a lot of load, but it would be fairly simple to move things to a setup like you described. The current setup is: Peer as part of my app, transactor, and PSQL storage on the same VM I own
From a bit of research, I think 1 advantage in fault tolerance is that if your client app crashes, once you restart, the peer’s cache is still intact.
I see references to this link but it is broken now: https://docs.datomic.com/on-prem/clients-and-peers.html
If your application runtime has or wants restrictions that make running it as a peer uncomfortable or impossible, client can allow that app to keep using datomic
Peers need: lots of ram and cpu, fast access to storage, lots of deps to support peer runtime. Clients don’t
But peers offer horizontal scalability that coincides exactly with your app: vast majority of what an app does is often talk to db
(But if not true for your app, maybe client a better fit)
FWIW, I'm not sure I agree w/ the statement "lots of ram and CPU" @favila. You can run a peer with as little as 64m ObjectCache (if you want).
Lots relative to an equivalent client, which needs no OC, no startup, etc. I wouldn’t run a peer in an aws lambda (let’s say) because of constraints on that runtime
I don’t mean to imply client should be your first choice. Like I said, peers give you horizontal scalability aligned with your app deployments, but to leverage them well you will have fewer, larger processes with count changing less frequently. This is not the usual way a web app is scaled with eg a sql backend, where you may have lots of transient, relatively lightweight and stateless processes
Client can give you an arch that looks more like that if you need it
Thank you for your thoughtful responses, everyone! I’ll go with a peer as part of the backend app and see from there
@ovidiu.stoica1094 Nice, how many servers did you use to deploy it? Server for app JVM + Peer lib, one for transactor (with a standby), and one for storage?