I had to spend a few days studying to find the right answer. Being able to use one technique or another does not mean that it should be used.
It depends on the situation. In my specific case I could use Polling, or long Polling, or others. But I wanted to know what the appropriate approach
and why.
So I’m going to summarize what I read, and justify the choice of SSE and not the other suggestions.
Since its inception, web applications have been created in a client/server logic, where the client ALWAYS STARTS the sending process
a request to the server and it returns a response to the client (Note that the answer may be an empty set.
Example: a client asks for some new data in the database and the server responds by saying that there has been no change
in the BD since the last requisition).
Following this logic, there was no way the server could send the new changes to the client INDEPENDENTLY, i.e.,
without the latter having first requested such action.
Time has passed and along with mobile devices, HTML5 and the high-speed internet, there has also come the appearance of the real web time,
which is a set of techniques and technologies that allow users to exchange (send and receive) information in real time. Information that can be of the most diverse types, starting from small strings like "Hi all right?" , passing through real time games, reaching up to a streaming video 4k or bi-directional Broadcasting and same real time applications as SAP-HANA with Iot, among other bi-directional comminution needs or not.
The fact is that the nature of the web is uni-directional and the needs today (2016) are different. We need real-time, bi-directional communication without having to use code to automatically make periodic requests to the server.
As the solution was not yet in hand, several techniques appeared to try to SIMULATE an open, bi-directional channel where a request can be made by the client or a response can be sent by the server, as soon as it is available. A clear example is facebook or twitter where the first request is made by the customer when we gain access to our page and after lagum downtime we receive notifications that new messages are available, without having asked for anything else.
Let’s see some (not all) techniques available to achieve this task. It is worth noting that one subject pulls the other and here at this point where one tries
SIMULATE an open channel of bi-directional communication with the server the first techniques, or most of them, start to use periodic requests to
servers and with it appeared a new problem needing a solution now - the overload of servers with I/O blocking requests due to the characteristics of multi-threaded processes. The solution came with the NODEJS where it tries to do the I/O differently tenatndo not block the process. In addition we have the help of balancing carags with the reverse proxi of NGINX to support this battle of bi-directional client/server communication. This is not the subject but here is a good video in Portuguese speaking a little theory of NODEJS
So let’s go to our alternatives of maintaining a bi-directional connection with the server:
Use the meta tag with http-equiv equal to refresh <meta http-equiv='refresh' content='5'> . This technique allows you to reload the page every period specified in the content attribute. In the example refresh will be done every 5 seconds. While it is easy and a possible solution to a specific problem, it is worth remembering that the main search engines penalize pages with http-equiv='refresh' by blacklisting them as they are considered unethical SEO practices. Doorway page.
Reading:
Link
The first alternative to http-equiv='refresh' is javascript usage - AJAX. Xmlhttprequest (XHR) gave the first illusion that was SENDING data from the server to the client through a persistent or lasting HTTP connection (client<->server), but this was not the case. Because the data was not being sent, but pulled from the server. With XHR the request is made by the client so that the user does not operate any event explicitly. The XHR tbm inaugurated the Comet model with its different approaches (Hidden iframe, XHR Polling, XHR long Polling and Script tag long Polling). In general these tbm techniques can be classified as REVERSE AJAX because they attempt to mimic a pseudo server autonomy to send data to the client. But they’re all techniques initiated by the client. These techniques may represent the ideal solution for some situations, but have some side effects, such as server overload (and here comes NODEJS and NGINX to mitigate the problem) due to unnecessary programmatic requests. Imagine a server with 100,000 connected clients and doing Polling every 5s where 30% of these receive empty answers from the server (example cited earlier at the beginning of the text). The threads were loaded and I/O were blocked unnecessarily. You don’t even have to analyze much to understand the inefficiency and difficulty of scalability.
2.1. XHR. The browser requests information from the server after a user-initiated event, without the page being reloaded. Server sends empty or no response.
2.2. XHR Polling. The browser keeps requesting information from the server periodically and the server keeps sending empty answers, until some new information is available. Compared to traditional AJAX (XHR), XHR Polling dispenses with the need for user action. That is, it can be used in situations where a page needs to be modified automatically.
2.3. The Piggyback Polling is a derivative of XHR Polling that attempts to remove requests that will generate empty answers and send additional data. No request to intervene. The client sends the request when it needs to be sent. The difference is that the answer can be broken into pieces (requested response + other events on the server). In addition to not solving the problem of overloading unnecessary requests, you need to modify the client code to respond to cases of additional data eventually sent.
2.4. XHR long Polling. As the new information is sent only when a request from the client initially occurs, this causes a delay in receiving the information from the browser, in relation to the moment it was available on the server. So the long Polling solution avoids frequent requests and favors almost immediate receipt of this information. The browser asks the server, but the server only responds when it has something to send. Then the server leaves the request suspended until data exists to be sent to the browser. Once the data has been sent the server terminates the transaction, the browser receives the result and then starts another request. Compared to Polling, long Polling decreases unnecessary use of server resources, but not 100% because requests continue to be sent to the server (perhaps unnecessarily). Following the example above, 100,000 requests would be sent to the server, although not all have immediate responses.
So let’s say 60% of customers (60,000) only get updates 3 times a day. If they stayed connected using long pooling there would only be 3 + 1 transactions a day for these customers. In the previous models there would be transactions at each time interval established. This is a good bi-directional communication strategy and there are some approaches to implementing it. They are:
2.4.1-Forever Iframe
2.4.2-Multipart XHR
2.4.3-Script Tags with JSONP
2.4.4-Long Living XHR
Leituras:
2.5-Although the techniques seen previously work, and they allow duplex or bi-directional communication (client->server / server ->client), they are only changes of a technology that was not created for this purpose.
That’s when HTML5 comes on. This new version of HTML brings embedded in itself (native) 2 approaches or technologies that allow bi-directional or uni-directional communication (server -> client) without having to change anything.
Are they:
2.5.1 - SSE -> Server-Sent Events. Unidirectional query (server->client). Easy implementation.
2.5.2 - Web SOCKETS -> Full Duplex Web Sockets. Bi-directional consultation. Implementation a little more laborious.
Leituras:
I’m here because SSE answers the original question of the post. I wanted one-way communication from the server to the client.
No need (in this scenario) to overload the server with requests that could return empty queries or without any
change since last query.
I’m not a web developer, so I can’t answer with authority,
– zentrunix
in fact my approaches (1, 2 or 3) solve the problem. But do refresh the page even if nothing was changed in the comic, I think it’s kind of funny. I wanted to know if nodejs is the correct alternative without gambiarra, and how would this implementation.
– zwitterion
Refresh is gambiarra anyway, no matter what you use on the server. Monitoring by the browser does not cease to be "gambiarra" too, despite being fashionable. If you still want to do it through the browser, that’s exactly what @Joséx does. stated, the server side makes no difference, the problem is the client-side technology, and he listed the alternatives in the comment above. Ideal even would be a native application.
– Bacco
Good do not use Node.js but I had a project at work more or less in this features and what I did was I used php I created the queries I wanted and yes I also used meta to do refresh, maybe it would be more effective and easy only use php embedded in html
– luis lota