cdodev / design Goto Github PK

Regarding the following:

The main difference of a functional app is that we don't mutate state directly. In fact current state is derived entirely from events that have been observed to happen, so we should be able to recover any state by replaying the events we have seen. The stream of events that has occurred is the golden source of data in the system and can be folded down into any other data source to express state.

I am hesitant about the part that I highlighted. In theory, that is true. In practice, recovering events that were saved sometime in the past is incredibly hard, as we already know from our experience at Fynder. There are some workarounds such as keeping state snapshots, or attempting to have some kind of migrations for events themselves, but these are just ad-hoc kludges and they can't really be generalized in a reliable manner.

I suggest we leave out the idea of “recovering any state by replaying the events we have seen”. We should have events, yes, but consider them “messages” as in a “message passing”, and use that to drive changes to the UI in real time (say, through a PubSub API over WebSockets), but those messages are never stored in a database, they just exist in memory and distributed over the network until they are not needed anymore.