Book Image

Mastering Backbone.js

By : Abiee Echamea, Abiee Echamea
Book Image

Mastering Backbone.js

By: Abiee Echamea, Abiee Echamea

Overview of this book

Backbone.js is a popular library to build single page applications used by many start-ups around the world because of its flexibility, robustness and simplicity. It allows you to bring your own tools and libraries to make amazing webapps with your own rules. However, due to its flexibility it is not always easy to create scalable applications with it. By learning the best practices and project organization you will be able to create maintainable and scalable web applications with Backbone.js. With this book you will start right from organizing your Backbone.js application to learn where to put each module and how to wire them. From organizing your code in a logical and physical way, you will go on to delimit view responsibilities and work with complex layouts. Synchronizing models in a two-way binding can be difficult and with sub resources attached it can be even worse. The next chapter will explain strategies for how to deal with these models. The following chapters will help you to manage module dependencies on your projects, explore strategies to upload files to a RESTful API and store information directly in the browser for using it with Backbone.js. After testing your application, you are ready to deploy it to your production environment. The final chapter will cover different flavors of authorization. The Backbone.js library can be difficult to master, but in this book you will get the necessary skill set to create applications with it, and you will be able to use any other library you want in your stack.
Table of Contents (17 chapters)
Mastering Backbone.js
About the Author
About the Reviewers

Subapplications based architecture

We can compose a Backbone application with many independent subapplications. The subapplications should work independently. You can think about each one as a small Backbone application, with its own dependencies and responsibilities; it should not depend on other subapplications directly.

Subapplications should be focused on a specific domain area. For example, you can have a subapplication for invoices, another for the mailbox, and one more for payments; with these subapplications in place, you can build an application in order to manage payments through email.

To decouple subapplications from each other, we can build an infrastructure application responsible for managing the subapplications, bootstrapping the whole application, and providing the subapplications with common functions and services:

Figure 1.1. Composition of a Backbone application with subapplications

You can use the infrastructure application to provide your subapplications with services such as confirmation and dialog messages, notification pop-ups, modal boxes, and so on. The infrastructure application does nothing by itself, it behaves as a framework for the subapplications.

When a subapplication wants to communicate with another subapplication, the infrastructure application can be used as a communication channel, it can take advantage of the Backbone.Event object in order to send and receive messages.

In the following figure, you can see a scenario where the subapplications communicate through the infrastructure application. When the user clicks on Compose message in the Mailbox subapplication, the infrastructure application creates and renders the Compose mail subapplication and allows the user to write an e-mail.

When the user is done, they have to click on the Send button in the Compose subapplication; then the e-mail is sent through a RESTful API or using plain SMTP, don't care, the important thing is that, when it finishes, it triggers an event in the email:sent infrastructure application.

The infrastructure application forwards the event to the Mailbox subapplication, so that the list of emails that are sent can be updated. Another interesting thing is that the infrastructure application can use the email:sent event to show a successful pop-up message to the user to tell them that the email was successfully sent:

Figure 1.2. Communication between subapplications

Subapplication anatomy

As mentioned earlier, a subapplication is like a small Backbone application; they should be independent of other subapplications and work as a standalone. You should be able to put the Compose mail subapplication on a blank page without any other subapplication and still be able to send emails.

To achieve this, the subapplications should contain all the necessary objects that are to be auto-contained. You can see that the entry point of the subapplication is Backbone.Router. When the browser changes the URL and a route is matched for a given subapplication, the router creates a subapplication controller and delegates it the route handling.

The subapplication controller coordinates the models/collections and how they are shown. The controller can instruct the Application infrastructure to show a loading message while the data is fetched and when it's done, the controller can build the necessary views with the models and collections that are recently fetched in order to show them in the DOM.

In short, a subapplication behaves exactly like a small Backbone application, with the main difference being that it uses the Application infrastructure to delegate common tasks and a communication channel between the subapplications.

In the next sections, we will examine how these parts are connected and I will show you the code for a working Contacts application. The following figure shows an anatomy view of a subapplication:

Figure 1.3. Anatomy of a subapplication