2

I have a single-page application in Node.js, React, Express and Socket.IO whose dataflow is divided as follows:

A C# server application serves the feed.js data through Socket.IO. feed.js in turn is also responsible for the turning that data around (after updating datastructures for correct presentation to app.js) and serving it to app.js to display in the browser. 

// Handle real-time incoming messages from c# clients.
socket.on('data', function (data) {
    broadcast(data, socket);
});

function broadcast(message, sender) {
    //process.stdout.write("Full message " + message.toString() + "\n");

    //...To app.js

    onChangeHandler(stock.symbol, 'stock', stock);

In this situation, under real-time load, the browser sometimes becomes unresponsive not so much to the data, but to view-like commands that affect the display. In other words, I can still see the data updating, but mouse-clicks on the browser don't get handled interactively.

The normal reaction as a "desktop developer" is to keep computation (model) separated from view by creating extra computation threads - with the view already running on its own thread. However, I have read that Node.js (and the supporting cast) is single threaded on purpose. Doesn't seem as if Socket.IO has that limitation though.

Wondering what the idiom in Node.js etc is to write real-time applications that are responsive on a web browser both in data and in GUI interactivity. An example or a link to one would help.

Rodia
  • 1,407
  • 8
  • 22
  • 29
Ivan
  • 7,448
  • 14
  • 69
  • 134
  • Any code examples? – hawk Feb 27 '17 at 19:29
  • I assume you're using promises or some other async js handling that helps you avoid blocking your client-side javascript execution. You may want to update your question to help us understand your approach on this. – Dave Thomas Feb 27 '17 at 19:31
  • @hawk sorry no I don't have code samples. – Ivan Feb 27 '17 at 19:32
  • @David no I am not! Do you have a link to a simple example that describes a problem and how promises/async solve this problem, __in the context of node.js__? I am assuming this has to happen in socket.io? Or can it happen in the rest of the stack? – Ivan Feb 27 '17 at 19:33
  • 1
    @Ivan, I love Scotch for tutorials like this. Check out https://scotch.io/tutorials/javascript-promises-for-dummies. Javascript will drive you bananas if you don't get your head around an async framework, and today's frameworks make it easy peasy. :) Here's a pretty popular question on the topic regarding client-side promises: http://stackoverflow.com/questions/5436327/jquery-deferreds-and-promises-then-vs-done – Dave Thomas Feb 27 '17 at 19:38
  • 1
    @Ivan for realtime web apps you should use websockets or long polling, there is no other way. GUI is already async, measure performance, detect bottleneck, eliminate it. Btw. it is not a programming question – hawk Feb 27 '17 at 19:38
  • Thanks appreciate the comments highly. I will look through those ideas. – Ivan Feb 27 '17 at 19:41

0 Answers0