Building a Single-Page App: Backbone, Node.js, and Beyond

Building a Single-Page App:
Backbone, Node.js, and Beyond

Spike Brehm, Front End Engineer
spike@airbnb.com
@spikebrehm
September 12, 2012

Thursday, September 13, 12

Past: Why Single-Page Apps
Present: How we built Wish Lists
Future: In pursuit of the Holy Grail


Past
Why Single-Page Apps


Airbedandbreakfast.com



• Started in 2008 as a Rails 2.x app



• Now Rails 3.0



• Now Rails 3.0
• Still stuck in old, page-based paradigm


What is a Single-Page App?



• Navigate in the app without page refresh



• Application logic in the client



• Application logic in the client
• Fetch data on demand


Why Single-Page Apps?



• Faster JavaScript runtimes



• New browser features (pushState,
localStorage, etc.)



• New browser features (pushState,
localStorage, etc.)

• Heightened user expectations


Two Approaches

The Easy Way

The Hard Way
aka “The Holy Grail”


The Easy Way


The Easy Way

• JavaScript app runs entirely in client


The Easy Way


• Server technology agnostic


The Easy Way



• Can use Backbone to structure app


The Easy Way




• Poor SEO -- not crawlable


The Easy Way





• Performance hit to download & evaluate JS before
rendering


The Easy Way





• Performance hit to download & evaluate JS before
rendering

• Good for apps behind login, or tools


The Hard Way
aka “The Holy Grail”


The Hard Way


The Hard Way
• Routing, templating, application logic, utilities run on
client and server


The Hard Way
client and server

• Navigate to any page, HTML rendered in client -- hit
refresh, serves up HTML


The Hard Way
client and server


• Must render full page of HTML without access to DOM
(or ﬁnd a faster DOM implementation)


The Hard Way
client and server



• Requires JavaScript runtime on the server (or DSL that
compiles down to JavaScript -- think GWT)


The Hard Way
client and server




• Backbone not a good ﬁt


The Hard Way
client and server





• Provides good SEO


The Hard Way
client and server





• Provides good SEO

• Better performance


Performance

Improving performance on Twitter.com
http://engineering.twitter.com/2012/05/improving-performance-on-
twittercom.html

“Time to ﬁrst tweet”


Stops and Starts


Stops and Starts

• mustache.rb: code duplication


Stops and Starts


• therubyracer: performance, stability


Stops and Starts


• therubyracer: performance, stability

• PhantomJS: slow, overly complicated


Present
How we built Wish Lists


Technologies


Technologies
• MV*: Backbone.js


Technologies
• Templating: Handlebars


Technologies
• UI & Layout: Oxygen (Airbnb’s Bootstrap)


Technologies
• CoﬀeeScript


Technologies
• CoﬀeeScript
• HTML5 pushState


Technologies
• CoﬀeeScript
• HTML5 pushState
• api.airbnb.com

Rails-Backbone interface:
index.html.erb
<div class=”app_view”></div>

<script>
!function(){
I18n.extend(<%= @phrases.to_json.html_safe %>);

Airbnb.Api.config(<%= @api_config.to_json.html_safe %>);

window.WishlistsApp = new AIR.Apps.Wishlists(
<%= @init_data.to_json.html_safe %>
);
}();
</script>


Bootstrapping the app
window.WishlistsApp = new AIR.Apps.Wishlists({
“listings”: [...],
“wishlists”: [...],
...
});


window.WishlistsApp = new AIR.Apps.Wishlists({
“listings”: [...],
“wishlists”: [...],
...
});

WishlistsApp.get(‘wishlists’)

=> [Object, Object, Object, ...]



• Each action bootstraps whatever data
needed on ﬁrst pageload



• Each action bootstraps whatever data
needed on ﬁrst pageload

• Subsequent data is requested on-
demand


App Initialize
class AIR.Apps.Wishlists extends Backbone.Model

