A Taste of Pakora
My name is Avery Dunn and I am a rising master’s student at Washington University in St. Louis studying computer science. For the past 12 weeks, I have been a software engineering intern on the API & Platform pod of the Foundation team. I am an active Strava user and have been for approximately 3 years with my favorite activity being running. Some other activities I enjoy are playing the piano, reading novels, or skiing (more of a luxury rather than a hobby). My internship at Strava has been a wonderful experience to help me learn, grow, and develop into becoming a more well-rounded, conscientious software engineer. Whether it was working with a recent hire or seasoned “Stravioli,” the positive and ambitious company culture shined brightly throughout the course of the summer.
In Transition From a Monolithic to Microservice Architecture
Strava currently maintains a code monolith–a huge Ruby on Rails codebase that controls the user interface, business logic, and database access. For a growing company like Strava and the continuous development of ideas being made into new features, a code monolith doesn’t make for a great developer experience. Trying to parse through a massive codebase and making sure that all the moving parts are in order so that a typo that was somehow glossed over can successfully be changed makes me a little dizzy, personally. The developers at Strava thought so too, and decided to embark on a transition from the Ruby on Rails singular software application to Scala microservices.
Over the course of my internship, I gained insight into the process of restructuring a singular software application into Scala microservices and the benefits of that result. Scala microservices can be thought of as modules that work together but separately. They encourage diversification of teams such that each team has less of a dependence on one another like they would for a monolithic codebase.
Spreading the code functionality across teams in the form of microservices makes for a far better developer experience. With Scala microservices, developers need only talk to a small group of individuals for help and occasionally discuss high-level concerns among a broader group, which keeps projects contained and promotes efficiency. This individualization of teams working on Scala microservices also falls directly in line with how the API is evolving: from a REST API to a GraphQL API.
Acronyms Explained
The mention of API applications might leave you wondering: what is an API? API stands for Application Programming Interface, which really doesn’t do a whole lot for understanding what it actually does. An API is like a bridge between two different islands, where the cars, people, or bikes crossing the bridge are the data packets being exchanged among two software systems. An API is essentially how we retrieve data.
Strava athletes, companies, and partners access Strava data through the API. Much like the structure of a bridge, the structure of an API can vary. A GraphQL API and a REST API are two different architectures. Strava is restructuring their internal API to replace the REST API functionality with GraphQL architecture. This restructure includes differences in how data is fetched and retrieved which are shown below:
As shown by the requests above, while REST is the standardized API architecture, GraphQL has many benefits when it comes to having an efficient way to fetch data. The REST API requires two requests in order to retrieve the nested information, whereas the GraphQL request requires a single query to fetch all associated data. Part of my project involved building out GraphQL resolvers, which are the relayers of information so to speak. To build off our existing example, these resolvers could metaphorically be the tollgates on either side of the bridge between our two islands. These resolvers were built out as the foundation for a new feature called application notes.
What is Pakora?
Pakora is a popular Indian appetizer but I came to know it as one of the Scala microservices at Strava, using a play on the word appetizer to indicate apps, i.e. API applications. Pakora is a new microservice introduced as part of the effort to transition from a code monolith and it is the service that houses all of the API application data. API applications are the means by which athletes, companies, and partners can interact with Strava data, via the Strava API. Companies like Garmin, Peloton, FitBit, and hundreds more have API applications as a means to exchange information with Strava. I became familiar with this experience of how an athlete or company gains access to this data in the first place: creating an application. An application includes a name, a description, associated club, and other useful information all stored within a MySQL database table. The Scala microservice Pakora interacts with all of this data associated with applications.
Do We Need to Take Notes?
The details of my project included building out endpoints to create a new feature for these API applications: application notes. Application notes will allow administrators (people who work at Strava) with the appropriate permissions to document important information to have all in one place. Use cases for application notes might be explaining why an application needs a higher rate limit (number of requests over a specific time interval) or documenting an update. These are things to take note of and can be displayed on the admin applications frontend page along with the details of an application. The notes themselves are stored within a table located in a MySQL database and the backend Scala service Pakora directly accesses this data by leveraging the Slick library. The Thrift server has endpoints used to retrieve this data, and finally, the GraphQL server speaks to the Thrift endpoints to actually get this data to an end user.
End-to-End
After having completed the new notes feature and implementing the backend Thrift and GraphQL endpoints, I transitioned to working in the frontend. The monolith codebase uses haml files for some of the frontend pages that currently exist at Strava. Haml is a markup language that is not widely used. In the transition to a new architecture, these haml files are soon to be replaced by React microfrontends. Microfrontends, similar to microservices, are like modules that make up only a small portion of the frontend, used within a container that puts it all together. The way I became familiar with microfrontends is by React-ifying the current haml files that make up the API applications admin page. This microfrontend will replace the current user interface in the code monolith and it creates a space where administrators can view and manage API applications. Administrators can search applications by the application id or by the owner id. These applications can be viewed, edited, and deleted. The new notes feature in the backend is added in the frontend as well, where administrators can document anything important. Being able to build out the backend endpoints and use them in the frontend was such a gratifying experience and a new discovery of what I enjoy which I can look for in the future.
Closing Thoughts
Throughout the course of my internship, I was encouraged and inspired by the commitment and positivity of the people at Strava. Whether it was running the Strava Mile or watching an impressive Jams presentation, I was overcome with how the people at Strava truly encourage connection. Having and maintaining connections with others requires vulnerability, which can be daunting, but ultimately drives success. I am extremely grateful for getting to spend my summer at Strava, especially with the mentorship of Collin Neuhaus, Anjali Merchant, Yudi Fu, Alayna Richmond and the rest of the Foundation team. Not only have I gained technical skills over the summer, but also have new role models in the people that I worked with.
