Backbone.js for large scale applications – UI Architecture

In my early days as a developer, even before Backbone.js was released, I was eager to learn about good conventions and best practices for organizing code and workflows.
I knew that somewhere, someone managed to recognize a good pattern that will scale in maintainable code, reusable pieces of code and a good & solid “framework” to place this code.
Overtime, I read few articles & watched several talks about software architecture that are relevant to front end development. In this post, I’m covering a journey I had (and still have) with some of the above as well as the overall front end architecture concept behind my latest project Echoes Media Center along with Backbone.js methodology.

How Do I Start with Backbone.js?

First, I like to stick to the concept of Justin Meyer, author JavaScriptMVC: “The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application”.
I’ve realized that Backbone.js implements a certain concept of the well known and used design pattern – MVC.
When I started working on Echoes Media Center I wanted to apply best practices in the architecture of this application – one that I can make use for any application. I wanted to find a good and solid application framework.
After reading several articles, I decided to brainstorm the concept of MVC and have a more thorough look into it – to see how I can use it wisely enough.
I took the very simple concept that Backbone.js applied to Models and Views.
This is a simple Backbone Model that represents of single youtube video:

This is the Backbone View object that uses the above model:

This is the view’s associated template:



Combining these two results in a simple small MVC module based on Backbone.js. It is important to understand that the Backbone.View object is actually in the role of the “classic” controller of MVC, while the “template” that is referenced in this object plays the role of the “classic” view of MVC.
This concept appealed to me in the sense that whenever I update or change the model, the view will take care to reflect the changes in the UI.
To achieve this, i could simply use it like so:

In that moment of understanding, I was really inspired and it became obvious to me that this very basic concept should play along with a larger module – or even a whole application.

Minimalism and Backbone.js

Backbone.js and its minimalism approach of implementing MVC appealed to me. It seemed to be elegant, organized and to have everything in its place – including the soon to come approach for applying software architecture to a front end code.
I took the very simple concept that I applied to a single youtube item, and i understood that the same should be done for any module – let it be a user details card, a youtube playlist data and eventually – a music player application.
To my understanding and experience, I started planning the model of Echoes. I figured out that in the end, I would like to apply the same concept of that “coolVideo” code to a similar minimalstic approach:

With this approach, I can be sure that whenever the model is updated, the changes will be applied to the UI – let it be new search results, playing a new video and asking to query my favorite videos.
From this point, it was quite obvious to take the “divide & conquer” approach for simplifying the big objects of “EchoesView” & “EchoesModel”.

The relevance of a Backbone.Router in Echoes

With the concept of having a clear separation of Echoes Model & View, I continued the “C” of MVC – the controller.
In one of my other posts, I explained the importance of a backbone router to function as an application controller – and in Echoes case – a controller to Echoes api.
Soon, it appeared to me, in a minimalistic kind of a way, that it only makes sense to pass Echoes Model as a reference.

In this way, the application has One Model, and it can be access through the view (or its sub views) or through the router in the form of a url.
Also, with the router implemented in such a way, I can define several urls to be mapped to a certain view controller.

Divide & Conquer – Full Architecture

Following the concept above, I decided to further simplify Echoes model to allow modular services and data that the player can supply to its views.
Eventually, the application model has been divided to several distinct nested models (and collections) , that, in order to allow some of the player’s data model to be treated as modular data. Since the whole architecture model in Echoes attempts to stick with data driven architecture, each view may get the Echoes Model as a reference to work with. A top level view may choose to pass any sub model to its sub views to interact with. This assures that any changes to the model will be reflected in any other views that are bonded to a model’s change events.

Echoes Backbone.js Architecture Scheme
This drawing illustrates the general architecture concept built into Echoes

Final Thoughts

This architecture seems to be working great with Echoes and any other standard single page application. With this concept in mind, I achieved modular and maintainable code that can be reused for other applications as well.
I think that one of the most important rules to have in mind is to first think about the data (application model) and how to update it – meaning – be data driven in mind. Update the model – and the view will take care of rendering and reflecting it.
Overall, Echoes is an open source project, and you can fork it, pull request or just read the code at github.
Your thoughts are welcome.