initialize: =>
@wishlists = new AIR.Collections.Wishlists @get('wishlists')
@listings = new AIR.Collections.Listings @get('listings')
...

new AIR.Routers.Wishlists({app: @})


App Initialize
class AIR.Apps.Wishlists extends Backbone.Model

initialize: =>
@wishlists = new AIR.Collections.Wishlists @get('wishlists')
@listings = new AIR.Collections.Listings @get('listings')
...

new AIR.Routers.Wishlists({app: @})

WishlistsApp.wishlists
=> Wishlists
_byCid: Object
_byId: Object
length: 11
models: Array[11]
__proto__: ctor


Backbone Router


Backbone Router
• Translates URL changes to method
calls


Backbone Router
calls

• Source of global app state


Backbone Router
calls

• Keep state out of views


Backbone Router
calls

• Keep state out of views
• Idempotent view rendering


Backbone Router
class AIR.Routers.Wishlists extends Backbone.Router
routes:
'wishlists/:id' : 'show'
'wishlists/:id/edit' : 'edit'

...

show: (id) ->
@app.fetchWishlist id, (model) =>
view = new AIR.Views.Wishlists.ShowView {@app, model}
@updateContent(view)


Data-on-demand


Data-on-demand
# AIR.Apps.Wishlists

fetchWishlist: (id, callback) ->
model = @wishlists.get(id)
if model?
callback(model)
else
@appView.setLoading(true)
@wishlists.fetchById id, (model) =>
@appView.setLoading(false)
callback(model)


api.airbnb.com


api.airbnb.com
• Used by iOS, Android, Mobile Web clients


api.airbnb.com

• No Cross-Domain XHR


api.airbnb.com


• JSONP for GET; but no POST, PUT, DELETE


api.airbnb.com


• JSONP for GET; but no POST, PUT, DELETE

• Added CORS support in API to allow
requests coming from valid Airbnb domain
(*.airbnb.com, *.airbnb.co.uk, *.airbnb.de...)


Accessing API from
Backbone

Airbnb.Api.getUrl(‘/v1/users/1234’)


Accessing API from
Backbone

Airbnb.Api.getUrl(‘/v1/users/1234’)

=> "https://api.airbnb.com/v1/users/1234?currency=USD&locale=en&
key=...&oauth_token=..."


Accessing API from
Backbone
class AIR.Models.WishlistUser extends Backbone.Model
jsonKey: 'user'
apiPath: -> "/v1/users/#{@id}"

...

_.extend AIR.Models.WishlistUser.prototype, AIR.Mixins.ApiResource


Accessing API from
Backbone
AIR.Mixins.ApiResource =
url: (options = {}) ->
apiPath = options.apiPath || @apiPath
if _.isFunction(apiPath)
apiPath = apiPath.call(@)
Airbnb.Api.getUrl(apiPath)

sync: (method, model, options) ->
options = _.defaults options,
url: @url(options)
Backbone.sync method, model, options


AIR.Views.BaseView
class AIR.Views.BaseView extends Backbone.View
postInitialize: ->
postRender: ->
getRenderData: ->
cleanup: ->
...


Before
class WishlistIndexView extends Backbone.View

template: 'wishlists/wishlist_index_view'

render: ->

@$el.html JST[@template](@model.toJSON())

@renderSomeThing()

@

renderSomeThing: -> ...


After
class WishlistIndexView extends AIR.Views.BaseView

template: 'wishlists/wishlist_index_view'

postRender: ->

@renderSomeThing()

renderSomeThing: -> ...


Before, Part II

...

render: ->

@$el.html JST[@template](@model.toJSON())

@


Before, Part II

...

render: ->

data = _.extend @model.toJSON(),

show_share_button: @options.show_share_button

@$el.html JST[@template](data)

@


Before, Part II

...

render: ->

@$el.html JST[@template](@getRenderData())

@

getRenderData: ->

