Rewriting core sections of your product with a framework unknown to most of your engineering team sounds crazy. But that’s what we’re doing within Intercom right now.
Eight weeks ago, we began an experiment to determine if Ember.js would allow us to raise the bar in terms of our product capability and development speed. We formed a small team tasked with re-implementing a core and complex section of our application, the user list. The required features included filtering, searching, sorting, selection, messaging, tagging and infinite scrolling.
Based on the success of this project, we now have three teams working with Ember.js and we will be releasing a series of improvements to Intercom over the coming weeks.
The Problem
Since its inception, Intercom has mainly consisted of a single Rails app. Rails allows small teams to be extremely productive and it is particularly well suited for the early life of a startup. As the application and engineering team size grows though, it is difficult to maintain this initial agility. The inevitable increase in application complexity has knock-on effects in terms of:
Application startup time
Test speed and TDD feedback time
Developer productivity & happiness
Application brittleness
Server memory usage
The common Rails pattern of delivering a HTML page response coupled with a soup of jQuery behaviour leads to a further increase in slowness, brittleness and complexity. In Intercom, a large amount of useful data from the previous request was needlessly thrown away on each subsequent request. The page header, authenticated user, segments and counts all were regenerated on each page request.
The Solution
Our Ember user list has proved to be a much quicker and vastly simpler application than the Rails version. The application initially loads once and from then on has a granular conversation with our JSON APIs as the user interacts with it. The loaded page context, lost with the Rails version, is reused throughout the life of the application. Changing user segment now requires a single JSON request, not a full page reload. This obviously benefits application speed, but it also results in a simplification of role for the server application as it now focuses on a single task rather than rendering a whole page.
Ember has also allowed us to vastly simplify our user list codebase. Ember conventions make it clear where specific code should live. Routes are responsible for URLs and injecting models into controllers. Models are responsible for loading and persisting server side data. Controllers are responsible for application state and user actions. Templates describe the structure of rendered HTML. Views and components are responsible for low level DOM events and translating these into semantic meaning within an application.
Ember components, based on the W3C web component spec, allowed us to created a set of reusable UI widgets which hide their inner complexity from the rest of the application. Our segment list component is a good example. Using it in a handlebars template is a simple one liner:
{{segment-list-component segments=content activeSegment=segment}}
Internally it renders a list of segments within the available width, placing additional segments in a dropdown list (which happens to be another component). It also handles window resize events, recalculating the displayed list each time. This internal complexity is hidden away from the rest of the application, we only open up this component when we need to make a change to it.
The black box mechanisms that Ember provides extend to other areas too. Working on an area of an Ember application usually means making changes to a particular route and its related model, controller and template. These objects are isolated from other areas of the application resulting in a simple development context. As an engineer, I find it extremely easy to get into “the zone” with Ember.
Watching my colleagues learn Ember over the past number of weeks has been exhilarating. In each case, the initial learning curve was quickly met with a series of “Aha!” moments followed by declarations such as “This is too easy”, “Ember is amazing” and “Where is all the code!?”. There is nothing better than working with a talented team of designers and engineers who are having fun building amazing products. Ember has certainly made it fun.
We’ve built up considerable momentum with Ember recently and the next few weeks will see the roll out of the our new Ember user list, company list, inbox and messaging wizard. Our Rails app will shrink over time, becoming a simple set of clean RESTful APIs and vastly reducing the complexity of the server side of Intercom. From both the client and the server, we’re raising the bar on what’s possible with Intercom and Ember.js is playing an important role. Are you interested in working with Ember.js and Intercom? We currently have a number of engineering roles open in Dublin and San Francisco.
Comments