Blog Post: Finitomata Marries Ecto

Yes, it is somewhat similar, oldie but goldie, and FSM are proven to keep a consistent state.

Instead of random requests, modifying the internal data of the application directly (as every single protocol known to me allows in a nutshell,) the endpoints in the web application should expose transition handlers only. The outmost world should not be allowed (and therefore even have an access) to modify data directly. It should be permitted to initiate transitions only.

This reminded me of CQRS pattern, where “commands” are used to create/modify data (usually not directly to the DB schema but to some sort of an “event store”) and queries are “read only”.

There is even the brand new wording invented by people who had most likely never been to the university.

Taken from the blog post you shared. I’m sure you have lots of insightful things to say, but I don’t think you need to try and negatively characterize a group of people to say them.

Definitely sounds very interesting, I will give it a try when I will have some time.

Technically, there is a [contrived] real-world example mentioned in the post, but it might be treated as a proof of concept only.

Server restarts are handled with loading all the entities in the intermediate states (in the middle of their lifecycle) as processes upon server restarts, and the migrations are handled in the same way as hot code upgrades in OTP itself.

This sounds as a great step towards data consistency, the only difference would be FSM does indeed prove the data is consistent.

That would not be so hard once using them is simpler and cleaner compared to direct calls, and our experience shows Finitomata gives that to developers. Also, a couple of weeks of using it makes people feel why it makes total sense, it reminds me of a mind shift required when one start using OTP (actor model) instead of, say, JDK (pure OOP.)

And yes, of course, I am working on the real-world example to be published.

It would be interesting to see a real world example with ecto, because while using FSM seems like a great idea, in the real world we have to deal with server restart, migrations and other things, and a FSM doesn’t seem to be most flexible approach in this case.

In general we kind of use this concept in practice with phoenix by using the contexts pattern, having some well defined functions that interact with database in a controlled manner, and we use them to abstract actions that might change data across multiple tables with respect to business logic, the only thing of course is to enforce the developer to use them instead of direct operations to database.