_.extend @model.toJSON(),



After, Part II

...

getRenderData: ->

_.extend super,



cleanup()
class AIR.Views.BaseView extends Backbone.View

...

cleanup: ->

@undelegateEvents()

@model?.off(null, null, @)

@remove()


cleanup()

...

cleanup: ->

super

@someChildView.cleanup()

clearInterval(@interval)


cleanup()

Backbone 0.9.2 adds new method:
Backbone.View.prototype.dispose()


Modular, DRY views


Modular, DRY views

• Re-usable bits of markup and
behavior


Modular, DRY views

• (screenshot)


Subview initialization
class EditView extends AIR.Views.BaseView

...

postRender: ->

@renderPrivacyDropdown()

renderPrivacyDropdown: ->

view = new AIR.Views.Shared.PrivacyDropdownView

'private': @model.get('private')

@$('data-privacy-dropdown').replaceWith view.render().el


Subview initialization
class EditView extends AIR.Views.BaseView

...

postRender: ->

@renderPrivacyDropdown()

renderPrivacyDropdown: ->

view = new AIR.Views.Shared.PrivacyDropdownView

'private': @model.get('private')

view.on ‘private-changed’, (isPrivate) =>

# do something

console.log(isPrivate)

@$('data-privacy-dropdown').replaceWith view.render().el


What goes into a
view?


What goes into a
view?
• app/assets/coffeescripts/views/shared/privacy_dropdown_view.coffee


What goes into a
view?

• app/assets/templates/views/shared/privacy_dropdown_view.hbs


What goes into a
view?


• app/assets/stylesheets/partials/_ privacy_dropdown_view.scss


What goes into a
view?


• app/assets/stylesheets/partials/_ privacy_dropdown_view.scss

• lib/phrase_bundles/privacy_dropdown_view.rb


Rdio’s Backbone-based View Component Framework
Justin Tulloss, @justin_tulloss
http://www.youtube.com/watch?v=TB-l2nF67iU


http://airbnb.github.com/inﬁnity

Inﬁnity.js

• (screenshot)


I18n.js


I18n.js

• 192 countries


I18n.js

• 192 countries
• 31 locales


I18n.js

• 192 countries
• 31 locales
• Client-slide translation library


I18n.t()
I18n.t('edit_wish_list');


I18n.t()

"Edit Wish List"


I18n.t()

"Edit Wish List"

<h1>{{t "edit_wish_list"}}</h1>


I18n.t()

"Edit Wish List"

<h1>{{t "edit_wish_list"}}</h1>

<h1>Edit Wish List</h1>


Interpolation
I18n.t('owners_wish_list', {name: name});


Interpolation

"Spike’s Wish List"


Interpolation


<h1>{{t "owners_wish_list" name=name}}</h1>


Interpolation


<h1>{{t "owners_wish_list" name=name}}</h1>

<h1>Spike’s Wish List</h1>


I18n.extend()
I18n.extend({
"edit_wish_list": "Edit Wish List",
"owners_wish_list": "%{name}’s Wish List",
...
});


I18n.pluralize()
I18n.pluralize("Listing", listings);


I18n.pluralize()

3 Listings


I18n.pluralize()

3 Listings

<span>{{t_pluralize "Listing" count=listings}}</span>


I18n.pluralize()

3 Listings

<span>{{t_pluralize "Listing" count=listings}}</span>

<span>3 Listings</span>


pluralize() just calls t()
{

"pluralize.Listing.zero": "%{count} Listings",

"pluralize.Listing.one": "%{count} Listing",

"pluralize.Listing.many": "%{count} Listings"

}


PhraseBundle


PhraseBundle
• Composable bundles of I18n phrases


PhraseBundle
• Keep phrases DRY


PhraseBundle
• Keep phrases DRY
• Separation of concerns: treat phrases
as data source


