More [Steps|Selfie] Challenges
Almost exactly one year ago I wrote about this initiative we as a familiy started in order to get out of the house more during these difficult times. The app I had created to support us was based on technology from Twilio and Whatsapp and the interaction and competition it had fostered really worked out well for us.
Later in the year the app went through a second evolution. The technology stack actually changed quite dramatically and the focus of the new version centered around capturing everybody’s sports activities. When I say sports I really mean the steps that everyone of us would do each day. As it happens everyone in our family owns a Fitbit watch so the new app was expected to work with the activity data that this watch would produce.
From a technology standpoint the new version of the app was different in that I hosted all my logic on a virtual machine deployed into the Digitalocean cloud. The initial version of the app was (also) written in NodeJS but hosted within the Twilio Functions offering. Sending all these notification SMS’es to the participants and integrating with Whatsapp in order to receive pictures showing everyone’s activities was becoming a bit expensive for me however (given this was a pure fun project) so with the new version I stopped the integration with Twilio which meant I had to move to some other form of compute to host my application logic. In the course of last year I did a quick Udemy course on Flexbox design and with that knowledge I was able to take all the Fitbit data and put it on a simple but neat looking as well as reponsive HTML dashboard.
The second version of the app was also received well by my family but we realized that when we wanted to run the third challenge (the third time we would compete for most steps within a set timeframe) that all participants were not so eager anymore as they had been initially. I am sure that there are a lot of reasons for that but I was focussing on the technical ones to try and see if we could improve the situation. I personally was unhappy with the fact that my app was served from a VM. I had to realize that a VM also contributes to costs and adding changes to the app felt too complicated. As it happens my company decided to grant everyone (who signed up for this) an Azure subscription with a monthly Microsoft credit worth 130 Euros so I decided to move all logic into Azure but I also wanted to make it serverless. The initial idea was to make use of a rather new service in Azure called Azure Static Websites (which was using Azure Functions underneath) but I had to realize that this service did have its (artifical) limits built in and so I implemented the logic as pure Azure Functions (some HTTP triggered, some Time triggered, some chained using the Durable Function feature and one triggered by a Queue).
I can see a lot of benefit from this already as besides the cost factor I can very easily deploy new versions of the app now (since I also implemented my infrastructure deployment as code using Pulumi). Still we all agreed that even with the new version everybody was missing this aspect of “competition” and “gamification” in the app and we realized a lot of this was already there in the very first version of the app and it came from integrating with the Twilio messaging features where everybody basically got told when somebody else was active which then sparked this spirit of competing with another.
In order for this blog entry to not become too long I will stop here and continue to talk about our gamification considerations in an upcoming blog article focussing on messaging and what it would mean to our app and use case.