Building an application with Backbone workflows
A non-typical Backbone example
When you start looking into Backbone, you may notice that many of the readily available example sites are setup in the same pattern: display a list of things with a list view and a details. This kind of of example plays to the strengths of the Backbone API. It has some models, some views, and some routing that correspond to standard REST operation URLs. It’s a good type of example that shows what you can do with Backbone right out of the box.
Of course, there are other application types that don’t conform to such a list and details model. Rather than shoe-horning my particular needs into that type of pattern, I wanted to explore what it would look like to have a multi-step workflow in Backbone. One that didn’t overly rely on the built-in routing mechanism nor assumed an API with normal REST conventions.
For the sake of this series, the application that will be built is setup around entering new claims for a policy. This problem domain should be simple enough to easily grasp while still allowing for multiple data types and separate REST services.
While the end goal of this series is the creation of a workflow in Backbone, several steps are required to get to that point. The series will be broken down into the following posts:
- Building an API with Node, Express, and Mongoose
- Testing the API with Jasmine
- Hosting the Node API in nginx with a reverse proxy
- Building a Backbone application with a workflow
- Testing the application: models and views
- Testing the application: workflows
- Testing the application: object interactions and AJAX calls
The example code for this series will be available on GitHub. As each post in the series is published, the corresponding code will be added to the repository.
The tech stack
When all is said and done, the following items will be part of the tech stack:
- Jasmine Ajax