This API exposes a singular function at the moment which is to do the following:
- Mashup on demand – Let client apps consume a mash up of fitness activity data points from different target APIs based upon user ID and time period for a specific date. Note: User ID is not implemented right now because my authorization website is not implemented fully yet.
Common usage of GetFitYall API
1. Self-service analytics tool such as PowerQuery and PowerMap pulls activity data points from HTTP/S endpoint(s) based upon query parameters such as user ID, date, and time period.
1. Get activities mash up
GET http://getfityall-api.azurewebsites.net/mashup?<userID>&ondate=YYYY-MM-DD&aftertime=HHmm&beforetime=HH:mm
E.g.,
http://getfityall-api.azurewebsites.net/mashup?ondate=2014-08-04&aftertime=10:00&beforetime=23:00
Description:
Gets a mashup of activity data points from different fitness APIs based upon user ID and matching timestamps. Currently supports Fitbit intraday API and Strava API. In order to get activity data points down to 1-minute detail level, this API function only works for a specific date as required by the Fitbit intraday API.
Query parameters
userID The Fitbit user ID which has been authenticated and authorized by Fitbit OAuth API
date The specific date from which to pull the Fitbit activity data points. This works with 1 specific day because the Fitbit Get Intraday Time Series function only allows fetching a time series for a specific day but the data points would be down to 1 minute detail for the day. See https://wiki.fitbit.com/display/API/API-Get-Intraday-Time-Series
afterTime The start of the period, in the format HH:mm
beforeTime The end of the period, in the format HH:mm
Returns: Content-type = application/json
HTTP status codes
200 – OK
400 – Error in request
500 – Error in processing
Example response:
[
{
"type":"fitbit_strava",
"date":"2014-07-20",
"data":[
{"datetime":"2014-07-20T10:00:00.000Z","latitude":-33.869406,"longitude":151.120498,"distance":12959.4,"altitude":8.5,"steps":105,"calories":13.890000343322754,"floors":0,"elevation":0},
…. omitted for brevity….
{"datetime":"2014-07-20T10:00:00.000Z","latitude":-33.869369,"longitude":151.120443,"distance":12966.1,"altitude":8.3,"steps":105,"calories":13.890000343322754,"floors":0,"elevation":0}
]
}
]
This API is implemented as node.js app and deployed into a free/basic Azure website from WebMatrix. The reason why I had chosen node.js is mostly to learn a new server-side technology. The other reasons are:
- More programmable for mashup logic.
- Leverage many third-party Node.js modules such as node-strava, node-fitbit to rapidly develop prototypes of the GetFitYall API.
- Scalable as I configure this as an always on basic Azure website and scale out accordingly.
- Due to the lightweight nature of node.js, the node.js app can handle a large amount of traffic with low overhead
Obvious Bottleneck
One potential problem is the sheer number of mashup requests. When I invoked this endpoint from PowerQuery, I saw that there were 3 requests for each query, kind of weird but I’m not keen to find out why. Multiplied by thousands if not tens of thousands of users, it is pretty obvious that this would become a serious problem. Recommendation to address this bottleneck as follows:
- Cache the HTTP Response
A simple solution is to cache the response for similar requests (based on the same query parameters). The main benefits of caching response are reduced latency and network traffic.
2. Mashup On-demand Optimization
The node.js app makes asynchronous calls to the Fitbit API to retrieve steps, calories out, floors, and elevation because this is how the Fitbit API works. A Javascript promise is used to determine when all calls are returned before processing the next step. This is another benefit of using node.js and by further using a 3rd party module such as Q, the callbacks hell can be avoided.