Skip to content

Instantly share code, notes, and snippets.

@iamstuartwilson

iamstuartwilson/wws.md

Created May 14, 2015 13:14
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save iamstuartwilson/d7300d92b8996544aac0 to your computer and use it in GitHub Desktop.
Save iamstuartwilson/d7300d92b8996544aac0 to your computer and use it in GitHub Desktop.
Download ZIP
Working with Strava API
Raw
wws.md

Things to think about

  • Building our own client. strava-v3 is quite good, but I'm not a fan of the interface
  • Making value objects for units of distance and time. How do we hold data centrally to allow users freedom to switch between metric and imperial
  • Isomorphic JS, what can we ship on the front and back?
  • Data crunching. How are we setting up mutliple API requests and queueing them without borking our server or maxing out rate limits?
@lpww
Copy link

lpww commented May 14, 2015

client: I'm not sure what you mean. Aren't the endpoints already set up on the Strava server and we have to use them?

units: This can be handled in the frontend or backend. We can make it part of the API request logic and add the imperial data as an extra property in the back. Or we can store conversion constants in the front end and calculate conversions when they click a switch units button.

isomorphic js: I've never heard this term specifically but it seems like the same code runs on the client and the server? I'm not sure how that would work exactly but apparently you can do it with React

data: it looks like strava does not support batch requests. Maybe we need to think about exactly which data we want to display each person and then we can get a sense of the number of API requests required to get an initial value. Then after the initial value is received is there any way to lower the required number of future requests? Finally we can set this up as a cron job that updates all users on the regs (better performance from users perspective but potentially wasting our call limits) or make a specific request for each user when someone tries to view their stats.

Caching: Is it valuable? Will it save us API requests?

Storage: We could potentially have 2 databases (probably not necessary but might be fun to implement). One is the raw strava data bank. One is the cache with clean data exposed directly to our client. This kind of setup would almost certainly require us to be pulling user data on a cron and then cleaning it and storing in the cache. It would take too long to do all those processes each time a user tried to load a stats page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment