ConfPad

When your monolithic codebase has existed for more than two years and its front-end library composition is an amalgam of Backbone, jQuery, React, and Redux, the desire to toss it all and start from scratch can be tempting. And although that is sometimes the right call, there are many ways to refactor your app and migrate chunks of it over to a unified framework while continuously shipping new features. At the Flatiron School, we have faced the problem of a Frankenstein’s monster-esque front-end firsthand. The bulk of our front-end app for Learn.co was redesigned in 2015 and resides in Backbone/Marionette, but a few months later, we decided that all future features would be written in React. For years, the overlap between domains has been small enough that new features could be spun up in React, and the systems could coexist in relative harmony and isolation. However, as both our business and our engineering team have grown, new requirements with ambitious deadlines as well as features like the Learn in-browser IDE have compelled us to rewrite much of the core app’s functionality and reconcile the differences between the libraries and frameworks. Throughout our feature development process, we look for seams where we can rewrite legacy code in React and assess that cost, but when the deadlines take precedence, we build bridges of communication between our systems to buy us time to pay down the technical debt. In this talk, I’ll outline how we look for seams in our app for rewrites. I’ll also walk through concrete examples of new feature requirements and how we built proxies to facilitate communication between Backbone Radio and Redux. Finally, I’ll discuss an example of when a rewrite of one app proved more problematic than anticipated.