Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL

The Flux terminology is confusing to me. It looks like the Observer pattern to me.<p>* Stores contain Observables<p>* Components (or Views) contain Observers<p>* Actions are Proxies<p>So the article is basically saying the Observer pattern is scalable, but uses the buzz-phrase &quot;Full Stack Flux&quot; instead. To make it even worse it is only a theoretical application of this pattern.

I suppose there is some value to this as a thought experiment but pretty much every tier in that architecture has breaking flaws. The most relevant being that anything that has an audience of 1 million users cannot run on an architecture that has single points of failure.

AFAICT, Facebook engineered their client side code around Flux in order to eliminate two-way data binding in their user interface code, which leads to all sorts of issues. I don&#x27;t imagine they push the pattern into the server. Their relay stuff still relies upon a smart data tier which understands a query language called GraphQL.<p>I <i>definitely</i> don&#x27;t think they considered implementing a dumb dispatcher and store layer on the database server using stored procedures. (This seems terrifying to me, I don&#x27;t see the upside.)<p>It&#x27;s an interesting experiment but I think this might be an example of being too aggressive in trying to generally apply a design pattern that was motivated by a specific problem.

Great post, but has this design been implemented to <i>effectively</i> handle something close to a million users ( or even 100k and show that no part is overheating) ?<p>As in every new and complicated design, i&#x27;m a bit skeptical of rules of thumb calculations. You never know what the wrong latency issue at the wrong place can do...

GameRanger has six million users, tens of thousands to hundreds of thousands of whom will be active simultaneously. His chat problem involved has moderate fan-out.<p>Scott Kevill does it on a single machine (last time I checked) with hand-rolled C++ and close attention to the details of how the Linux networking stack works.

Do you have anything like this up on github?

This could be the inspiration for a great open source project, and become something that could easily be deployed to a cloud hosting platform. Basically it&#x27;s the same as firebase, but with some of the react and flux goodness like server side rendering. Or somebody could package this as a product.

One problem I have with using postgres listen&#x2F;notify as a general purpose message queue is that it requires polling (At least that was the case when I last looked at it). Of course you can use a blocking wrapper around the polling code but it still causes unnecessary roundtrips.

As far as I understand, this design is based on similar goals as the Meteor&#x2F;MongoDB project - instead of reading oplog, you listen for notifications.<p>I wonder how would Meteor be better than this proposal given that both are node based.

OT: as someone trying to learn my way around Erlang&#x27;s OTP framework, I&#x27;d be interested in a walkthrough of an OTP based system compared to this.

Anybody know how to efficiently make smexy graphs like that? Did Adobe have a hand in their creation?

This is so interesting - keep up the good work!