Finally I got withings and the new service for ConnectStats to work again with version 5.1! At the time of this writing version 5.1 is pending apple approval for release.
Withings
The Withings authentication process has been broken for a while…
It took me trying a whole new approach to do the authentification process for the withings API, a few exchanges with withings support and learning way more than I ever wanted to know about the OAuth 2.0 protocol to get it all in the right place again.
The key change I believe is that withings started to have the OAuth 2.0 authentification token to expire and the way I was using the authentification library was slightly incorrect. But before I tried to use that library correctly, I tried to upgrade to a more modern approach than the one I was using that had been declared obsolete. These though required Withings to make adjustment on their side (non http scheme), which they kindly did. I never got it to work. Ultimately, after studying the deprecated library, using the ever more useful proxy app Charles I finally figured out how to get things working again! In the process I also streamlined the way the setup screen works, fix the ability to logout and back in, and synchronised the interface into Strava to use the same new code.
New ConnectStats Service
To use the new Garmin Health API, I had to implement a server that would receive, process and save all the activities of ConnectStats users when their device uploaded them to Garmin.
I knew that processing these requests as they came in realtime was a bad shortcut in the first implementation of the service for the new Garmin API. I had not expected how bad the deadlock and timeout would be when used in real life as often many files would be sent to my server at once. I had adopted the “make it work, optimise later” approach, but here the optimise step was immediately needed…
While I had postponed implementing it, I knew what the right approach was: I had to add all the incoming requests from the service to a queue and process sequentially a few at a time.
To host my server, I am using an entry level service from GoDaddy, which is a great relatively cheap hosting but with fairly limited optionality in configuration. Which meant it wasn’t an option to bring some pre-built queuing system. I had to build it myself with the tools available…
It’s of course not advisable to implement such a common system yourself, but, well, I do all this to learn anyway… It was definitely interesting to figure out how to make sure it behaved in a robust manner in all the edge cases I could think of. As with Connectstats itself, I open sourced the code of the server. Hopefully it can be useful to someone interested in having a lightweight server to work quickly with the Garmin Health API or can help people struggling to implement their own.
I am releasing this now in version 5.1. In that version only new users will use the new service by default, but existing user will have to switch manually in the configuration page. Crossing finger that this time it will work better and scale…
Bonus with the new service
Beside resiliency to the next API change from Garmin on their web site, the new service allowed me to bring in weather information from DarkSky, so that’s an added bonus for using the new service. Because I now fully control the service that serves activities to Connectstats, it maybe possible in the future to add more such new features.
Thought on servers, hosting, services etc
This experience made me appreciate better the differences in services. I use a service from GoDaddy that is very simple, turn-key and fairly cheap. While it forces you to be a bit more nibble in the implementation, it was a bit interesting to compare it to using more scalable and more configurable services like DigitalOcean or AWS. I briefly considered, but it’s clear that it would require a non-significant learning process and higher costs. So I am sticking with GoDaddy for now, and hope the system will handle an increase of users without requiring me to upgrade to a fancier hosting service.
The weather service from DarkSKy is very nicely done and reasonably priced and free for the first 1000 calls per day. I anticipate based on the current number of users that the cost will remain small.
Would be nice if name,location and type of run could be imported from Garmin – to search for specific runs.
The latest version 5.1.3 is intended to do that, let me know if it works.
Yes, that’s the plan. In settings there is an option for garmin to use as source “all” in that case it will try to import information from garmin as well. I didn’t check yet if it get the name, but if it doesn’t I’ll fix in new version
Actually found the reason what the name wasn’t updated properly, update will come soon (5.1.2)