January 3, 2012
Currently at Monterail we're building a frontend-heavy app. With a lot of cool stuff. Like preloading data for daily views so that you won't have to wait for every surrounding day to load. Many, many interactive elements that should be really interactive - not in an oldschool, ajax
spinner way. And a lot of other stuff we shouldn't talk about yet.
We decided to put more emphasis on Backbone.js with Rails and build most of the app with this combination.
Below you can find some of our findings on the topic of making those two speak to each other in a nice manner.
Really makes things easier. Organizing your JS code before it meant a lot of things: handling dependencies, minifying & compressing the code, organizing it into a lot of different files and building connections between them. With asset pipeline and it's awesome
Don't forget to:
gzip your JS/css assets
Also makes things easier. It puts backbone.js (& underscore.js) library code into your asset pipeline. It gives you some great generators to get started if you don't know where to start. Definitely worth including in your Gemfile.
Vin MVC done right
Views are classes. You handle logic inside them using the hardcore code, which is receiving so much hate in Rails views. They can have many methods, they do not have to render a single
action. And templates are templates - and nothing else. There is a lot of discussion recently on the matter of Views/Templates in Rails, but you can start implementing it right away. Go and try it. You'll fall in love.
Yes. You will use Rails to render only the core view of the application. Of course, you will have to handle all things around the core of your app.
For example, you should probably leave out:
authentication logic: sign up / in, reset password
steps necessary to use the app: billing pages
But, other than that, you can use the views rendered in JS. What does that mean?
if they do not include any dynamic data, they are lightning fast
if they include dynamic data, you can preload it and they still will be lightning fast
Backbone comes with it's own router. You can utilise pushState without any effort. How cool is that?
Since you'll be doing most of the association/validation work in background, you don't have to worry too much about server responses. It's the same with rendering elements: you'll be doing it in JS, not Rails. You don't have to wait for the request to return the rendered element to actually display them. If you create something, the UI should respond right away and the ajax request can persist the data with it's own pace.
You should, however, prepare a global
something went wrong, reload the page request rescuer - in case of network outages, backend app failures and so on. But it's way easier to manage.
You get it for free. It doesn't have to be public, but if you decide to, it's a matter of adding OAuth as the way of authenticating requests and it's done. (Or you could go with http basic auth, which is obviously bad for a lot of reasons).
With smart caching (give redis-store a try), you'll save tons of server power. You know, relating to the old ruby saying,
views are most resource-consuming.
There are, obviously, downsides, which I'll cover in future (I silently hope that there won't be any reason to do that). And topics I haven't covered. I'm curious about other stacks and ways of doing things. Share in the comments or ping me on Twitter!