Hacker News Reader

Comment by weeksie | Hacker News Reader

Interesting. I still think that the Flux (specifically Reflux) is the way to go with React. I know this solves a different issue, but I've been itching to build a truly unidrectional data flow application with something like a Rails REST API and an Elixir socket server with a Redis queue in between.

All requests go to a REST API which only returns head responses, and shoves the actual data response onto a queue. The websocket server reads off the queue and publishes the response to connected clients.

On the client side it's all actions and dispatchers and react components. Keep meaning to write an in depth blog post about that when I get the time.

View on HN

> All requests go to a REST API which only returns head responses, and shoves the actual data response onto a queue. The websocket server reads off the queue and publishes the response to connected clients.

This reads very similar to how IMAP is defined (it's not a request/response protocol).

And Websocket seems like an overcomplication of the system as you need a WS-compatible server and broker, it would probably be simpler to use SSE[0][1]. See http://matthiasnehlsen.com/blog/2013/06/23/angularjs-and-pla... for an example of SSE+occasional HTTP calls.

The big difference, of course, is that such a system is not really offlinable, the application is basically frozen as soon as the connection is lost.

[0] even if MSIE doesn't support them, they can be polyfilled even in IE7 and old android browsers

[1] plus SSE has native support for server-configured reconnection timeout, event-ids and custom event types, all that in an ASCII-based format

Nice. I hadn't played around or even heard of SSE.

I'm not _as_ worried about offlinable, to be honest. This post just tickled that part of my brain that had been thinking about React.

> Nice. I hadn't played around or even heard of SSE.

Yeah SSE is one of the most interesting APIs people have never heard about, everybody jumped on WS but for many use cases SSE is more than sufficient, much simpler to deploy and use and a much simpler upgrade path from polling.

In theory it could be at least partially offlinable, so long as you push a UUID or similar with each request you send to the server. You can then immediately push the expected response into the message queue, which would update your UI, and on receiving the real response update the relevant entry in your local cache of the data store.

The Flux+Swarm TodoMVC was mentioned in the post. These are orthogonal things. https://github.com/andreypopp/todomvc-flux-swarm

I built a websocket server in Go that pulls messages from Redis and shoots them off to subscribed clients, similar to what you're mentioning. https://github.com/johnernaut/goatee

Anywhere I can keep track of you and your progress? I am looking at an almost identical setup (with Elixir) and need to get some inspiration.

AFAIU you're doing Twitter right - I mean your last tweet. Easy follow.

They are different things. Have you used them?

Reply on news.ycombinator.com