I just watched Andrey Sitnik ’s talk on Logux it addresses the issue of concurrency collisions that can occur in large complicated systems due to the increase in the number and complexity of ajax calls being made. He has offered an alternative solution with Logux.
The coordination of many client actions to many servers into a single data store is a daunting task. Maintaining the synchronicity of changes being made to the data in the correct order offers a host of problems. Andrey points out that the historical problem exists between the state-machine running on the client and the MVC running on the server. The no man’s land in between has been largely navigated using AJAX calls.
As systems grow and features get added these calls to the server become tedious and prone to error not to mention chatty. This is where Logux comes in.
Log files exist both on the server and on the client. We log all kinds of actions on the client and every scrap of execution on the server. The premise of @Logux_io is to make the log a first class citizen of the application. In my mind, unifying the logging of all aspects of the application nails down the tenants of event sourcing as outlined by Martin Fowler.
To ultimately use it as a source of truth for the activities passed between the client and the server. This will all occur using the immutable update pattern that Redux implements. It seems to me to naturally extend Redux to have a artifact useful for the coordination of the system itself. The log will be well defined and each action within the stack will have an atomic identifier outlined by the paper CRDTs: Consistency Without Concurrency Control published in 2009.
With the concept of self ordering atomic actions baked in for both the client and the server then it would become trivial to commit those actions in the order that they occur beit real time or when coming back online.
There are a number of challenges that have been at least roughly addressed concerning the whole realm of date-time gotchas that almost every large scale application has to face anyway. Andrey seems to have narrowed that down and ironed out the details concerning the agreement and coordination of those key points as well as handling the dead on the line scenario by maintaining a heart beat between the server and application.
All in all, it was a great talk by one of the EvilMartians .
Here are some obligatory links: