Introduction

My name is Caleb Tetteh. I worked on the API and Platform Team as a software engineer intern in the summer of 2023. I gained a lot of software skills from learning from engineers on the API and Platform Team during my internship at Strava. In this blog post, I will discuss how I automated the process of adding new hires and removing employees from the Strava platform.

This blog post is divided into six sections which are the introduction, background, project description, iterative software development steps, code implementation, and conclusion.

Background

• Srava monolith application

Strava maintains a large Ruby on Rails monolith application codebase. The monolith historically housed Strava’s web user interface (web UI), application programming interface (API) gateway, and business logic. The API gateway is the entrypoint for all API clients including Strava’s iOS and Android applications. The web UI allows users to interact with the content of Strava web app. The business logic is the portion of the software that users do not see and is responsible for processing logics such as rate limiting, authentication, and authorization.

• Onboarding and offboarding process on Strava via monolith application

Strava engineers on the API and Platform team and Infrastructure team handle the onboarding and onboarding process via the monolith application. Onboarding simply means granting employees with permissions and roles that gives them the ability to do things like delete athletes or manage third party API applications. Offboarding simply means removing granted permissions and roles from employees who are leaving the company. Onboarded employees are given elevated status called superuser status.

When onboarding an employee as superusers via the monolith application, an engineer manually loads a Rails console and runs a script called the onboardingscript which is located inside of the monolith. This script changes the employee’s Strava account email to their work email, adds them to the Strava employee access group, elevates the employee’s subscription status, and grants permission and roles. Permissions and roles assigned to the employee are based on their work responsibilities. Before running the onboarding script the engineer provides the script with the employee’s ID and company email. Figure 1 shows a pseudo code of a portion of the onboarding script that updates employee’s subscription status.

Figure 1: Updating employee’s subscription status pseudo code

Similarly, when offboarding an employee via the monolith application, an engineer loads the Rails console to run a script called the offboarding script which is located inside of the monolith. This script reverses doings of the onboarding script by resetting the employee’s Strava account email to personal email, removing Strava employee badge from the employee, removing the employee from Strava employee clubs, demoting the employee’s subscription status to a regular user, and removing all roles and permissions.

• Strava move from monolith to a new platform

Strava is transitioning from its monolith Rails application to a new platform which is composed of backend microservices, React web UI, and GraphQL API gateway. Microservices is an architectural style used for software development where the software is composed of loosely coupled and independent services that use APIs to transmit information. React is a Javascript library used for web user interface development. GraphQL API gateway facilitates the querying of data across multiple services in the backend.

Strava’s backend microservice architecture is developed to communicate to the React front-end over the GraphQL API gateway. As part of Strava’s effort to move away from its monolith application, monolith application logic is being migrated onto the new platform and new development features are implemented on the new platform.

• Strava microservice architecture and GraphQL API gateway

Strava microservices are implemented in Scala and connected to a GraphQL API gateway. The GraphQL API gateway is made up of multiple subgraphs and Strava’s backend REST API’s are orchestrated to send or receive data from the front-end across these subgraphs. Subgraph consists of unique schemas that allow query execution across the backend service it represents. The subgraphs are federated into a bigger schema of supergraphs in the GraphQL gateway which allows querying across multiple services from the client side. Figure 2 is a high level representation of client, subgraphs, GraphQL gateway, and microservices.

Figure 2: GraphQL gateway, front-end, subgraphs, and microservices.

Project description and goals

The goal of my project was to automate the onboarding and offboarding process on Strava’s new platform to reduce the amount of time and toil engineers spend in performing the same process in the monolith application. This required the migration of the onboarding and offboarding script logic from the monolith into microservices, as well as modification of Strava admin user interface, and modification of the GraphQL gateway. When my project is successfully completed, the offboarding and onboarding process will be done with a single UI click from the front-end, and hence can be transferred to Strava human resource team to handle, thereby saving the company engineers hours which can be put towards other productive projects.

Iterative Software Development Steps

I utilized iterative software development steps to achieve the project goals. Figure 3 below illustrates a cycle of software development steps used in migrating all onboarding and offboarding script logic from the monolith to the new platform. Each iterative step is explained below.

