Presentation: Refactor Frontend APIs & Accounting for Tech Debt

Julia: I work at Indiegogo as a software engineer on the Backer Experience and Trust team, a team dedicated to the delivery of the backer experience. A backer is someone to goes on Indiegogo and backs a campaign. Our team also works on the tools entrepreneurs use to build their campaigns.

Julia: Indiegogo is most known as a crowdfunding website. After joining the company, I’ve learned that it’s a lot more than that. Indiegogo is an entrepreneur platform. Anyone in the world can become an entrepreneur and reach millions of people. We have resources to help entrepreneurs throughout all the stages needed to fulfill a product. In the past year, we’ve launched a immensely successful product marketplace.

Julia: We have both web and mobile apps. Indiegogo is available on iOS and Android. Our website receives the most traffic. It’s a Ruby on Rails app that uses Angular 1 in the client side. Currently, I’m part of a sub-team that is focusing on web performance. We’re working on getting our campaign page to load faster on mobile web and desktop. We’re currently thinking about switching to another front-end framework -- maybe Angular 2, React, or even Elm.

Julia: Several months ago, I was the engineering lead for adding Apple Pay support to perks with itemization. Prior to that, two separate had worked on adding itemization to perks and Apple Pay support to perks. I was part of the latter team. Both teams were working in the same area of the codebase, but were on tight schedules to deliver -- so as a result, a lot of technical debt was accrued. I had to deal with cleaning up this debt in order to deliver a new feature that combined both projects. Consolidating the front-end APIs for accessing a perk was main refactoring work that had to be done.

Technical debt is hard to anticipate at the beginning of a project. It’s important to account for it from the beginning of the software development process. In my project, I learned to take time to investigate technical debt and determine how much of it can be fixed without compromising delivery. For instance, I created “chores” for every refactor that needed to be done and determined how much effort it would take to complete it. Refactoring can take you down into an endless rabbit hole, and it’s important to prioritize. Tackling technical debt as you go as a way to refactor without having to fall into the rabbit hole.

Technical debt is an ugly word and it’s not a fun thing to talk about, so my talk tells the story of my project through the lens (gifs) of Baz Luhrmann’s Romeo + Juliet. Hopefully it’s an entertaining and also enlightening experience!

Julia: My talk isn’t how-to guide to refactor front-end APIs in Rails and Angular. Everyone is working with unique codebases across various frameworks. I’m using the example of my project to demonstrate how we can refactor front-end APIs and minimize technical debt. Overall, tackling technical debt should be part of engineering best practices. It makes product better and developers have the responsibility to communicate this to non-technical leaders like product managers.

Julia: The two projects that accrued technical debt had duplicate services that fetch perks from the server. On the server side, I created a base serializer for perks that perks with itemization can inherit from. This base serializer follows the decorator pattern and allows for separation of concerns. On the client side, I created one service to fetch perks and consolidated duplicate TypeScript definitions. I also created a central location for services that make API calls to the server. Previously, these services were scattered across the codebase in separate modules.