WISH LIST
server and client rendering of
single page apps
Thomas Heymann	

@thomasheymann	

github.com/cyberthom
WHAT WE’VE BUILT
WISH LIST
•  Shopping tool	

•  Track products	

	

•  Receive alerts	

•  Share lists
GOALS & OBJECTIVES
•  Improve UI	

•  Pull out wish list into separate stack of services	

•  Update front-end code using modern frameworks and best practices	

–  Perfect candidate for SPA due to mutability	

•  Minify duplication which led to inconsistencies
SHARED CONCERNS
Server	

 Client	

USER
INTERACTIONS	

LOGGING	

MONITORING	

ROUTING	

PRESENTATION
LOGIC	

APPLICATION DATA	

views / layout / templates	

models / collections /
business rules / API calls	

events / animations	

SITE FURNITURE	

ANALYTICS	

i18n	

translations / date and
currency formatting	

STYLING
•  Developers get DRY and MV*	

•  Users get best of both worlds: 	

–  fully rendered pages (instant content)	

–  responsiveness of SPA	

•  Business gets SEO	

	

•  Everybody’s happy 🌈😃🎉
ENVIRONMENT AGNOSTIC
•  EvenThoughtWorks agrees 👌	

TECH RADAR
http://www.thoughtworks.com/radar/#/techniques	

Client and server rendering with same code 	

	

Increasingly, HTML is rendered not only on the server but also on the client,
in the web browser. In many cases this split rendering will remain a necessity
but with the growing maturity of JavaScript templating libraries an interesting
approach has become viable: client and server rendering with same code. 	

HOLD ASSESS TRIAL ADOPT
ARCHITECTURE & TECH STACK
SYSTEMS OVERVIEW
WISHLIST	

 API	

SITE FURNITURE	

Aggregation Layer	

Presentation Layer	

API	

MAGAZINE	

API	

CATALOGUE	

Core Services	

& Storage
TECH STACK
SERVER	

 CLIENT	

node.js	

 IE8+	

Express	

 Backbone Router	

cheerio	

 jQuery	

Backbone	

Handlebars	

require.js	

App
•  Renders nested views	

•  Re-attaches views to DOM client-side	

APP COMPONENTS
VIEW ASSEMBLER	

ROUTER	

MODEL FACTORY	

SERIALIZER	

SYNCER	

•  Ignores duplicate requests and caches responses	

•  Injects headers	

•  Matches URLs and extracts params	

•  Executes controller logic	

•  Serializes app data to JSON server-side	

•  Deserializes app data client-side	

•  Creates models	

•  Enforces singletons for data bindings
PAGE REQUEST	

1.  Instantiate app	

2.  Dispatch route (run controller logic)	

3.  Render views	

4.  Serialize data (models/collections)	

5.  Decorate page with site furniture	

6.  Send response	

SERVER WORKFLOW
PAGE LOAD	

1.  Instantiate app	

2.  Deserialize data (models/collections)	

3.  Setup Backbone routes	

4.  Dispatch route (run controller logic)	

5.  Re-attach views	

PAGE NAVIGATION	

1.  Dispatch route (run controller logic)	

2.  Render views	

