Let’s assume that we have a simple GIS-like application, which presents (using Google Maps or anything similar) recorded tracks. Each track consists of points (data portions) with geo-data and additional information, like speed, altitude and similar attributes.
Basing on these additional params, I want to calculate some extra information, like average speed. What kind of data should web client receive and on which side is it the best to perform necessary calculations:
- client side: client receives (via AJAX) pure array of data (points with additional params) and all the calculations are done in Javascript in the browser,
- server side: client receives content ready to be put in the proper places, like value of average speed, and all the calculations are done on server.
Personally I was always choosing (somehow automatically)the first option, as I thought (correct me, if I’m wrong) this gives me more flexibility. But, right now, after reading some docs and pages, I can see clearly, that I may be wrong. So, what is the best practice in such situation?
6
I think the most important things in this case are Response time (on page load) and Responsivity (in the GUI during interaction).
There is a part of the application use case where some static, more or less constant data is sent to the browser, but thereafter the interaction with the user will determine what data will actually have to be calculated.
-
If you STORE processed-data in your server, prior to any possible request, you could end up with redundant storage space (since speed, acceleration, power, slope, are directly derived from position);
-
If you CREATE processed-data on demand for each request, you could end up with some processing overhead AND some impact in response time to process and send the data;
-
If you SEND raw data and populate derived data on the client side, this could collectively impact response time, because data would have to be sent and calculated anyway, just in different order than in the previous case, because computation is delegated to the client. It would be “good for you”, and would create a good GUI responsivity for the client during interaction (the whole data would be available all the time) at the cost of a slower loading time;
-
I you just send the data from the server, and don’t calculate anything until the user explicitly asks for it (for example, selecting a trajectory, or a segment of a trajectory), then you would have the best response time, and the responsivity of the interface would depend only on sheer data volume AND the strategy you use to perform calculations asynchronously (so as not to freeze the UI), providing clear visual indications of progress, like progress bars or spinning cursors.
I am an enthusiast cyclist and map-geek, and it seems to me that the last approach is the most widely adopted in sites like STRAVA and RideWithGPS. The most common scenario are tracks with just a few hundreds of points anyway, and the types of calculations are quite simple and well-suited to javascript algorithms (basic arithmetics and trigonometry).
Hope this helps!
0