Building Highly Scalable, Robust & Fast Single Page Web Apps

Presented @ Netcentric Summit 2017
Lisbon, Portugal

Single page applications have become increasingly more complex over the past few years. The way we approach and design web applications have changed a lot. User interfaces have become even more interactive and often contain very complex asynchronous data flows. The performance has also become very critical because the end users are expecting a native-like experience.

We will look at some framework agnostic concepts that will help you build truly reusable UI components and manage the application state in a predictable way. As the application grows and changes over time, we will leverage some best practices and tools to ensure a robust design that scales well in terms of requirements and performance.

Transcript

1. summit 2017 Erik Grijzen Lisbon, Portugal 04/02/2017 Building Highly Scalable, Robust & Fast Single Page Web Apps
2. Struggles building large-scale Single Page Web Apps.
3. Traditional MVC architecture. Controller Model View
4. View View Model Model MVC doesn’t scale. Controller Model View
5. View View Model Model Infinite loops. Controller Model View
6. View View Model Model Duplicated state. Controller Model View
7. View View Model Model Hard to track errors. Controller Model View
8. View View Model Model Expensive change detection. Controller Model View
9. Data changes over time.
10. Work in isolation.
11. Super Hero developer. S
12. Framework size. Framework Performance Target
13. The more features, the bigger the size. Framework Feature Feature Feature Performance Target
14. Share components between projects. Project 1 Project 2
15. Ideas & concepts to solve these problems.
16. Erik Grijzen Senior Frontend Software Engineer
17. Components are the fundamental building blocks of the user interface.
18. Component tree structure.
19. Root component. App
20. View components for routing. App View 1 View 2
21. Components to compose your user interface. App View 1 View 2 Component Component Component Component Component Component Component Component
22. Container & Presentational components.
23. Container Smart Stateful Unpure Fat Presentational Dumb Stateless Pure Skinny
24. Presentational components.
25. Presentational components are concerned how things look.
26. Everything is a component. Label text: Placeholder text Title LABEL INPUT BUTTON
27. Composing components together. Phone number: Enter your phone number... Send
28. Component folder structure. / button button.html button.scss button.js button.test.js index.js
29. (props) => markup;
30. Presentational component example. // Header.js function(text) { return `<h1 class="header__base"> ${text} </h1>`; }
31. Presentational components. ﹡ Nearly all markup. ﹡ No app dependencies. ﹡ Receives data from parent. ﹡ Not aware of app state. ﹡ Rarely contain state.
32. Container components.
33. Concerned how things work.
34. Views are typically the first layer of container components. App View 1 View 2 Component Component Component Component Component Component Component Component
35. Example container component.
36. Little to no markup of its own.
37. Contains other components.
38. Passes data down.
39. Aware of application state.
40. Provides callbacks.
41. Reusing components with different data. App View 1 View 2 Component Component Component Component Component Component Component Component
42. Share components between projects. <message-box text={...} /> Container 1 Project 1 <message-box text={...} /> Container 2 Project 2
43. Separate the presentational components from your app. / Project A / app / common / containers / users / products / ... / Component Library / components / accordion / button / input / label / message-box / radio-buttons / select-box / table / text-area / ...
44. Moving to a Living Style Guide.
45. Showcasing / Testing with mock data. <message-box text={...} /> Container 1 Project 1 <message-box text={...} /> Container 2 Living Style Guide <message-box text={...} /> Container 3 UI Testing
46. Why split components up in two categories? ﹡ Reusability. ﹡ Testability. ﹡ Easier to reason about. ﹡ Easier to distribute. ﹡ Separation of concerns. ﹡ Work in isolation.
47. Styling components.
48. What part of the box model is the component? ? Margin Border Padding
49. Only style within the component boundaries. Component Margin Border Padding
50. Extended boundaries if it’s part of the design. Component Margin Border Padding
51. Don’t use vertical or horizontal spacing inside components. Project 1 Project 2
52. Avoiding global CSS pollution.
53. CSS Modules.
54. CSS files in which all class names and animation names are scoped locally. // Header.css .title { background-color: red; } // Header.js import styles from "./styles.css"; element.innerHTML = `<h1 class="${styles.title}"> An example heading </h1>`;
55. The classes are dynamically generated, unique, and mapped to the component. // bundled css .Header__title_n6slD { background-color: red; } // rendered html <h1 class="Header__title_n6slD"> An example heading </h1>
56. The magic happens at build time.
57. Production build. // bundled css .n6slD { background-color: red; } // rendered html <h1 class="n6slD"> An example heading </h1>
58. Why use CSS Modules? ﹡ True encapsulation. ﹡ The power of JavaScript. ﹡ No specificity conflicts. ﹡ No naming conflicts. ﹡ No BEM/SUIT conventions. ﹡ Forces best practices. ﹡ Explicit dependencies. ﹡ Dead code elimination. ﹡ File size.
59. Component communication.
60. Direct communication is a poor practice.
61. The Flux design pattern.
62. Unidirectional data flow. Action Dispatcher Store View
63. Components dispatch actions to the store. Store
64. Components subscribe to changes. Store
65. Why use unidirectional data flow? ﹡ Separation of concerns. ﹡ Easier to reason about. ﹡ More predictable. ﹡ Easy to keep UI in sync. ﹡ Debugging.
66. Facebook Flux Fluxible Reflux Alt Flummox Marty.js McFly Lux Fluxette Fluxxor Fluxury Freezer
67. A predictable state container.
68. Single Source of Truth.
69. The state of your whole application is stored a single store. { todos: [ { id: 3, completed: false, text: 'Three' }, { id: 2, completed: false, text: 'Two' }, { id: 1, completed: false, text: 'One' } ] }
70. State is Read-Only.
71. The only way to change the state is to emit an action. { type: 'ADD_TODO', text: 'Build my first Redux app' }
72. Typically we use action creators for better reusability. export const ADD_TODO = 'ADD_TODO' export function addTodo(text) { return { type: ADD_TODO, text, } }
73. Changes are made with Pure Functions.
74. (previousState, action) => newState
75. To specify how the state tree is transformed by actions, you write pure reducers. import { ADD_TODO } from './actions' function todosReducer(state = [], action) { switch (action.type) { case ADD_TODO: return [...state, { text: action.text, completed: false }] default: return state } }
76. Each reducer manages its own part of the global state. import { combineReducers } from 'redux'; const todoApp = combineReducers({ todosReducer, visibilityReducer, });
77. Easy to test isolated state changes.
78. What about asynchronous logic?
79. Redux middleware.
80. Middleware example. const logger = store => next => action => { console.log('dispatching', action); let result = next(action); console.log('next state', store.getState()); return result }
81. Adding middleware to the store. import { createStore, combineReducers, applyMiddleware, } from 'redux'; const todoApp = combineReducers(reducers); const store = createStore( todoApp, applyMiddleware(logger) );
82. Asynchronous actions.
83. Asynchronous action middleware. ﹡ redux-thunk ﹡ redux-promise ﹡ redux-observable ﹡ redux-saga
84. redux-promise example. export const LOAD_DATA = 'LOAD_DATA' export function load() { return { type: LOAD_DATA, payload: fetch('api/v1/data'), } }
85. Redux DevTools demo.
86. How is the user interface updated on state changes?
87. Change detection.
88. What happens if data changes? DOM MODELS
89. Model gets mutated. DOM MODELS
90. Projecting the data on the user interface. DOM MODELS change
91. Components abstract the DOM rendering. Component
92. Data is passed from top to bottom. View 1 Component Component Component Component Component Component Component Component Component Component Component Tree
93. Change! Component Tree When a change occurs...
94. Every component re-renders itself. Component Tree
95. Every component re-renders itself. Component Tree
96. Every component re-renders itself. Component Tree
97. Every component re-renders itself. Component Tree
98. Mutable data structures.
99. Example container component. class PersonDetailsContainer { constructor() { this.personData = { firstName: 'John', lastName: 'Doe', } } changeFirstName() { this.personData.firstName = 'Jane'; } }
100. Passing the data down. PersonalDetailsContainer PersonalDetailsComponent <personal-details person="personData" onClick="changeFirstName()"> </personal-details> { firstName: 'John', lastName: 'Doe', }
101. Mutating the data object. PersonalDetailsContainer PersonalDetailsComponent <personal-details person="personData" onClick="changeFirstName()"> </personal-details> { firstName: 'Jane', lastName: 'Doe', } Click! oldPersonData === newPersonData // true
102. Frameworks have to conservatively render the whole tree. Component Tree
103. DOM mutation are expensive.
104. Smarter change detection.
105. Immutable data structures.
106. Making a change always creates a new reference. import Immutable from 'immutable'; class PersonDetailsContainer { constructor() { this.personData = Immutable.Map( firstName: 'John', lastName: 'Doe', }); } changeFirstName() { this.personData.set('firstName','Jane'); } }
107. Passing the data down. PersonalDetailsContainer PersonalDetailsComponent <personal-details person="personData" onClick="changeFirstName()"> </personal-details> { firstName: 'John', lastName: 'Doe', }
108. Passing the data down. PersonalDetailsContainer PersonalDetailsComponent <personal-details person="personData" onClick="changeFirstName()"> </personal-details> oldPersonData === newPersonData // false { firstName: 'Jane', lastName: 'Doe', } Click!
109. Change! Component Tree When a change occurs...
110. When the reference is the same it won’t rerender. Component Tree
111. How can we deliver fast mobile experiences?
112. Key user moments.
113. Source: http://bit.ly/2kIzs58
114. Source: http://bit.ly/2kIzs58
115. Optimizing Perceived Performance.
116. Offline first approach.
117. Source: http://bit.ly/2jLxkcP
118. App Shell architecture.
119. Source: http://bit.ly/2jLxkcP
120. Universal JavaScript.
121. Source: http://bit.ly/2jMByAZ
122. Server-rendered application shell. Source: http://bit.ly/2jMByAZ
123. Source: http://bit.ly/2kIzs58
124. Optimizing Time To Interactive.
125. Avoid serving large, monolithic bundles.
126. Load your app like a video game.
127. Separate the bootstrap logic. App View 1 View 2 Component Component Component Component Component Component Component Component Component Component Component Component
128. Route-based chunking.
129. Views are easy split points. App View 1 View 2 Component Component Component Component Component Component Component Component Component Component Component Component
130. Loading routes on demand. [ { path: 'home', getComponent(location, cb) { System.import('./containers/Home') .then(loadRoute(cb)); }, }, { path: 'products', getComponent(location, cb) { System.import('./containers/Products) .then(loadRoute(cb)); }, }, { path: 'shopping-cart', getComponent(location, cb) { System.import('./containers/ShoppingCart') .then(loadRoute(cb)); }, }, ]
131. Separate code that is unlikely to change. App View 1 View 2 Component Component Component Component Component Component Component Component Vendor Polyfills Component Component Component Component
132. Bundle common logic together. App View 1 View 2 Component Component Component Component Component Component Component Component Vendor Polyfills Component Component Component Component
133. Deliver the minimal functionality for a view.
134. As more resources arrive, the app progressively unlocks more features.
135. Optimizing bootstrapping.
136. Source: http://bit.ly/1PE8g4r
137. Source: http://bit.ly/1PE8g4r
138. Frameworks are slow by default. Framework Size (min) Size (min + gzip) Ember 2.2.0 435kb 111kb Ember 1.13.8 486kb 123kb Angular 2 566kb 111kb Angular 2 + RxJS 766kb 143kb Angular 1.4.5 143kb 51kb React 0.14.5 + React DOM 143kb 40kb React 0.14.5 + React DOM + Redux 133kb 42kb React 15.3.0 + React DOM 139kb 23kb
139. Source: http://bit.ly/1PE8g4r
140. Source: http://bit.ly/1PE8g4r
141. Are frameworks viable for mobile use?
142. User Interface libraries.
143. We can render the whole app inexpensively.
144. Virtual DOM Source: http://bit.ly/2jsDBy5
145. The ability to re-render at will allows for a fundamentally lighter approach.
146. Benefits of this lighter approach? ﹡ No observable models. ﹡ No data binding. ﹡ No templating system ﹡ Less framework features. ﹡ Less code. ﹡ Less memory usage. ﹡ Less computations.
147. Rise of minimalistic UI libraries. ( 3kb ) ( 9kb ) ( 17kb ) ( 8kb )
149. Thank you! www.erikgrijzen.com @ErikGrijzen