(Re)Actors
TBH, I am a big fan of actor- and reactor-like programming patterns (also known as Finite State Machines. While you’re not strictly required to use reactors and might be able to get away without them – they DO provide several very substantial benefits.
Asynchronous Processing for Finite State Machines/Actors: from plain event processing to Futures (with OO and Lambda Call Pyramids in between)
January 11, 2016 by • “No Bugs” Bunny
Quote:
With 'callback pyramid' it is not easy to express the concept of 'wait for more than one thing to complete' , which leads to unnecessary sequencing, adding to latencies (which may or may not be a problem for your purposes, but still a thing to keep in mind).
Another Quote:
Don't even think of converting all of your code to a so-called Continuation-Passing-Style
Filed under: Book: D&D of MOGs1st beta of Vol. I-IIIOn.System Architecture(Re)ActorsOn.ProgrammingProgramming Languages
Read moreServer-Side Architecture. Front-End Servers and Client-Side Random Load Balancing
December 28, 2015 by • “No Bugs” Bunny
Quote:
[about Round-Robin DNS] one of these returned IPs can get cached by a Big Fat DNS server, and then get distributed to many thousands of clients
Another Quote:
As a rule of thumb, Front-End Servers are a Good Thing™
Filed under: Book: D&D of MOGs1st beta of Vol. I-IIIOn.System ArchitectureDistributed systems(Re)Actors
Read moreClient-Side. Client Architecture Diagram, Threads, and Game Loop
December 14, 2015 by • “No Bugs” Bunny
Quote:
To have a good concurrency model, it is not strictly necessary to program in Erlang
Another Quote:
Most of developers agree that FSM-based programming is beneficial in the medium- to long-run.
Filed under: Book: D&D of MOGs1st beta of Vol. I-IIIOn.System ArchitectureDesign decisions(Re)Actors
Read more



