GenStateMachine are likely not the best fit for a machine configured at runtime, as they represent states and transitions with compiled Elixir code.
You could use them with an approach where they implemented a “generic machine” that interpreted the runtime configuration…
Some things to think about when picking implementations:
- how durable is state? Does it survive the BEAM rebooting?
gen_statem doesn’t have any baked-in persistence, since it’s used for a lot of in-memory only things like tracking connections etc. Other solutions like
ecto_state_machine are explicitly built on top of persistence.
- can the machine initiate actions, or is it purely reactive to inputs?
gen_statem includes multiple timeout mechanisms and represents state as a running Erlang process. This can be really powerful for handling situations like “request a driver, then notify Operations if one isn’t assigned within 10 minutes”. On the other hand, something like
ecto_state_machine only runs code when a state transition is happening.