paint-brush
Logux: Alternate approach to using AJAXby@jetstreamin
815 reads
815 reads

Logux: Alternate approach to using AJAX

by Michael Mahon
Michael Mahon HackerNoon profile picture

Michael Mahon

@jetstreamin

April 11th, 2017
Read on Terminal Reader
Read this story in a terminal
Print this story
Read this story w/o Javascript
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

I just watched <a href="https://medium.com/@iskin" data-anchor-type="2" data-user-id="abb86a2b6f08" data-action-value="abb86a2b6f08" data-action="show-user-card" data-action-type="hover" target="_blank">Andrey Sitnik</a>’s<a href="https://youtu.be/UUvX7US8TSc" target="_blank"> talk on Logux</a> 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.

Companies Mentioned

Mention Thumbnail
ThoughtWorks
Mention Thumbnail
Twitter
featured image - Logux: Alternate approach to using AJAX
Michael Mahon HackerNoon profile picture
Michael Mahon

Michael Mahon

@jetstreamin

I just watched Andrey Sitnik’s

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.

Cheers!




Here are some obligatory links:Logux GitHubShout Out to the Amazing Martin Fowler & ThoughtWorks Andrey Sitnik & The EvilMartians

Comment on this Story
L O A D I N G
. . . comments & more!

About Author

Michael Mahon HackerNoon profile picture
Michael Mahon@jetstreamin

TOPICS

THIS ARTICLE WAS FEATURED IN...

Arweave
Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite
Sudonull

Mentioned in this story

X REMOVE AD