PhraseBundle
I18n.extend(<%= {
'map_view' => t('wishlists.Map View', :default => 'Map View'),
'list_view' => t('wishlists.List View', :default => 'List View'),
...
}.to_json.html_safe %>);


PhraseBundle
I18n.extend(<%= {
...
}.to_json.html_safe %>);

I18n.extend(<%= PhraseBundles::Wishlists.new.to_json.html_safe %>);


PhraseBundle
module PhraseBundles
class Wishlists < PhraseBundle
includes :privacy_dropdown, :share_dropdown, :wishlists_modal

def phrases
{
...
}
end
end
end


CDN Asset URLs
• Image paths need to go through Sprockets


CDN Asset URLs
Development: https://localhost.airbnb.com:3001
/static/icons/facebook.png


CDN Asset URLs
Development: https://localhost.airbnb.com:3001
/static/icons/facebook.png

https://a0.muscache.com/airbnb
Production:
/static/icons/facebook-
e04e8c0c43e40ff7a277a3a7a734ed52.png


CDN Asset URLs


CDN Asset URLs
window.ImagePaths = <%= map_image_paths([
'icons/facebook.png',
...
]).to_json.html_safe %>;


CDN Asset URLs
...

ImagePaths['icons/facebook.png'];
=> “https://a0.muscache.com/airbnb
e04e8c0c43e40ff7a277a3a7a734ed52.png”


CDN Asset URLs
...

ImagePaths['icons/facebook.png'];
=> “https://a0.muscache.com/airbnb
e04e8c0c43e40ff7a277a3a7a734ed52.png”

<img src=”{{image_path “icons/facebook.png”}}” ...>


Future
In pursuit of the Holy Grail


Backbone.js is just a
stopgap


stopgap
• Backbone.View is DOM-centric


stopgap
• Backbone.History is window-centric


stopgap
• Backbone.History is window-centric
• Backbone.Model and
Backbone.Collection are more
portable (with override of
Backbone.sync)


It’s a great time to be a JavaScript hacker.


It’s a great time to be a JavaScript hacker.

But not a great time to build modern,
plug-and-play web apps.


Testing the Node.js Waters


We are refactoring m.airbnb.com with a
Node backend instead of Rails.



Primary goal is to learn how to
productionize a Node app.



Primary goal is to learn how to
productionize a Node app.

Secondary goal is to prototype a new way
of building web apps.


Node Frameworks


Node Frameworks
Geddy, Tower
Rails-inspired. Not utilizing Node’s strengths.


Node Frameworks
Geddy, Tower

SocketStream
Modular, real-time, but optimized for The Easy Way.


Node Frameworks
Geddy, Tower

SocketStream

Meteor
Solves for The Hard Way, but all-or-nothing. Alpha.


Node Frameworks
Geddy, Tower

SocketStream

Meteor
Solves for The Hard Way, but all-or-nothing. Alpha.

Derby
Solves for The Hard Way, but not very modular. Alpha.


Node Frameworks
Active authors.
Active mailing list.
Small, if messy, codebase.

Derby


Node Frameworks
Derby
Active authors.
Active mailing list.
Small, if messy, codebase.



Other Resources
Single Page App Book, by Mikito Takada
http://singlepageappbook.com/

view.json, by Mikito Takada
http://mixu.net/view.json/

Building The Next SoundCloud
http://backstage.soundcloud.com/2012/06/building-the-next-
soundcloud/

Sean McBride, Bridging the Client-Server Divide
http://seanmcb.com/client-server-divide/

NodeUp Podcast
http://nodeup.com/


res.end()


Let’s chat
@spikebrehm


Building a Single-Page App: Backbone, Node.js, and Beyond

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Building a Single-Page App: Backbone, Node.js, and Beyond

Semelhante a Building a Single-Page App: Backbone, Node.js, and Beyond (20)

Mais de Spike Brehm

Mais de Spike Brehm (11)

Building a Single-Page App: Backbone, Node.js, and Beyond