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.

Transcript

1. Isomorphic and Reactive Applications
   Peter Marton
   @slashdotpeter
   

   View Slide

2. Isomorphic and Reactive Applications
   Peter Marton
   @slashdotpeter
   

   View Slide

3. $ whoami
   - work: RisingStack, Inc.
   - twitter: slashdotpeter
   - email: peter@risingstack.com
   - blog: http://blog.risingstack.com
   

   View Slide

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.
   

   View Slide

5. BUT
   (there is always a but)
   

   View Slide

6. SPA Problems
   - SEO
   - code duplications: validation, routing...
   - performance
   - first load is heavy -> bandwidth
   - rendering -> drains mobile battery
   - legacy browser support
   

   View Slide

7. Ideal world
   

   View Slide

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

   View Slide

9. Different environments
   - browser’s window: localStorage.getItem()
   - node specific: fs.readFile()
   - IoT device (~Tessel): myPin.read()
   - environment shims
   

   View Slide

10. What can be shared?
    - from templates and small components
    - to the ~entire application
    - today I talk about entire apps
    

    View Slide

11. Isomorphic codebase, lifecycle
    

    View Slide

12. What do we need?
    

    View Slide

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...
    

    View Slide

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
    

    View Slide

15. How does it work?
    

    View Slide

16. Isomorphic server side
    

    View Slide

17. Isomorphic client side
    

    View Slide

18. data-reactid
    

    View Slide

19. Showcase
    brew-ui
    

    View Slide

20. Isomorphic challenges
    - data fetching: talk about this later
    - init app on both sides
    - singleton app on client -> request scoped on server
    

    View Slide

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
    

    View Slide

22. Isomorphic architecture
    - should work on both sides
    - should be data oriented
    - flux can be good
    

    View Slide

23. Flux
    - unidirectional data-flow
    - reducing complexity / cross dependencies
    - helps avoiding side effects
    

    View Slide

24. Isomorphic Flux
    - share Store(s): serialize / deserialize
    - per request isolated Dispatcher and Store(s)
    - server rendering should wait initial data load
    

    View Slide

25. Reactive programming and Isomorphic
    - think in data and event streams
    - optimize rendering calls with immutability
    Omniscient, nuclear-js
    

    View Slide

26. Isomorphic packages
    - power of npm
    - envs. (browser) should be shimmed
    - check your published packages
    BE ISOMORPHIC!
    

    View Slide

27. I’m isomorphic: badge
    http://bit.ly/isomorphic-ready
    

    View Slide

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

    View Slide