Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Are the tracks pre-recorded? How likely is it that they'll change? –  Yannis Rizos May 13 '13 at 9:39
2  
How many points are we talking about? Is it quicker to download the raw data (mobile? 3G?) to the device then do the calculations, or is it better to do the calculations server side and just blip down the few bytes that the user will actually see? –  Dan Pichelman May 13 '13 at 13:25
    
@YannisRizos: Very likely. Future version of web app should even allow on-line update of track being recorded as viewers watch it. –  trejder May 13 '13 at 18:35
    
@DanPichelman: Points array size may of course vary, but at this stage of app development (design) I assume average track to have between 500 and 5000 points. –  trejder May 13 '13 at 18:38
    
"But, right now, after reading some docs and pages, I can see clearly, that I may be wrong." Do you have any actual reference to support this impression? Which docs and which pages? –  heltonbiker Jul 24 '13 at 14:45

1 Answer 1

up vote 1 down vote accepted

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.

  1. 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);

  2. 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;

  3. 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;

  4. 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!

share|improve this answer
    
You bet, it helps! :] Thanks... –  trejder Jul 25 '13 at 13:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.