I have been weighing the pros and cons of using WebSockets vs. an Ajax call for an event which will happen every x number of seconds (in this case 5). I'll start by explaining the scenario.
Business customer wants "real-time" updates to a webpage based on data living inside a database. This database resides within a walled environment (third party application), and the only way to access this data is via a provided REST API.
My initial thought was that we could simply do an Ajax request every minute to update the webpage with the newest data obtained from the API, but the business customer wants this data as soon as it's updated and insists that a one-minute interval is too long. Ok, that's understandable.
My next thought was to just run the Ajax call every five seconds, but I quickly realized that this may have a serious performance overhead. If 1000 users have this webpage open all day long watching the data refresh, that would result in
1000*(60/5)*60*24 (number_of_users * (seconds_per_minute / refresh_rate) * minutes_in_hour * hours_in_days) or
17,280,000 additional requests per day, along with each requiring a call to the API to obtain the information.
That's a lot of requests. And an exceptional amount of API calls resulting in database reads. To overcome the excessive API calls we could implement a caching solution which would read from the database at the refresh_rate (5 seconds) and save the results to something like Redis, which the Ajax requests could then read from. This would remove the
number_of_users variable from the above equation.
Ajax call TLDR:
- 17,280,000 http requests per day
- 17,280 api calls per day
- quick and easy to implement
- does not introduce a WebSocket server onto our current software stack
Alright, so if it's decided that the Ajax solution is too much extra overhead... then WebSockets. Using WebSockets seems like a logical approach to resolve this dilemma.
Instead of having to make an http request every five seconds back to a webserver, clients could instantiate a WebSocket connection on page load and receive updates as fast as the server can push them.
The WebSocket server could poll the API every 5 seconds for changes (eliminating the need for a caching solution as described in option 1) and push these changes to all connected clients.
- single call to server to instantiate connection, server then pushes changes to all connected peers
- no need for caching layer
- introduces a WebSocket server onto our stack
It seems like Option 2 is the way to go, however as mentioned above, this will require an additional application to live on our stack which will need to be thought out, designed, and supported. So it would seem that my real question really comes down to:
Would you rather allow 17.3 million http calls to your infrastructure, or design a WebSocket server?
The WebSocket server would have to be implemented in either Java or C# as these are the allowed backend technologies for our organization (no Node.js).