A few changes are coming to the Strava api over the next couple of weeks, the main details of which I’ll leave for their official announcement. There are however a couple of things in those changes that will affect VeloViewer to a limited extent so here’s some info on what that will mean.
Almost all APIs offered by sites (e.g. Twitter, Google etc) apply limits to how many times your application can hit their API in given time frames and lots, like Google, start charging you once you need to go above a given rate. Strava are introducing rate limits but fortunately they have been very generous in the limits that they have given VeloViewer and are not charging me for this usage. There will be a 15 minute limit and a day limit (resetting at midnight UTC) and should I reach either of those limits then I can’t get access to Strava data until the respective time period has completed. Therefore in periods of high demand I will need to limit or suspend the large update processes (and you will be shown a warning saying as such) in order to try and keep the general functionality of the site, like viewing segment details, running smoothly. Coming back to complete the process a bit later in the day will most likely work fine.
The main pages of VeloViewer (Summary, Activities, Segments) don’t use the Strava API so these will continue to work even if the limit has been reached.
In order to reduce the chance of hitting the rate limits (mainly the 15 minute limit) I will be making some changes to the update process to apply some more restrictions (as well as the once a week restriction that is already in place):
- Checking placings: I’m restricting the segment placings that you can have updated to your top scoring (so all segments that make up your VeloViewer Score and some besides will always be included) along with other top scoring segment (which aren’t included in the Score). I’m still working through how to determine this list but basically it won’t include low placing/scoring segments relative to the rest of your segments and there will be a maximum number of segments that can be checked. Every time you cover a segment on a new activity its placing will be rechecked, even if you didn’t achieve a PR.
- Checking for new segments: I’m going to restrict this to your last 100 activities.
Once I’ve got all of that ironed out I might look into letting people perform checks on more segments/activities if there is slack in the rate limit in the last couple of hours of the day (UTC).
The main change here is around being able to access data streams (i.e. long/lat, elevation, distance, etc) from other user’s activities. Basically the API will now only let you access your own data streams. In the current functionality in VeloViewer that isn’t too much of an issue but it does mean that the old VeloFlow functionality will never be able to be re-implemented as getting other people’s streams was key.
It does however throw a spanner in the works for any activity details type page (or 3D view) that I was planning on doing if you chose to make your data public. This is because when you access your own streams you are returned the full stream, including data from within your privacy zones. I’ve avoided this in the past by accessing your stream as a dummy user to ensure I only ever dealt with pre-clipped streams. The short term solution is to not allow any of your screens that include activity stream data to be publically available so I think that is how I’ll proceed for the time being until I can think of a way around it.
Note: the current activity tracks shown on the activity page map come from a different source which always clips any privacy zone info and so will remain as is.