Beyond the Single-Page App: React and the Servers that Serve it

A typical React app counts on multiple backend processes to serve it, render it, and keep things in sync. But between SPAs, CDNs, SSR, and OSI, it's not always easy to decide how the pieces fit together. While surveying the many interactions between React and its servers, we'll build up a practical model for deciding when, where, and how to use them.

Transcript

1. React and its servers RJ Zaworski: Director of Growth, koan.co · github.com/rjz · @rjzaworski
2. Web apps, a brief history It started with the server ★ Static documents + hyperlinks ★ State maintained by server ★ Commands? HTML <form> and HTTP POST 1993 1995 1999 2005 2013
3. Web apps, a brief history Clients get smarter ★ Dynamic Document Object Model ★ JavaScript: mutate the DOM at runtime ★ Cookies: shared client/server state 1993 1995 1999 2005 2013
4. Web apps, a brief history Asynchronous JavaScript and XML (AJAX) ★ XMLHttpRequest: fetch data or page fragments ★ State maintained by client and server 1993 1995 1999 2005 2013
5. Web apps, a brief history Client-side applications ★ JavaScript frameworks ($) ★ Abstract browser APIs ★ Client-only UI state ◦ memory ◦ document ◦ localStorage 1993 1995 1999 2005 2013
6. Web apps, a brief history React ★ Rethink the DOM ★ Focus on the UI ◦ BYO state container... ◦ ...app structure ◦ ...external libs/APIs 1993 1995 1999 2005 2013
7. Expectations Everyone wants something from our web app ★ Users: functional, responsive ★ Dev teams: easy to build, maintain ★ Software agents: neighborly
8. Development goals 1. Meet { User, Dev, Software } Expectations 2. Spend as much time as possible shipping products!
9. Let’s launch a web app ★ Fetch HTML ★ Fetch page assets ★ Render HTML ★ Parse and run JS ◦ Update DOM ◦ Handle Input ◦ Repeat
10. React
11. Why React? How about a DOM that’s... ★ Declarative ★ Immutable (stateless) ★ Componentized (encapsulated) ★ Consistent
12. Why React? Simplify client-side application development ★ Fewer server round-trips ★ Limited, scheduled DOM updates This feels fast!™
13. Great news for the UI, but... ★ Bring your own State Container ★ ...and Business logic Output Renderer Component Tree Application Logic State + Context React React React React
14. Servers
15. Why Servers? Because they’re useful. ★ Store app assets ★ Validate, persist, recall app state ★ Consolidate logic ★ Mediate between Software Agents
16. But there’s a catch. ★ New technology to learn ★ More moving parts ★ State in multiple places More { tech, complexity, synchronization } = less time building great user interfaces!
17. Servers “A Necessary Evil”
18. Single-Page Applications (SPAs) 1993 1995 1999 2005 2013
19. Remember that web app? ★ Fetch HTML ★ Fetch page assets ★ Render HTML ★ Parse and run JS ◦ Update DOM ◦ Handle Input ◦ Repeat SPA
20. React SPAs ★ Responsive (client-rendered UI) ★ React’s “natural” environment ★ Not without complications ◦ Imperative browser APIs ◦ Mutable DOM ◦ State
21. React SPAs - Prevailing Wisdom Users :^| Responsive once app bundle is loaded Dev teams :^) One tech stack only! Software agents :'( Must render JS application
22. Server opportunity: performance ★ Fetch HTML ★ Fetch page assets ★ Render HTML ★ Parse and run JS ◦ Update DOM ◦ Handle Input ◦ Repeat // Minify / compress data // Minify / compress / cache // Ditto app assets SPA // Split bundle
23. SPA servers: build or buy? ★ Static hosts ◦ Netlify ◦ Surge ★ Backends-as-a-Service ◦ AWS Amplify ◦ Firebase
24. Server-Side Rendering (SSR) 1993 1995 1999 2005 2013
25. Remember that web app? ★ Fetch HTML ★ Fetch page assets ★ Render HTML ★ Parse and run JS ◦ Update DOM ◦ Handle Input ◦ Repeat // SSR via react-dom/server SSR
26. Server-side rendering Two goals: 1. Optimize critical rendering path a. Show the user something, stat b. Avoid script-blocking 2. Improve access for software agents
27. Server-side rendering Two modes: 1. Static 2. On-demand
28. Static Generation ★ React ⇒ HTML at compile time ★ Compare with HTML templating ◦ Documents composed of components ◦ Your renderer may vary ★ Build or buy? ◦ Static site generator: GatsbyJS
29. On-demand SSR ★ Pages generated per-request ★ Build or buy? ◦ Frameworks: Next.js, Razzle
30. React SSR - Prevailing Wisdom Users :^| Fast load, slow updates Dev teams :^| One (iffy) tech stack only Software agents :^) HTML is easy to parse!
31. Server opportunity: compatibility ★ Fetch HTML ★ Fetch page assets ★ Render HTML ★ Parse and run JS ◦ Update DOM ◦ Handle Input ◦ Repeat SSR * Web crawlers * Screen readers * Browsers * ???
32. SSR: questions to ask ★ Does abstraction make sense? ★ Where does state live? <!doctype html> <html> <head> <!-- How do we set <meta /> tags? How do we set the page <title />? …? --> </head> <body> <div id="js-react-app"> <!-- Render React app here! → </div> </body> </html>
33. SSR libs: build or buy? ★ Static generation ◦ GatsbyJS ★ On-demand ◦ Next.js ◦ Razzle
34. Client-Server Hybrids 1993 1995 1999 2005 2013 ????
35. That web app, hybrid edition ★ Fetch HTML ★ Fetch page assets ★ Render HTML ★ Parse and run JS ◦ Update DOM ◦ Handle Input ◦ Repeat // SSR via react-dom/server // SPA via react-dom SPA SSR
36. Reuse Application Logic Output Renderer Component Tree Application Logic State + Context React React React React
37. Client-server hybrids Different flavors of “hybrid” ★ Progressively rendering ★ Isomorphic applications ★ ...and everything in between
38. The Good Something for everyone! ★ All the benefits of Server-side Rendering ★ All the benefits of an SPA ★ And we can reuse components!
39. The Bad Development overhead ★ Devs working in two platforms ★ Added build/deploy/runtime complexity ★ Library support—YMMV
40. The Ugly ★ Different runtime APIs (e.g. window.history) ★ ...where does state live?
41. Hybrid React - Prevailing Wisdom Users :^) Fast load, fast updates Dev teams :'( More tech to wrangle Software agents :^| HTML is easy to parse (if it’s up to date)!
42. Hybrid React - Server Opportunities ★ Fetch HTML ★ Fetch page assets ★ Render HTML ★ Parse and run JS ◦ Update DOM ◦ Handle Input ◦ Repeat SPA SSR “...Yes!”
43. The Bottom Line ★ Meet { User, Dev, Software } Expectations ◦ Old problems, new tools ◦ React is one piece of the puzzle ◦ Servers still matter! ★ Save time for new development ◦ Lazy wins? ◦ Keep it simple! 1993 1995 1999 2005 2013
44. Thank you! RJ Zaworski: Director of Growth, koan.co · github.com/rjz · @rjzaworski