2013 04-02-server-side-backbone


Published on

HTML5 DevConf 2013 talk by Lauri Svan / SC5

Writing single page applications that respect all web browsers and crawlers should be easy. Still, many end up rewriting their single page application with a server-side templating language, too and get trapped to maintaining two codebases.

With the emergence of server-side JavaScript, the “holy grail” of running the same app code on both ends seems attainable. Frameworks like Meteor, Derby and Yahoo Mojito have done it, and the efforts of AirBnB and Backbone LayoutManager bring it closer to Backbone developers, too. Still, the current approaches make such assumptions on the backend or enforce such constraints on the programming model that an old-fashioned Backbone.js developer cannot take them in use.

This talk compares the approaches for the “holy grail”, particularly from a Backbone application developer’s perspective. In addition, it presents a programming model by which pretty ordinary Backbone applications can run on both ends. The presented approach works for web crawlers and could have limited use for dumb browsers, too.

The talk is technical, with the primary audience being single page app developers planning to move their app server-side. The audience will benefit from previous knowledge of Backbone.js.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

2013 04-02-server-side-backbone

  1. 1. SuRvIvInG RoBoTs aNd OlD BrOwSeRs bY SeRvEr-sIdE BaCkBoNe" LaUrI SvAn @lAuRiSvAn Sc5 OnLiNe @sC5 HtMl5 eXpErTiSe aT yOuR sErViCe  
  2. 2. HeLp! My SiNgLe PaGe ApP FaIlS fOr RoBoTs!
  3. 3. WhY dEsIgN yOuR ApP fOr1% oR 0.1% oF YoUr tRaFfIc?
  4. 4. UsE a PrOxY fOr LeGaCy BrOwSeRs Browser   Browser  interfaces   Server  API   Full   app   Plain  HTML   App  Proxy  
  5. 5. WhAt Do I GaIn?•  Solve the Robot problem – remove double code paths•  Speed up time to first render – bootstrap your DOM•  Potentially solve the “legacy browser” problem•  Ease your test automation – mocking your API/App
  6. 6. WhAt DoEs iT TaKe tO AcHiEvE?•  JavaScript support (node.js)•  Shared module loader (Require.js / Browserify)•  Some way to emulate/abstract out DOM•  Some shims for Browser APIs (XHR, localStorage etc…)•  Some way to tell your app has completed rendering
  7. 7. QuEsTs FoR tHe HoLy GrAiL ReViSiTeD
  8. 8. GrAiLs: WhAt yOuR ApP MiGhT LoOk LiKe •  Some partial layering modelApplication Logic & Templates •  App touches the browser APIs Backbone through all the layers jQuery Browser API •  Everything needs server-side JavaScript Runtime shims! Runs on both as-is Compatibility Layer Platform Specific
  9. 9. GrAiLs: PrOxY BrOwSeR (PhAnToM.Js) Browser •  Full WebKit implementation on server-side •  Runs on its own process/server Reverse Proxysmartclients dumb clients •  Context sharing with Phantom.jsApp Server Proxy Browser process is tricky •  Chromium Embedded Framework & Node.js would even better?
  10. 10. GrAiLs: TeMpLaTe ShArInG (tHe nOrMaL wAy) Templates •  Share the templates on client Data Representation and serverApplication Logic Server Logic •  Separate codebases forBackbone compositing the page fragments jQuery Browser API •  Simple to understand JavaScript Runtime Any Runtime •  Double code paths: Double testing, maintenance etc. Runs on both as-is Compatibility Layer Platform Specific
  11. 11. GrAiLs: ShArEd ClIeNt-sErVeR Fw (DeRbY, MeTeOr) •  Full app frameworks that hideApplication Logic & Templates the DOM Custom Framework •  Hide client/server messaging (socket.io etc.) •  Meteor still uses PhantomJS to JavaScript Runtime render for robots? •  Lock-in to a certain development model Runs on both as-is •  Lock-in to a certain backend Compatibility Layer Platform Specific
  12. 12. GrAiLs: SeRvEr-sIdE DoM (JsDoM) •  JSDOM - Full JavaScript DOMApplication Logic & Templates implementation Backbone •  How about the other APIs? jQuery •  Browser/HTML5 APIs is huge! Browser API Subset •  Slow to emulate JavaScript Runtime Runs on both as-is Compatibility Layer Platform Specific
  13. 13. GrAiLs: SeRvEr-sIdE jQuErY (ChEeRiO) •  Use jQuery for compatibilityApplication Logic & Templates Backbone •  Hide the DOM below jQuery / Cheerio •  Limited adaptation problem JavaScript Runtime •  Potentially faster •  Changes to Backbone needed Runs on both as-is Compatibility Layer Platform Specific
  14. 14. GrAiLs: AbStRaCt oUt DoM (AiRbNb / ReNdR) •  Backbone, but abstract out all Application Logic & Templates DOM manipulation from view Backbone manipulation Adaptation Layer •  AirBNB - Concatenate templates on server JavaScript Runtime •  No jQuery, no DOM access •  Is it the same anymore? Runs on both as-is Compatibility Layer Platform Specific
  15. 15. GrAiLs: CoMpArIsOn Template  Sharing   Templates Your  Typical  App   Shared  Client-­‐Server  FW   Data Representation Application Logic & Templates Application Logic & Templates Application Logic Server Logic Backbone Custom Framework Backbone jQuery jQuery Browser API Browser API JavaScript Runtime JavaScript Runtime JavaScript Any Runtime RuntimeDOM  Abstracted  out   JSDOM   Cheerio   Application Logic & Templates Application Logic & Templates Application Logic & Templates Backbone Backbone Backbone Adaptation Layer jQuery jQuery / Cheerio Browser API Subset Runs on both as-is Compatibility JavaScript Runtime JavaScript Runtime JavaScript Runtime Layer Platform Specific
  16. 16. AlMoSt aLl oF oUr aPpS aRe BaCkBoNe & JqUeRy YoU cAn’t tEaCh oLd dOg nEw tRiCkS
  17. 17. BaCkBoNe-SeRvErSiDe – oUr DeSiGn PrInCiPlEs•  We do not need to be a full browser•  We cannot expect the world to change our way•  API compatibility is our friend•  Make it a polyfill, not a library or framework•  Do not assume anything else than Backbone•  Retain API compatibility, hide the dirty tricks if possible•  Retain the possibility to use 3rd party JavaScript libs•  Keep app specific changes to minimum
  18. 18. InTrOdUcInG BaCkBoNe-SeRvErSiDe •  Run the same Backbone SPA on both Application client and server with minimal extra conventionsBackbone •  Removes Backbone DOM depencies jQuery / Cheerio •  Cheerio jQuery subset for DOMBrowser / Adaptation Layer manipulation •  Polyfills for Cheerio (events, ajax) JavaScript Runtime Things you may need to change in your app: •  Stick to a subset of jQuery (Cheerio) •  Use a dependency manager that you can run on both ends (AMD/RequireJS, CommonJS/Browserify) •  Implement a messaging mechanism between your node.js server and your app
  19. 19. SeRvEr-sIdE BaCkBoNe RePlAcEmEnTs •  The classes you typically use will run as-is Collection RouterModel •  The classes that touch the DOM View underneath need changes sync We stub out/replace a few things History jQuery Ajax •  jQuery: Cheerio and its fake DOM •  Ajax: Replace jQuery.ajax with a 3rd party node.js module Runs on both as-is Compatibility •  History: Trim away DOM specifics Layer Platform Specific (window.navigator.location etc.)
  20. 20. WhEn ArE We ReAdY tO SeNd tHe PaGe BaCk?Browser / Server One way on how to handle parse path / pushState Inject to DOM the problemBackbone App •  Use Backbone events for Router messaging handle route verify all states pass the results •  Single point of control Model View (App Singleton/Router) fetch models notify render notify •  All relevant objects have an Legend: observable stateServer API direct call serve JSON event
  21. 21. FeAtUrE dEtEcTiOn – A MuSt HaVe?•  Require.js is hard to get right on the both ends •  Conditional switches between jQuery and Cheerio needed •  Some client-slide libraries just won’t load•  Typical applications use DOM and Browser APIs directly•  Typical 3rd party libraries use DOM & Browser APIs extensivelyà You will benefit from a feature detection library
  22. 22. DeMo TiMe
  23. 23. BaCkBoNe-SeRvErSiDe – WoRk iN PrOgReSs•  It is still experimental, but already demonstrable•  Contributions wanted at our GitHub at SC5/backbone-serverside•  An article in Mozilla Hacks just got out•  Some of the near-term work involves •  Handling feature detection (analytics, DOM events) •  Cross-request user state management (localStorage adapters?) •  Concurrency handling (currently we have single, shared DOM) •  Samples on robot & browser detection (express-device)
  24. 24. QuEsTiOnS?
  25. 25. LeT’s SoLvE tHe CrAwLaBiLiTy PrObLeM! LaUrI SvAn Software Architect, SC5 Online Ltd https://github.com/laurisvan @laurisvan HtMl5 eXpErTiSe aT yOuR sErViCe