Fitness as a part of the physical and mental wellbeing of Bitwisers has always been a topic of conversation at Bitwise. So, when the Fit India Freedom Run was announced by the Government of India as a nationwide virtual campaign to encourage citizens to include fitness activities in their everyday lives, fitness enthusiasts like me at Bitwise were filled with excitement about the prospect of participation. 

We perceived this campaign as a great opportunity to actively make fitness activities part of Bitwisers’ daily routine and decided to make the most of it. The Bitwise event team initiated a company-wide event by registering the company for Fit India Freedom Run for all Bitwisers to participate. 

And guess what? More than 200 Bitwisers enrolled for the event.  

Post enrolment, we had to collate and share the relevant data of the participants along with the cumulative distance covered by them over 50 days on the Government’s Fit India Portal.  

Now, here comes the challenge to accurately capture the necessary data in a quick and efficient manner…

FitIndia App: An innovative approach to collect fitness data 

Necessity is the mother of all inventions and in our case, innovations. And accurately collating fitness data from 200+ Bitwisers for an activity spanning over 50 days was a problem that needed a smart solution. 

So, I decided to do what a Bitwiser does best: Leverage innovation and technology.

This was a challenge that sparked the idea for me to create FitIndia App to track and record Bitwisers’ fitness activities in a highly efficient and automated way.

Why reinvent the wheel?     

The sole focus of my endeavor was to make this initiative as efficient as I could and I did it by integrating the App with Strava- A fitness tracking platform with social networking features.

FitIndia application would need to gather real-time fitness data from every participant daily and it would need to be designed and deployed as quickly as possible. Strava was the most obvious choice for the integration purpose as it fit the bill perfectly. 

A popular social networking platform among fitness enthusiasts, Strava is compatible with all mobile devices and smartwatches, which was ideal for me to ensure easy access for all participants.   

The innovative approach of integrating the App with Strava was like a key piece of the jigsaw puzzle that revealed much of the bigger picture.  

Strava provides APIs which fetch athletes’ activity to a local database. As soon as an athlete completes any fitness activity, there is a need to register a webhook to receive an activity ID. The FitIndia app acted as a bridge to capture real-time data from Strava and upload it to the Government’s Fit India Portal.

This paved a way for seamless functionality. 

How FitIndia App functions

The functionality of the FitIndia App is easy. Here’s how it works: 

• Bitwisers are required to register on the FitIndia App.  

• They log in to the App with a Strava account.  

• The FitIndia App needs permission to read data on your behalf. The app will ask for permission when a user is logging in for the first time and then it will use the same credentials to log in. 

• Once the two applications are synced, Bitwisers can view the dashboard for the fitness activities they have logged as well as others’ contributions.  

• When Bitwisers decide to do any fitness activity like running, walking, or jogging, they can use the Strava app either on their phones or smartwatches.  

• Once the fitness activity is completed, the fitness data generated is synced to Strava’s server. 

• After the data is available on the Strava server, the FitIndia app receives a notification, and the backend system extracts information from its server using its APIs.

Enabling these functionalities required extensive planning and experimentation. And even though I knew it wouldn’t be easy, my passion for both fitness and technology made it an exciting challenge to solve…

Innovation demands experimentation 

The entire process of integrating the FitIndia App with Strava took me three iterations. Every iteration was an approach used to find the right way of integration. Each iteration revealed some challenges as well as paved a path for successful integration.

With every iteration, I was intent on ensuring that there is value added into each one, the performance is enhanced, the scalability and extensibility are not compromised, and cost optimization is at the center stage of design.

Iteration 1

Building an application for user registration, syncing data in real-time with Strava API, writing a unit test, and integration with the application took me 2 days.  

The next step was to finalize deployment options. I had multiple choices for host applications on GCP such as App Engine Flexible, GKE, and Cloud Run. Out of these choices, I chose GKE and created a small cluster with two nodes in the Asia-south-1 region. The application had to be accessible over SSL, so there was a need for components to perform SSL offloading. I selected Nginx-ingress over Istio, as the application is simple and there is no need for features of a full-fledged service mesh.

Challenges faced in this iteration 

• Strava has an API quota limitation where one can only make 100 calls per minute and 1000 calls in a day 
• Cluster setup was required and the cost of the cluster is on the higher side from a scalability point of view 

Improvement areas for the next iteration 

• Cost optimization for cloud resources 
• Preventing data loss while reading information from Strava 
• Throttle API calls to Strava to meet the API quota

Iteration 2 

The main objective of the second iteration was cost optimization and throttling API calls without any data loss in case of any failure. I added a Node JS based cloud function to read incoming information from Strava and store it to pub/sub-message. Also, I configured the dead letter queue and exponential back-off in pub/sub. 

To optimize cost, I deployed its existing Spring-boot application in Cloud Run (It’s a serverless offering from Google Cloud to Run Containers based on KNative). This iteration yielded significant benefits in terms of cost as the application was entirely server-less, and most of the services got free tier.

Challenges faced in this iteration

• Degraded UX was a cold start for Cloud functions 
• In terms of usage of Pull Subscriber to throttle Strava API calls, as Pull Sub works in a background thread, it’s Live only during the period when requests from end-users are received

Merit of this iteration 

• Message delivery guaranteed by Pub/Sub with SLA of 99.95 

Demerit of this iteration  

• The default behavior of the Cloud run is to scale down to zero. If no requests are coming, it results in Cold Start 

Iteration 3

In this iteration, I had two options to achieve successful integration as follows:

• Rewriting some code and making the application lighter to resolve the issue of cold start for cloud functions 
• Looking for other hosting options for cost optimization

 Merits of this interation

Integration with Pub/Sub helped me to provide automatic retry behavior until the activity is synced properly. It also provided features like Dead Letter queue & exponential back-off.

• After each Publish request, the request timeout increases by the request timeout multiplier, up to the maximum request timeout 
• After each retry, the retry delay increases by the retry delay multiplier, up to the maximum retry delay 

Result

The lifespan of a Preemptible VM is a maximum of 24 hours so there was a possibility of experiencing downtime of a few minutes when VM recycling in the process.  

But due to the resilient nature of the application, there was no data loss. So, I used the same cluster from option as in Iteration 1 and added one more node pool with Pre-emptible VM and reduced disk size while configuring node pool. 

Outcomes from all 3 iterations  

• I achieved approximately 50% reduction in the cost from the first iteration  
• There was a huge improvement in the UX as the average response time was less than a second 
• There was no loss of information from Strava even in case any failure was detected 

The App was a success on all fronts 

The goal was achieved in an agile and timely fashion. The FitIndia App is resilient and there hasn’t been any instance of data loss.  

The innovative approach did the trick and helped to efficiently gather data from the Bitwisers who participated in the run and upload it on the Government’s Fit India Portal.  

It also motivated the participants as they could see their own progress as well as that of others on the dashboard. This has led to a gradual increase in the number of participants and continues to do so. 

Bitwisers covered a distance of 4500 km in this run spanning over 50 days. After the Fit India Freedom Run, the FitIndia app is still a crucial application for fitness enthusiasts at Bitwise and has become an integral part of the new normal of fitness.