Search code examples
node.jsdesign-patternspolling

Node.js design approach. Server polling periodically from clients


I'm trying to learn Node.js and adequate design approaches.

I've implemented a little API server (using express) that fetches a set of data from several remote sites, according to client requests that use the API.

This process can take some time (several fecth / await), so I want the user to know how is his request doing. I've read about socket.io / websockets but maybe that's somewhat an overkill solution for this case.

So what I did is:

  • For each client request, a requestID is generated and returned to the client.
  • With that ID, the client can query the API (via another endpoint) to know his request status at any time.
  • Using setTimeout() on the client page and some DOM manipulation, I can update and display the current request status every X, like a polling approach.

Although the solution works fine, even with several clients connecting concurrently, maybe there's a better solution?. Are there any caveats I'm not considering?


Solution

  • TL;DR The approach you're using is just fine, although it may not scale very well. Websockets are a different approach to solve the same problem, but again, may not scale very well.

    You've identified what are basically the only two options for real-time (or close to it) updates on a web site:

    1. polling the server - the client requests information periodically
    2. using Websockets - the server can push updates to the client when something happens

    There are a couple of things to consider.

    1. How important are "real time" updates? If the user can wait several seconds (or longer), then go with polling.
    2. What sort of load can the server handle? If load is a concern, then Websockets might be the way to go.

    That last question is really the crux of the issue. If you're expecting a few or a few dozen clients to use this functionality, then either solution will work just fine.

    If you're expecting thousands or more to be connecting, then polling starts to become a concern, because now we're talking about many repeated requests to the server. Of course, if the interval is longer, the load will be lower.

    It is my understanding that the overhead for Websockets is lower, but still can be a concern when you're talking about large numbers of clients. Again, a lot of clients means the server is managing a lot of open connections.

    The way large services handle this is to design their applications in such a way that they can be distributed over many identical servers and which server you connect to is managed by a load balancer. This is true for either polling or Websockets.