CLIENT WORKFLOW
HANDS ON
module.exports = function(options) {!
var options = options || {},!
App = options.app,!
route = options.route;!
!
return function(req, res, next) {!
var app = new App({!
language: req.params.language,!
authToken: req.cookies.sessionid!
});!
!
app!
.dispatch(route, req.params)!
.done(function(view) {!
var html = view.render().outerHTML(),!
bootstrap = JSON.stringify(app.serialize());!
res.send(html + '<script>' + bootstrap + '</script>');!
})!
.fail(next);!
};!
};!
SERVE APP MIDDLEWARE
WISH LIST CONTROLLER
route('/wishlist/:id', 'wishlist', function(id) {!
var app = this, api = app.wishlistApi;!
!
var allWishlists = api.getAllWishlists(),!
wishlist = api.getWishlist(id),!
allWishlistItems = api.getAllWishlistItems(id);!
!
var productList = new ProductListView({!
collection: allWishlistItems!
}),!
navigation = new NavigationView({!
model: wishlist,!
collection: allWishlists!
});!
mainView = new MainView({!
model: wishlist,!
views: {!
'append header': navigation,!
'inner [role=main]': productList!
}!
});!
!
return mainView.ready().then(function() {!
return mainView;!
});!
});!
MAIN TEMPLATE
<header>!
<h1>{{name}}</h1>!
!
{{#if isOwner}}!
<button>Manage</button>!
{{/if}}!
!
{{! Navigation }}!
</header>!
!
<div role="main">{{! Product List }}</div>!
CLIENT-SIDE BOOTSTRAPPING
<header>!
<h1>Wish List</h1> <button>Manage</button>!
<ul class="navigation">!
<li>...</li>!
</ul>!
</header>!
<div role="main">!
<ul class=“product-list">!
<li>...</li>!
</ul>!
</div>!
!
<script>!
var app = new App();!
!
app.deserialize({bootstrap});!
!
route('/wishlist/:id', 'wishlist', function(id) {!
app!
.dispatch(route, id)!
.done(function(view) {!
view.attach('.container');!
});!
});!
Backbone.history.start();!
</script>!
VOILA!
WHAT WE’VE LEARNED
•  Lots of code bridging differences between environments and libraries	

–  Introducing extra abstraction layer	

•  Routing is different	

–  Stateless server-side routing (new app instance for each request)	

–  Stateful client-side routing (holding on to app during page navigation)	

–  Express vs. Backbone routes (reversed order, paths, params)	

–  Redirects (302 vs. browser location)	

–  Serve mobile page based on user agent	

•  Fetching data is different (XMLHttpRequest vs. node request)	

COMPLEX PROBLEM
•  Caching is different	

–  Only ever fetch once per incoming request	

–  Tab could be left open for days	

–  Expire and re-fetch resources after x seconds client-side	

•  Error handling is different (HTTP error codes vs. popups)	

•  Sending email is borderline	

COMPLEX PROBLEM
•  Dependency management	

–  CommonJS runs client-side with browserify	

–  AMD runs server-side with require.js	

–  Both work but ideally language level support (ES6 Modules)	

•  Promises	

–  Q or jQuery Deferred	

–  Ideally one standard (ES6 Promises)	

ES5 IMMATURITY
•  Well known jQuery API for DOM manipulation and traversal	

•  Easy to pick up	

•  Can translate Backbone apps directly to the server	

•  No full blown JSDOM, but still slow	

CHEERIO
•  Airbnb Rendr	

–  One stop solution (Rendering, Serialization, Routing)	

–  Pure string concatenation using templates – Fast on the server	

–  Client-side rendering trashes and re-renders whole DOM (can cause
flicker and performance issues)	

•  Facebook React	

–  View rendering library (Bring your own MC)	

–  Virtual DOM approach: slow on the server but super fast client-side	

–  Fun fact: Inspired by DOOM III	

CHEERIO ALTERNATIVES
Rendering comment box with 1000 comments	

SERVER-SIDE PERFORMANCE
•  Very simple HTML – String concatenation will shine even more as markup
grows in complexity	

•  React has the edge over Cheerio – JSX uses precompiled objects so can be
heavily optimized byV8 (Cheerio parses strings into trees on runtime)	

RENDR	

REACT	

CHEERIO	

~ 110 ms	

~ 174 ms	

~ 204 ms
•  Load performance means time to content (not response time)	

–  Server-side DOM is slow but faster than serving empty pages	

•  Think of it as an enhancement to SPA	

–  Stateless service can be easily scaled up	

–  Respond with empty pages if load is too high and render client-side	

•  Client-side rendering performance equally important	

•  Decide per use case – In certain situations simple Express.js templating with
separate client-side JS might be better approach	

SO WHAT?
•  YES! 🌟😺✨	

•  Joy to develop once hard work is done	

•  Easy and fast to build rich UI and add new functionality	

•  But:	

•  Technique in its infants	

•  Better frameworks/solutions required	

WORTH IT?
THANKS!

Server and client rendering of single page apps

  • 1.
    WISH LIST server andclient rendering of single page apps Thomas Heymann @thomasheymann github.com/cyberthom
  • 2.
  • 3.
    WISH LIST •  Shoppingtool •  Track products •  Receive alerts •  Share lists
  • 4.
    GOALS & OBJECTIVES • Improve UI •  Pull out wish list into separate stack of services •  Update front-end code using modern frameworks and best practices –  Perfect candidate for SPA due to mutability •  Minify duplication which led to inconsistencies
  • 5.
    SHARED CONCERNS Server Client USER INTERACTIONS LOGGING MONITORING ROUTING PRESENTATION LOGIC APPLICATIONDATA views / layout / templates models / collections / business rules / API calls events / animations SITE FURNITURE ANALYTICS i18n translations / date and currency formatting STYLING
  • 6.
    •  Developers getDRY and MV* •  Users get best of both worlds: –  fully rendered pages (instant content) –  responsiveness of SPA •  Business gets SEO •  Everybody’s happy 🌈😃🎉 ENVIRONMENT AGNOSTIC
  • 7.
    •  EvenThoughtWorks agrees👌 TECH RADAR http://www.thoughtworks.com/radar/#/techniques Client and server rendering with same code Increasingly, HTML is rendered not only on the server but also on the client, in the web browser. In many cases this split rendering will remain a necessity but with the growing maturity of JavaScript templating libraries an interesting approach has become viable: client and server rendering with same code. HOLD ASSESS TRIAL ADOPT
  • 8.
  • 9.
    SYSTEMS OVERVIEW WISHLIST API SITEFURNITURE Aggregation Layer Presentation Layer API MAGAZINE API CATALOGUE Core Services & Storage
  • 10.
    TECH STACK SERVER CLIENT node.js IE8+ Express Backbone Router cheerio jQuery Backbone Handlebars require.js App
  • 11.
    •  Renders nestedviews •  Re-attaches views to DOM client-side APP COMPONENTS VIEW ASSEMBLER ROUTER MODEL FACTORY SERIALIZER SYNCER •  Ignores duplicate requests and caches responses •  Injects headers •  Matches URLs and extracts params •  Executes controller logic •  Serializes app data to JSON server-side •  Deserializes app data client-side •  Creates models •  Enforces singletons for data bindings
  • 12.
    PAGE REQUEST 1.  Instantiateapp 2.  Dispatch route (run controller logic) 3.  Render views 4.  Serialize data (models/collections) 5.  Decorate page with site furniture 6.  Send response SERVER WORKFLOW
  • 13.
    PAGE LOAD 1.  Instantiateapp 2.  Deserialize data (models/collections) 3.  Setup Backbone routes 4.  Dispatch route (run controller logic) 5.  Re-attach views PAGE NAVIGATION 1.  Dispatch route (run controller logic) 2.  Render views CLIENT WORKFLOW
  • 14.
  • 15.
    module.exports = function(options){! var options = options || {},! App = options.app,! route = options.route;! ! return function(req, res, next) {! var app = new App({! language: req.params.language,! authToken: req.cookies.sessionid! });! ! app! .dispatch(route, req.params)! .done(function(view) {! var html = view.render().outerHTML(),! bootstrap = JSON.stringify(app.serialize());! res.send(html + '<script>' + bootstrap + '</script>');! })! .fail(next);! };! };! SERVE APP MIDDLEWARE
  • 16.
    WISH LIST CONTROLLER route('/wishlist/:id','wishlist', function(id) {! var app = this, api = app.wishlistApi;! ! var allWishlists = api.getAllWishlists(),! wishlist = api.getWishlist(id),! allWishlistItems = api.getAllWishlistItems(id);! ! var productList = new ProductListView({! collection: allWishlistItems! }),! navigation = new NavigationView({! model: wishlist,! collection: allWishlists! });! mainView = new MainView({! model: wishlist,! views: {! 'append header': navigation,! 'inner [role=main]': productList! }! });! ! return mainView.ready().then(function() {! return mainView;! });! });!
  • 17.
    MAIN TEMPLATE <header>! <h1>{{name}}</h1>! ! {{#if isOwner}}! <button>Manage</button>! {{/if}}! ! {{!Navigation }}! </header>! ! <div role="main">{{! Product List }}</div>!
  • 18.
    CLIENT-SIDE BOOTSTRAPPING <header>! <h1>Wish List</h1><button>Manage</button>! <ul class="navigation">! <li>...</li>! </ul>! </header>! <div role="main">! <ul class=“product-list">! <li>...</li>! </ul>! </div>! ! <script>! var app = new App();! ! app.deserialize({bootstrap});! ! route('/wishlist/:id', 'wishlist', function(id) {! app! .dispatch(route, id)! .done(function(view) {! view.attach('.container');! });! });! Backbone.history.start();! </script>!
  • 19.
  • 20.
  • 21.
    •  Lots ofcode bridging differences between environments and libraries –  Introducing extra abstraction layer •  Routing is different –  Stateless server-side routing (new app instance for each request) –  Stateful client-side routing (holding on to app during page navigation) –  Express vs. Backbone routes (reversed order, paths, params) –  Redirects (302 vs. browser location) –  Serve mobile page based on user agent •  Fetching data is different (XMLHttpRequest vs. node request) COMPLEX PROBLEM
  • 22.
    •  Caching isdifferent –  Only ever fetch once per incoming request –  Tab could be left open for days –  Expire and re-fetch resources after x seconds client-side •  Error handling is different (HTTP error codes vs. popups) •  Sending email is borderline COMPLEX PROBLEM
  • 23.
    •  Dependency management – CommonJS runs client-side with browserify –  AMD runs server-side with require.js –  Both work but ideally language level support (ES6 Modules) •  Promises –  Q or jQuery Deferred –  Ideally one standard (ES6 Promises) ES5 IMMATURITY
  • 24.
    •  Well knownjQuery API for DOM manipulation and traversal •  Easy to pick up •  Can translate Backbone apps directly to the server •  No full blown JSDOM, but still slow CHEERIO
  • 25.
    •  Airbnb Rendr – One stop solution (Rendering, Serialization, Routing) –  Pure string concatenation using templates – Fast on the server –  Client-side rendering trashes and re-renders whole DOM (can cause flicker and performance issues) •  Facebook React –  View rendering library (Bring your own MC) –  Virtual DOM approach: slow on the server but super fast client-side –  Fun fact: Inspired by DOOM III CHEERIO ALTERNATIVES
  • 26.
    Rendering comment boxwith 1000 comments SERVER-SIDE PERFORMANCE •  Very simple HTML – String concatenation will shine even more as markup grows in complexity •  React has the edge over Cheerio – JSX uses precompiled objects so can be heavily optimized byV8 (Cheerio parses strings into trees on runtime) RENDR REACT CHEERIO ~ 110 ms ~ 174 ms ~ 204 ms
  • 27.
    •  Load performancemeans time to content (not response time) –  Server-side DOM is slow but faster than serving empty pages •  Think of it as an enhancement to SPA –  Stateless service can be easily scaled up –  Respond with empty pages if load is too high and render client-side •  Client-side rendering performance equally important •  Decide per use case – In certain situations simple Express.js templating with separate client-side JS might be better approach SO WHAT?
  • 28.
    •  YES! 🌟😺✨ • Joy to develop once hard work is done •  Easy and fast to build rich UI and add new functionality •  But: •  Technique in its infants •  Better frameworks/solutions required WORTH IT?
  • 29.