A Pattern for Success: Component Driven Architecture

December 14, 2015 | by Ryan Day | Architecture


Deciding what development frameworks make the most sense for your effort can be confusing at best when faced with all the competing approaches.

Front-end development frameworks and libraries, by their very nature, are an opinionated lot. The teams that develop and maintain libraries such as AngularJS, EmberJS, React and others arrive at their particular approach to solving the problems of modern, front-end application development through their collective experience.

Choosing the Right Path

You will inevitably find a well defined path to integrating framework XYZ into an application. But how it works isn’t the real issue - whether it works for you is.

We are talking here about Architecture Patterns, about which there is no shortage of opinions. DePalma Studios recognizes this, but we avoid becoming bogged down with the dogma that comes with each choice of development frameworks. Through our years of collective experience, we have adopted architecture patterns that allow us to produce applications that are scaleable and easy to maintain.

These patterns do not rely on any particular choice of technology, but rather they can be applied in a cross-boundary fashion. Whether we build an application with Backbone, Ember, Angular, etc., we rely on a core set of patterns to ensure a successful delivery that best fits our customer's unique needs.

Foundation of Components

The foundation for these patterns revolves around what we refer to as a Component Driven Architecture. Essentially, our visual engineering team divides up an application into a set of independent UI components. No hard rule governs how small or large each component can be, but each is either a Container Component or a Child Component.

Container Components, as the name implies, serve as containers for the Child Components. The Container Components organize larger, functional sections of the applications and typically will pull in all the data needed for that section, ensuring its Child Components have whatever they need to perform their function.

Application State

This data comes from a well-defined service layer in the application. Application state is created, modified, and maintained in this service layer. This is essentially how you decide what type of operations happen inside an application, i.e. where they take place, either in a service module or a component module. Put simply: if the operation is somehow mutating application state, specifically mutating model data, then it will happen inside a service. Otherwise, it can happen inside an individual component.

This makes the application much easier to maintain and debug as it grows in size. Each component's data is isolated from other components, and any interaction by that component with an external entity such as another component or service happens through a well-defined eventing process.

Unidirectional Data Flow

At a higher level, this means we deliberately enforce unidirectional data movement in an application. Frameworks such as KnockoutJS and AngularJS, to name a few, allow for two-way data binding, but once you allow different parts of your application to mutate data up and down the scope tree it, tracking the current state the the application becomes confusing and difficult.

The easiest way to avoid this problem is to simply not do it, period, no exceptions. Data moves in one direction, from the REST api, to the application services. Any state that needs to be updated is taken care of here, and the changes are pushed downstream to the Container Components, and finally to the Child Components where the UI can be updated for the end user.

You may hear something like this: "Well, the application is broken down into discrete, re-useable components." Reusable is fine, but that only scratches the surface of the efficiency and power of a Component Driven Architecture. If you're using the building blocks of your application in a haphazard, poorly defined manner, you've missed the boat the true value of this approach.

Topics: Architecture