6

We're looking for a simple way to continuously update an HTML table (SPA) to display "orders" received. Currently, we are having to refresh the page every time we want to see the new orders. With my limited front-end knowledge, I can think of 3 ways to do it. I would appreciate advice on the best approach:

1- Making AJAX requests on a regular basis (every 10 seconds?) and then having a JS framework (Vue or React) update the table.

2- Using WebSocket (instead of HTTP) to enable server to push data when such new orders come in.

3- Using a notification service: back-end sends a notification to a topic that client browser is subscribed to. That triggers some code in front-end framework to request new orders from server. Is that feasible?

Again, I have very limited knowledge on how front-end frameworks (VueJS, React) can or can't do. I don't want this to become a full blown project. We're just looking for a simple solution to a (hopefully!) very common use case. Thank you.

Bas
  • 211
  • 1
  • 12
  • Go for AJAX requests. Nothing easier than that. – Aer0 Dec 17 '19 at 14:15
  • You asked for best solution - best would be use of websockets because they are less havy for server and only if something changes request is being send. So you won't kill server while 1000 users will send over and over ajax request. – Zydnar Dec 17 '19 at 14:22
  • first option is called polling. Best chance to have the server blocked for too heavy traffic. I'd go for websockets at all. But this is not related to frontend development. It is a backend issue. Frontend will handle just the presentation layer – Lelio Faieta Dec 17 '19 at 14:47
  • there's a 4th alternative being basically to trigger a page refresh from javascript instead of user action in the browser. It will have the same impact as what you're doing now, only will it trigger more often than doing it manually... it's the non-ajax version of your first proposition. – Laurent S. Dec 17 '19 at 14:48
  • Does this answer your question? [In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?](https://stackoverflow.com/questions/10028770/in-what-situations-would-ajax-long-short-polling-be-preferred-over-html5-websock) – Lelio Faieta Dec 17 '19 at 14:59
  • @LelioFaieta, backend architecture is serverless (AWS Lambda + API Gateway) so no issues with blocking. – Bas Dec 17 '19 at 22:08

3 Answers3

3

It all depends from how many web client instances you expect to be running at any given time.

Polling for data changes even when there are no changes, and doing it from many web clients at the same time could result to a DoS attack to you own infrastructure.

WebSockets or even Server-sent-events should be a more reliable solution.

Implementing the client side is trivial, but doing the actual change detection on the back-end side involves some kind of versioning on your data. Hashing on the database row level should do the trick. There are more sophisticated solutions too.

Can you elaborate further on your use case?

Christos Lytras
  • 36,310
  • 4
  • 80
  • 113
George Metsis
  • 107
  • 1
  • 3
  • Doesn't have to involve hashing; you could simply push new data whenever for example the `OrderManager.addNew` method is called on the server. – nicholaswmin Dec 17 '19 at 15:20
1

As you mentioned, there are two ways mostly. Most of the applications I have seen if you are using react js (since i dont have any idea on vue), it's fast for rendering data (updating dom - it fits your case).

So for one of our application also we used polling of 15 seconds and it was performing well. In this case what you can do is basically if the tab is not active then you can turn off the polling by checking visibiltyState (chrome and firefox it works perfectly) and you can pause the polling when the tab is not active using this thanks to @oriol this works very well.

As discussed an other good way is socket. You need a backend like nodejs or golang where you will have rooms where you need to emit the data and it will be listened in the front end using some libraries called socket-io

And I have heard of using appollo graphql but never tried it, you can check that also.

I think this will give a better understanding of the problem.

So I think if you can afford in basis of data volume and time, then it's easy to implement the polling with setInterval else mostly everyone suggests sockets.

So I think for a better solution socket will be good, but easy implementation, easy to afford then setInterval from client side.

Christos Lytras
  • 36,310
  • 4
  • 80
  • 113
Learner
  • 8,379
  • 7
  • 44
  • 82
1

EDITED ANSWER

As mentionned in the comments, Websocket is really the way to go performance-wise, if you plan on having many concurrent requests. Lelio Faieta linked an interesting post in the comments about long polling performance: In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?

OLD ANSWER

If you have to refresh the data every 10 seconds, ajax calls are fine as mentionned in the comments above. This will be easy to implement with jQuery or more advanced frameworks as you mentionned. Please find below a real short code snippet calling an API every 10 seconds and updating the first row of a table, for example.

window.setInterval(function() {
  $.getJSON("https://reqres.in/api/users?page=2", function( data ) {
    let length = data.data.length;
    let index = Math.floor(Math.random() * length);
    $("#myTable td:eq(1)").html(data.data[index].first_name);
  })
}, 10000)
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<table id="myTable">
  <tr>
    <td>Name</td>
    <td>Value</td>
  </tr>
</table>

As you can see this is pretty straight forward to implement, apart from your own data logic needs.

However, you might have incentives to use Websocket instead of Ajax queries. Those has been discussed in this post Why use AJAX when WebSockets is available?

Christos Lytras
  • 36,310
  • 4
  • 80
  • 113
Daniel
  • 807
  • 8
  • 24
  • 1
    an ajax call every 10 seconds will be a nightmare for performance of the server. Polling is not a good idea at all. – Lelio Faieta Dec 17 '19 at 14:47
  • I believe when using http/2 will leverage the same connection from concurrent request, from Google developer docs "HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection". However I totally agree Websocket would be better – Daniel Dec 17 '19 at 14:55
  • 1
    have a look at [this](https://stackoverflow.com/questions/10028770/in-what-situations-would-ajax-long-short-polling-be-preferred-over-html5-websock). Polling is not the way to go – Lelio Faieta Dec 17 '19 at 14:59
  • Thank you for this very interesting link. I edited my answer accordingly :) – Daniel Dec 17 '19 at 15:07
  • Thanks for all the input guys. I should have mentioned that we are deploying a Serverless architecture. So polling might be less of a nightmare because there will no server bottlenecks.... What we need to figure out as far as AWS API Gateway is concerned is: the cost difference between doing a websockets endpoint (Where we get charged for "connection minutes") or just doing 10 sec polling. Thanks for all the inputs guys. Greatly appreciated. – Bas Dec 18 '19 at 15:33
  • If you use API Gateway with Lambda proxy, I'm not sure you'll be able to open a websocket, but if so, note that Lambda executions have a maximum time before getting killed and concurrent calls lead to multiple Lambda triggering. So websocket does not seem viable at all in that case (you would get charged 5mn per user for instance). Also, running Lambdas with minimal memory for 100mn will cost you around 0,3USD, which is 50% more expensive than 1 million requests, which in your case would make 1666mn (polling every 10s). So even if that was possible you'd better be polling. – Daniel Dec 18 '19 at 16:07