Design Patterns – Better Alternatives to Traditional Polling Methods

angularjsdesign-patternsjavascriptpolling

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.

Best Answer

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

Related Solutions

How Client-Side Programming Works in JavaScript

When a client makes a request to your Web Server requesting a resource -for example, the main Page- your server returns that resource. In case that resource is an HTML file, it is possible -and common- that to show your site you also require additional resources -images, CSS stylesheets, JS files- so the Browser can render your page correctly. That assets can be on the same web server that host your application or can be hosted somewhere else.

With this line of code:

 <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.0.7/angular.min.js"></script>

Your HTML file is saying that it requires the file angular.min.js, and that file is locate in the https://ajax.googleapis.com servers. On the other side, this line of code:

 <script src="components.js"></script>

States that your site requires the components.js, and that file is located within your Web Server (for example, in http://www.mysite.com/components.js). So, when a user access to your site his Browser will load some files from your Web Server and some other from external repositories. Every file will be downloaded and stored in the Client's PC to load your site.

AngularJS dealing with large data sets (Strategy)

Is there a best practice of handling this large amount of data?

Not sure about "best practice", but I think would be a good idea to clearly define what you need to do with the data. What will the user actually need to see at any one time? Instinctively, 24 hours of data points every 2 seconds doesn't seem that possible to handle, cognitively. Maybe you'll have a per-5-minute average, that you'll need to graph? In that case, I would create an API that requests these averages so the browser doesn't need to deal with all the data. You could cache these on the server if needs-be, for other requests. If the user will see one-screen of fine-grained temperatures at any one time, then create an API that requests one-screen's worth of data at a time (similar to your paging API).

Using one-screen's worth of information at a time is also a good strategy if you have lots of Angular's bindings: if you end up with 1000s of them then interface performance will drop.

I am just looking for some suggestions as to what might provide a good balance between good performance and not caching the entire data set on the client side

Would it be useful to load those first 20 minutes into the live view and then cache into local storage something like the last 24 hours?

It's always a bit hard to decide how to optimize before you know exactly where the bottlenecks are. Keeping-it-simple for the first design is often a good idea. Don't build your own caching layer, at least at first: use $http's built-in cache, and maybe also an aggressive caching strategy using http headers, so the browser can cache the Ajax requests as well.

Best Answer

Related Solutions

How Client-Side Programming Works in JavaScript

AngularJS dealing with large data sets (Strategy)

Related Topic