Better ways than traditional polling methods

Question

I'm currently in a AngularJS/Javascript environment.

Currently the application using the polling method (i.e, to retrieve new data from server in a fixed amount of seconds).

This is quite taxing and does not retrieve latest result immediately. Assuming the server is using ASMX for webservice functions and if possible, without a major overhaul, how can I better improve on the application efficiency?

Edit 1:

By taxing , I mean the server would have to pull up different SQL tables and associated data and stuff, meaning complex data processing which if there is alot of concurrent users I'm afraid there might be possible issues with the server performance in the future.

The latest data will not be retrieved as currently the application is using request-response https type of calls.

I can improve more on the mobile application side, but not able to modify much on the server side apart from the server's webservice files.

Answer 1

If by "traditional" you mean every client hammering the server as often as they can then I can help at the architectural level.

The appropriate design depends on where your server falls in this grid:

Control \ Resources : Sufficient | Insufficient
Customizable        :     SC     |     IC
Untouchable         :     SU     |     IU

• SC : Make the server follow the observer pattern. Allow clients to register as observers.

• IC : Only allow a proxy system to register with the server. Clients register with proxy.

• SU : Only allow a proxy system to poll the server. Clients register with proxy.

• IU : Only allow a proxy system to poll the server. Clients register with proxy.

A proxy that follows the observer pattern can solve both customization and resource issues. This works just as well over the internet as is does between objects. When you register you're asking to be called when something happens. Listen on a port and you're ready to be called. ajax, REST, UDP, whatever.

The problem with polling is that the observer controls when the call happens yet doesn't know when state changes so it makes many needless calls. This eats resources especially when there are many observers. The key to dealing with polling is: as soon as possible, get the direction of calls going from the point of state change to the observer. Then calls happen when they're needed. Not when they aren't.

If you have polling calls going this way:

• Server <=== Many observers

Any of these would be a better way to detect changes:

• SC: Server ===> Many observers

• IC : Server ===> One proxy ===> Many observers

• SU : Server <=== One proxy ===> Many observers

• IU : Server <=== One proxy ===> Many observers

Answer 2

You can use Server-Sent-Events as an alternative to polling.

Instead of asking your server for new data every n seconds, open a dedicated connection and have it send your new data when it becomes available!

The connection will stay open until explicitly closed by either the client or the server (or by their sudden termination).

You can setup your server to broadcast data to your client on fixed intervals, or at specific times at your server (lets say when an object changes state or when a scheduler fires a job or when ).

You can define different event types and have different routines handle different event types.

On the server side you can hold a queue of users currently subscribed to your application/event type, when an event is created, your server will broadcast it to all the users in the queue. Frameworks like Jersey2 already implement this approach using a Broadcaster object.

On the client side you will have to write a service that will listen to server sent events on a specific url.

When you will enter a state/route you will have to subscribe to a server type, and unsbscribe on $destroy to avoid a leak.

Answer 3

They're websockets : they're an exntesion of HTTP, work in the same port.

It enable bidirectionnal communication between client and server and oof course there is an angularjs integration available for that.

Otherwise on the back office side, if you look at Spring in Java, there are others way of doing it :

• Long polling
• STOMP
• ...

This link covevr websocket and others methods adapted to what you need.

Note that if you don't have Spring/Java you should still read it and search equivalent solution in your stack of technologies.

Answer 4

You need to better define things like "quite taxing" and explore why it doesn't retrieve the latest result immediately. These are questions that are probably happening irrespective of whether you're polling from your client or not.

That said, with a browser based front end, you basically have two options if you want to stay in native javascript: polling (as you're doing, or possibly long-polling) or web sockets. I've not seen web sockets done w/ ASMX before (not saying it can't be done, just that I don't have experience there so I don't know how hard it would be for you to re-implement). Further, if you're having performance or accuracy issues, as I said, those might well still be there even with the use of web sockets.