I few months ago, I began building a new cloud based application using a very different stack to the one that I use at work. I am a full stack cloud engineer and have plenty of experience working in the cloud but I have never set up a project from scratch. To try to broaden my technological horizons and because I thought I was picking the right tools for the job I departed from my old familiar languages and frameworks. In this series I am going to share how it’s going and what I am learning.

I am already a few months into this journey, I am just starting to document it now but I plan to stay more up to date on this project!

The App

I want to say first of all that I am not the first one to have the idea, I know of at least a couple of implementations that exist but I liked the idea and thought it would be interesting for me to try to recreate and maybe add a couple of my own features on top.

The premise is that I cycle to work and I like to track my activities on Strava. I like having my aggregated stats but I also don’t want to pollute everyone’s feeds with my boring commutes. Strava gives you the option to tag rides as “commutes” allowing you to filter them out from your history. You can also to set them to “mute” where if someone is following you, the activity does not show up on their feed but your activities remain public and thus count towards your weekly totals etc. These options (for now at least) are manual on Strava and I got a bit tired of doing this twice a day when I cycle to and from work.

Luckily for me, Strava exposes an API so I can run a script that checks if any new activities are commutes by some criteria and then updates them programmatically. Better still, Strava exposes a webhooks API that notifies me each time I do an activity so I can use this to trigger my script. Basing myself off examples I have seen Strautomator and Commute Marker I agreed that the most logical criterion is the start and end location (I like to switch up my commute to keep things interesting so full route matching wouldn’t work for me).

The algorithm behind this isn’t inherently difficult and so I thought it would be a good learning opportunity to try to recreate the same thing using languages and frameworks that are new to me. Maybe once I have this base feature working, I can add some more features over the top that might make my offering a bit more unique.

The Tech

My main area of expertise is containerised microservices in Java with front end in Angular. I am also familiar with Google Cloud Platform as a cloud provider. For this project, I am interested in the AWS free tier (for obvious reasons) and the lambda function offering. This seemed to me to be a good choice since lots of the orchestration is abstracted from me and it can scale to zero, hopefully making it more cost effective. Not being too familiar with serverless architecture, this would be another opportunity to explore a slightly new domain to me.

Backend

Something to be aware of with Lambda functions is that there are lots of cold starts, so start up time is important both for performance and cost effectiveness. I therefore wanted to pick a programming language that I could compile natively. Sticking to my home territory, I would have picked a Java framework such has Helidon or Quarkus that both offer native compilation. I instead looked at slightly lower-level languages such as C++, Rust and Go. Although I was keen to learn new things, looking around C++ and Rust, I was concerned about the learning curve and the complexity of just building something that could handle web requests. Go has web request support built in and seemingly easy to implement. It also offers native compilation, good performance and no need to manage memory (something I have never really learned coming from a Java background).

Frontend

There are a growing number of frontend frameworks. As well as the established Angular and React, frameworks like Vue.js are building on the SPA front end framework idea. I know Angular fairly well and I have dabbled in React so going with one of the newer kids on the block was tempting but went with React to continue my learning journey with this framework. This decision not being as technically informed as my backend choice since my understanding of the technical constraints are a bit more limited and users won’t be interacting too frequently with the front end so it won’t be too complex.

Armed with my first tech decisions, I decided to dig into the docs and started trying to get something off the ground. I will continue this series with some more of the early challenges and decisions I have had to make to get to where I am now and I will try to keep updating as I continue!