BetterCloud Front End: Level Up Your Architecture
(Part 1 of …11?)
At BetterCloud, Java rules the roost. Our microservices are 99% Java, and all but four of our engineers primarily program in Java. Even the web front end to our first product, Flashpanel (created long before I joined the company in September 2016), was written in Java and compiled down to Javascript using GWT. For a company of almost exclusively Java developers, this solution was a great fit, and indeed Flashpanel is still our flagship product — it has and continues to serve us and our customers quite well.
But as my predecessors began to plan for our new “Project X” product with the pain points of GWT fresh in their minds, it became clear that a lower-level, more controlled approach would be necessary. The Javascript community was starting to coalesce around certain tools and ideas. Build tools like Gulp, Grunt, & Webpack were becoming ubiquitous and necessary for every web project. Frameworks like Backbone, Ember, Knockout, and Angular were no-brainer choices for any projects above a certain level of complexity. With the clock ticking, they quickly evaluated and chose their new front-end tech stack. Grunt for builds. Angular for app structure. Less for styles. Jasmine for tests.
Time went by, Project X was launched, and over the next year the app grew at the breakneck speed of startup. During that time, Angular 2 was released and introduced a staggering amount of breaking changes, but nonetheless the benefits of the upgrade were clear, and early work began to clear the way for an eventual Angular 2 conversion.
At about this time, I joined the company. I had recently left a job where I had the pleasure of being an early adopter of React. Let me go ahead and add a disclaimer here: I was — and am — a huge fan of and evangelist for React. As someone who has been creating websites for over 20 years, learning React re-energized my love for web development in a way that nothing has since I first learned about the <BLINK> tag all those years ago. But let me also be clear: My goal coming into BetterCloud wasn’t to convince the company to convert the project to React. On the contrary, I was excited to learn Angular 2! I was ready to dig into RxJS and reactive patterns, I looked forward to the safety of Typescript, and I knew SystemJS was making waves as an alternative to Webpack and I wanted to compare the two. I was ready to deep dive into Angular 2 and forget about React for awhile.
But, you know, sometimes plans change.
After a week at BetterCloud, I made a list of near-critical issues I knew we would need to tackle over the next couple of years to avoid collapsing under the weight of our own feature needs (in no particular order):
- Faster local development.
- Faster builds.
- Faster page loading.
- Increased testability and test coverage
- Better integration testing.
- Better interactions between the front end and UX teams.
- More manageable application state.
- Better documentation for shared APIs.
- Consistent coding styles and standards/increased code readability.
- Training the team on all the new patterns we’d be implementing.
There were a number of other systems that needed improvements as well (normalized microservice contracts, style/design system overhaul, i18n/l10n support, etc.), but these ten items were the most immediate and pressing concerns for us.
Over the next series of articles, we will talk about the approach that BetterCloud took to address each of these issues, and how ultimately that approach culminated in a complete conversion to a React/Redux ecosystem. We will discuss the obstacles presented by the conversion effort and our solutions to those obstacles, as well as how we prioritized the list of required changes. And above all, we’ll explain how we managed to keep releasing new features at a healthy pace throughout the entire process.
