So the usual way of datahike (let's call it embedded) runs in your main applications process. It is the only writer to your db. This is fine if your application is the only writer. If you want to write from another process e.g. resetting an account from the repl as an admin this will result in a bad time as you have two writers (i.e. two processes). The same applies for 0 down time deploys. You have to be careful. Long story short only one process can write to datahike. If you want to processes to write you need to use distributed mode. This mode ensures one writer on your behalf. You can use a remote peer. Which means your application is thin client and dispatches all the work to the server.
:remote-peer {:backend :datahike-server
:url ""
:token "securerandompassword"}}
Or you can use a single writer so each instance manages it's own reads but the writes are centralized and the connection are updated when writes happen.
:writer {:backend :datahike-server
:url ""
:token "securerandompassword"}}
Distributed mode creates a http-server that uses a macro to mirror the datahike api and then accepts the requests and does the writes for you. This basically means you need your current application server plus another for server for the datahike-server you could also build a docker image with your jar and the datahike-server jar in the same images.
This is obviously a lot of admin but once you have users and you need to update data with but build APIs it because necessary.
So the question: Is why can't we get the routes from the server namespace and expose them into my running app so it becomes the server?
Excellent question. That's what I want to do. It's not as easier as I thought because adding it to the main library breaks the graalvm/native image compatibility. So i need to first refactor the server so you can have the routes in the main lib and then make your own server the datahike server.
TL;DR if you want to write to datahike from more than one place. We need to refactor the repo to make this not painful. Thanks for taking the time to write this, Alek.
This is a note to myself: When there is more than 1 process making transactions, restarting dyno or pushing updated codebase will not reflect changes made in a process if another process has more recent transactions. A process overwrites another when it has more recent timestamp (which means transactions made by other processes are effectively "gone").