Life on the bleeding edge: front-end architecture

Re-architecting Apteligent’s web application, part 2

Last week I talked about the difficulties we’ve been experiencing that led us to re-architect our web application. In the rest of this series, I’ll discuss the technology choices we made in doing that re-architecture.

So let’s get down to brass tacks. A new web application will need a server side and a client side, each of which requires making a slew of technology decisions.

In the case of the front-end, it had become clear that we needed to reset our thinking about how we built the UI. Axing Backbone in favor of another framework that did more or less the same thing wasn’t going to cut it, because we’d end up facing the same problems with hard-to-understand data flow and over-fetching.

Enter Flux, Facebook’s new front-end application architecture. You should really watch the video to understand Flux and its inception, but in a nutshell here’s how it works:

User interactions with the view affect the system through actions that are sent to a central dispatcher. The dispatcher in turn triggers the likewise central store — in charge of maintaining the application state — to update itself through, for example, server interaction.

Flux’s beautiful simplicity

Views subscribe to the store to get updates on the information they care about. And when the store updates itself, it notifies subscribers of changes, which triggers them to re-render.

Pretty simple, right? Let me highlight a few aspects of the Flux architecture that are of particular import:

• Data flow is uni-directional.
• The central dispatcher and store are clearinghouses for events and shared information, respectively.
• Views re-render on every change to the parts of the store they care about, by default rather than by configuration.

And here’s why they’re important:

• Uni-directional data flow makes understanding — and predicting — the behavior of the application easier.
• Centralizing the event handling regulates the data flow and, again, makes the system more orderly and predictable.
• Centralizing the shared information and updates to views based on changes in that information — once more, with feeling — adds orderliness and predictability to the system.
• The fact that views always re-render optimizes for the most common case in your development, but you’re given the flexibility to limit those re-renders based on circumstances.
• Perhaps most importantly, the framework you choose takes care of most of the boilerplate associated with actions and view re-renders. In one fell swoop, that reduces errors and the amount code you have to write. There are many frameworks out there; our choice is the subject of a future post.

By choosing Flux, we’ve set ourselves up to write less boilerplate, understand data flow better, and spend our efforts on the parts of our applications that matter. In other words, to develop new features faster, with less code and higher quality. BOOM.