Why is it “distributed GenServer”? I don’t see any “distributed” here, it’s more like “durable” or even “persistent”
General idea of durable state machines is nice and very useful, but implementing it with GenServer semantics is a dead end. I think that it is a bad pattern and a very misleading approach.
If I were to make this library a good one, I’d think about it like this:
DGenServer does not work as a GenServer in any sense.
You can’t safely restart this server in order to reset the state, which is a big deal when it comes to how OTP approaches failure safety. Then, performance is completely different. Then, timeouts handling is completely different. Then, interface is completely different (postponing side effects, etc). Then, use-case is completely different. In the end, any comparison with GenServer is wrong and is bringing more harm than good for users who may think that they can just replace their use GenServer with use DGenServer and go on.
So, I’d change the name to something like DurableStateMachine.
Messages
Even if you rename it and change the interface, there is still a problem: input comes from messages! That is very bad. Most of messages are temporary and contain temporary data like pids, references. Monitors and links result in temporary data. And you save them.
So, I’d separate the state machine from BEAM’s message boxes and remove this process-based handle_info, handle_call, etc. semantic completely.
I’d have just handle_input with manual state handling, without any processes involved.
Diff
You do diffs to not save the whole state, but your diff implementation is best effort. If you give user the ability to handle the update themselves, it would bring a huge performance benefit in some cases
Batching
And it would be nice to have the ability to batch the changes, because FDB works much more efficiently with one transaction changing 100 keys than 100 subsequent transactions changing 1 key
So, it would look something like this
defmodule MyStateMachine do
use DurableStateMachine
@impl true
def init(id) do
{:ok, %{id: id, status: :off, calls: 0}}
end
def switch(state) do
with {:ok, state} <- handle_input(:switch, state) do
Logger.info("Switched #{state.id} to #{state.status}")
Logger.debug("#{state.id} received #{state.calls} so far")
{:ok, state}
end
end
@impl true
def handle_input(:switch, state) do
next_status =
case state.status do
:off -> :on
:on -> :off
end
next_calls = state.calls + 1
# Only status is saved, because `calls` is for debugging
DurableStateMachine.set({state.id, :status}, next_status)
{:ok, %{state | status: next_status, calls: next_calls}}
end
end
# And used like this
id = # Some ID here
{:ok, state} = MyStateMachine.get_or_create_new(id)
{:ok, state} = MyStateMachine.switch(state)
IO.inspect state.status
But this functionality has no batching. If you were to add batching, you’d have to make the transaction explicit and it would make the whole need for library obsolete.
