Kicksend Practices Part I – Backend and Web

Kicksend is a multiple platform application, we have clients on iOS, Android, OS X, Windows and the web. All of this is powered by a Rails backend, which we treat as an API server. Here are a couple of practices we have in play right now.

The Backend

(Taken by Tom Raferty)

Avoid to_json

Responses are the equivalent of views for your API; your presentation layer. Hence, you shouldn’t use to_json to generate your response, the same way you wouldn’t put presentation logic in your model. Use a templating system/builder like RABL (which we use) or Jbuilder.

Action cache

We use action caching, based on the principals of key based cache expiration. This keeps cache invalidation very simple for us as they auto-expire whenever an object or a collection is updated. We use a couple of helpers to simplify our cache key generation.

The Web App

The Kicksend web app is made with Backbone.jsHandlebars in Coffeescript. We treat it as a standalone entity, and it consumes our API the same way as our other apps do. There’s no special treatment.

Keep the UI responsive

As much as possible, keep your app responsive and don’t block the user. People have the expectation that rich clients are snappy. Some tips:

  1. Design your app such that you don’t have to use { wait: true }.
  2. Assume that the request will be a success, and have an error state with a retry otherwise.
  3. Load commonly used collections in the background, regardless of the page the user visits.
  4. Keep things asynchronous.


Keep your models and collections independent from your views. This makes our views easily reusable (and even nestable). We instantiate individual models in our router and app wide collections on load, and never within the view. In the rare event you need to instantiate a model/collection from within a view, ensure that they are used only within the lifecycle of the view.

Have a single representation of each resource

For each resource (eg. api/lists/1), we maintain a single model representation of it as much as possible. This ensures that the right models are used by our views, so that the any model changes are appropriately reflected in the UI. We use our app wide collections to maintain the “gold” model representation of each resource. Here’s an example:

  1. You navigate to “″ to edit your Family list.
  2. To reduce wait time, we make an API call to “/api/lists/1″, and instantiate a single List model – let’s called it Model 1. We then render the list edit page with Model 1.
  3. In the background, we load up our collection of all your lists (KS.lists), which will contain another model of your Family list – we’ll call this Model 2. The rest of the app operates off Model 2.
  4. Any changes to Model 1 is synced back to Model 2 within KS.lists.

Use a view manager

In a single page app, instantiating and destroying your view is important. Mismanagement can lead to a bloated DOM and stray event bindings. Taking a cue from Derick Bailey, we use a singleton to handle all view transitions and cleanups. The Kicksend app has two “containers” that we render views in – within the page or in a modal. With our View Manager, we can easily render any view in either container.

Over the next couple of months, we’ll be discussing more practices we use throughout the Kicksend ecosystem, so stay tuned. As always, we are always looking to improve and we love to hear any suggestions or improvements you may have!

Catch us on Twitter at @Kicksend and @derrickko. Sounds interesting? We’re hiring.


  • Reply June 25, 2012

    Brian Danowski

    How do you handle auth in your backbone app?

  • Reply June 26, 2012


    Cann’t wait for more info on viewmanager.
    I current fight for controller of Backbonejs.
    I really miss mvc, but backbone has mvp.

  • Reply June 27, 2012

    Kevin Chiu


    I was wondering if you could elaborate more on not using to_json?

    I have used this a few times without a second thought when putting together JSON APIs.

Leave a Reply

Leave a Reply