How to update a web page automatically right after an entry into the database? Use Nodejs?

Asked

Viewed 4,206 times

0

This is the scenario: I have a central user, the manager of a hotel who will be monitoring 24 hours the status of the rooms in real time. The rooms have 3 status: 1-In use. 2-In maintenance (cleaning). 3-Available.

The update of this status may come from one or several users, for example servants who have just entered the room to start a cleaning.

The manager needs to know what’s happening to the rooms in real time.

For this, it would be enough to refresh the Manager page, each time a servant inserted some record in the database (as happens with facebook for example). If nothing is entered in the database, the page does not need to be updated.

All I have in mind is the automatic refresh of the page, but it will happen every second stipulated, there is insertion in the comic book or not. For this I would do:

1 - within the <head></head>, use the following Meta tag

<Meta http-equiv="refresh" content="x" />

Where "x" is the time. expl x=1 (1s).

2 - Could use javascript setTimeout() for the page to call itself every x seconds.

3 - could make a combination of setTimeout() with ajax.

I think there are more modern techniques to achieve the same goal, if I’m not mistaken.

Since I’m new to nodejs, I’d like to know if it would be more appropriate to use nodejs in this scenario, to the detriment of the aforementioned techniques that I already know, and if it is the case to use the Node, how it would implement the code to update the manager page responding to the Insert event in the database made by another user?

  • I’m not a web developer, so I can’t answer with authority,

  • 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.

  • 1

    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.

  • 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

3 answers

3

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:

  1. 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

  2. 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.

  • 1

    I’m still trying to understand why this answer didn’t win several ups! Good job.

0

Hello, I believe that a good way to work with real time operations is using socket. ( for Node.js ), link access and good studies.

  • Welcome to the stackoverlow community. Make a tour and know a little of the rules and good practices, answer how it would be possible to implement this resource. (An Example)

0

Use the Pubnub. I used it in some projects and it is very fast. There is a Javascript SDK.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.