Upgrade to Pro — share decks privately, control downloads, hide ads and more …

NodeSummit - Isomorphic and Reactive Applications

1e2275ae49fccaa79d88fa6539492640?s=47 Peter Marton
February 10, 2015

NodeSummit - Isomorphic and Reactive Applications

There is no such thing as separated client and server app in the isomorphic era, there are only environments (browser, server, IoT device etc.). One app is running on both client and server side: this the end of the SEO pain and code duplications.

1e2275ae49fccaa79d88fa6539492640?s=128

Peter Marton

February 10, 2015
Tweet

Transcript

  1. Isomorphic and Reactive Applications Peter Marton @slashdotpeter

  2. Isomorphic and Reactive Applications Peter Marton @slashdotpeter

  3. $ whoami - work: RisingStack, Inc. - twitter: slashdotpeter -

    email: peter@risingstack.com - blog: http://blog.risingstack.com
  4. SPA: Single Page Load Applications - single page load -

    pure data after first load -> fast UI - renders on client side - example: Backbone, AngularJS, Ember, etc.
  5. BUT (there is always a but)

  6. SPA Problems - SEO - code duplications: validation, routing... -

    performance - first load is heavy -> bandwidth - rendering -> drains mobile battery - legacy browser support
  7. Ideal world

  8. Isomorphic JavaScript “JavaScript code that can be shared between environments.”

    - Spike Brehm
  9. Different environments - browser’s window: localStorage.getItem() - node specific: fs.readFile()

    - IoT device (~Tessel): myPin.read() - environment shims
  10. What can be shared? - from templates and small components

    - to the ~entire application - today I talk about entire apps
  11. Isomorphic codebase, lifecycle

  12. What do we need?

  13. What do we need? 1/2 - language that runs on

    both sides: JS ;) - bundle with Browserify/Webpack - modules that runs on both sides -> npm: superagent etc. - view engine that renders on both sides: - React, - VirtualDOM...
  14. What do we need? 2/2 - share states: Serializable states

    (stores) - https://github.com/yahoo/serialize-javascript - continue at the client from where server left
  15. How does it work?

  16. Isomorphic server side

  17. Isomorphic client side

  18. data-reactid

  19. Showcase brew-ui

  20. Isomorphic challenges - data fetching: talk about this later -

    init app on both sides - singleton app on client -> request scoped on server
  21. Data fetching problem - environment specific problems - should be

    shimmed - same functionality and interface - different implementation: AJAX / WS / DB call / micro-service / .. - “Full Stack Flux” - Pete Hunt: React.js Conf 2015 - Full Stack Flux
  22. Isomorphic architecture - should work on both sides - should

    be data oriented - flux can be good
  23. Flux - unidirectional data-flow - reducing complexity / cross dependencies

    - helps avoiding side effects
  24. Isomorphic Flux - share Store(s): serialize / deserialize - per

    request isolated Dispatcher and Store(s) - server rendering should wait initial data load
  25. Reactive programming and Isomorphic - think in data and event

    streams - optimize rendering calls with immutability Omniscient, nuclear-js
  26. Isomorphic packages - power of npm - envs. (browser) should

    be shimmed - check your published packages BE ISOMORPHIC!
  27. I’m isomorphic: badge http://bit.ly/isomorphic-ready

  28. Q&A Thank you! http://blog.risingstack.com/from-angularjs-to-react-the-isomorphic-way/