cancel
Showing results for 
Search instead for 
Did you mean: 

Bootstrapping a new app with data

gtracy
Mt. Kenya

I'm super curious how developers are bootstrapping their data.

When starting a new app, I want to bootstrap my database with my personal history. So rather than simply leveraging webhooks, I want to first read in past events. This is impossible with the current rate limits. 

What do most people do to solve this problem?

Thanks!

1 ACCEPTED SOLUTION

ActivityFix
Kilimanjaro

It really depends which data fields you are trying to collect. You can use getLoggedInAthleteActivities to retrieve up to 200 activities at a time using a single API call, so even for someone doing 2-3 activities per day that would only require 5 API calls for a year of activities. If you're pulling activity streams or other details which aren't included in the SummaryActivity model then you'll have to do things the hard way and grab a single activity at a time, which leads to...

You can (and should) also design your app with rate limiting built in. Every API call returns your current rate limits and usage in headers. You can use that information to throttle your calls to stay within your limits. For my app I have queues of pending requests and only pull from them if I have enough API calls left to complete it, otherwise I wait for the next 15 minute increment before executing an API call. That allows me to handle any sudden influx of activities without blowing through my API limit. It occasionally adds a little bit of processing delay for the end user during very busy times, but it's better than failing to process at all.

View solution in original post

2 REPLIES 2

gtracy
Mt. Kenya

Thank you for the pointer to getLoggedInAthleteActivities!

 

ActivityFix
Kilimanjaro

It really depends which data fields you are trying to collect. You can use getLoggedInAthleteActivities to retrieve up to 200 activities at a time using a single API call, so even for someone doing 2-3 activities per day that would only require 5 API calls for a year of activities. If you're pulling activity streams or other details which aren't included in the SummaryActivity model then you'll have to do things the hard way and grab a single activity at a time, which leads to...

You can (and should) also design your app with rate limiting built in. Every API call returns your current rate limits and usage in headers. You can use that information to throttle your calls to stay within your limits. For my app I have queues of pending requests and only pull from them if I have enough API calls left to complete it, otherwise I wait for the next 15 minute increment before executing an API call. That allows me to handle any sudden influx of activities without blowing through my API limit. It occasionally adds a little bit of processing delay for the end user during very busy times, but it's better than failing to process at all.