Figure 3: Migration cycle

The first iterative step involves breaking down the onboarding and offboarding script logic into small independent Jira tasks to be easily tracked and worked on. Onboarding script logic was already broken down into small portions of specific Jira tasks when I joined the company. This made it easier for me to break down the offboarding script logic after successfully automating the onboarding process.

The second iterative step involves picking a single Jira task to implement in the new architectural platform and identifying the appropriate microservice, GraphQL subgraph or web page to implement code for the Jira task.

The third iterative step involves coming up with creative design solutions and implementing the code for the chosen Jira task in the appropriate microservice, GraphQL subgraph, or web page of the new platform.

The fourth iterative step involves developing unit tests to test code functionality to help ensure code quality. Unit test verifies the accuracy of a block code, typically a method, to check if it runs logically as expected.

The fifth iterative step involves creating a pull request for reviewers to approve my code implementation and unit tests, or request further changes to specific lines of code. I move onto the next step after the pull request is approved by engineers on the API and Platform team.

The sixth iterative step involves deploying the approved code to a non production environment, then testing its functionality to verify if the code implementation works as expected.

The seventh iterative step involves deploying the approved code to a production environment and testing functionalities to confirm that code implementation also works as expected. At this stage, the approved code request is then merged into the main repository. After merging into the main repository, I pick the next Jira task to implement and follow the migration cycle as shown in Figure 3 until I have successfully migrated all logic to the new platform.

Code Implementation

This section highlights key code implementation and software design consideration while working on the project. This section is divided into four parts which are implementation in microservices, GraphQL API gateway modifications, and implementation in React front-end.

• Implementation in microservices

Some of the onboarding and offboarding logic implementation required dependency among multiple services for successful execution whereas others did not require dependency. Figure 4 is a diagram representation of a micro service called mass that is making requests to other microservices for response.

Figure 4: A diagram of mass microservice making calls to other microservice

For the logic that required dependency on other services, I designed and developed new API endpoints to make requests or receive responses from those services. To ensure code quality before deployment, I developed unit tests for all code implementations. I also implemented permissions checks to ensure that only users with the appropriate permissions can offboard or onboard an employee.

• GphQL API Gateway Modifications

Some portions of the onboarding and offboarding script logic required me to make changes to the GraphQL API Gateway so that the new data parameters I created by modifying onboarding and offboarding API can be exposed to the client. To achieve this, I updated the backend GraphQL resolvers and mutations in subgraphs to allow both email and employee ID data to be sent across Strava GraphQL architecture. GraphQL resolvers are functions used to populate data for a schema field, whereas GraphQL mutations are operations that are performed on the backend to allow the insertion and fetching of data from backend services.

• Implementation in React front-end and Testing

I modified the existing admin user interface by adding an email input field and implemented javascript functions for email and employee ID validation checks for the onboard process. I also developed an email input field for the offboarding process and implemented email validation checks as well. To ensure correctness of validation checks, I utilized a testing framework called Jest for verifying accuracy of employee ID and email validation functions.

Figure 5 below is an image of the UI window used in onboarding an employee.

Figure 5

Figure 6 below is an image of the UI window used in offboarding an employee.

Figure 6

Conclusion

I automated the process of onboarding and offboarding employees at Strava by migrating logic from an offboarding and onboarding script into multiple microservices as well as modifying a React front-end application to communicate with these services over a GraphQL gateway. Onboarding and offboarding processes that used to take 10 minutes per employee now take less than 20 seconds with a single UI click from the front-end.

As a result, Strava engineers on the API & Platform team and Infrastructure team no longer have to manually load Rails console to onboard or offboard employees which saves the company engineers hours. Since the onboarding and offboarding process is no longer a manual process, the responsibility of offboarding or onboarding new hires as superusers can be handed off to the human resource team to handle. Software tools utilized for the project include Scala, Finagle-thrift, GraphQL, React, CSS, Git, JavaScript, Jest.js, SQL, AWS, Kubernetes, and Docker.

..