Architekturoptionen für moderne Web-Frontends

Architekturoptionen für moderne Web-Frontends

Eine moderne Web-Anwendung wird selbstverständlich in JavaScript implementiert, erzeugt ihr HTML clientseitig im Browser selbst und kommuniziert mit dem Server nur, um über ein HTTP/REST-API Daten im JSON-Format abzuholen – das, so scheint es, ist die gängige Weisheit. Aber haben die bewährten Ansätze wie serverseitiges HTML und „Progressive Enhancement“ tatsächlich ausgedient?

In diesem Talk möchten wir darüber diskutieren, welche unterschiedlichen Stile von Web-Anwendungen es gibt, welche Vor- und Nachteile diese haben und wieso teilweise als altmodisch angesehene Ansätze für viele Anwendungen eine gute Wahl sind.

Afd6dc452bc20f8f06612d4792bb8be3?s=128

Stefan Tilkov

May 26, 2020
Tweet

Transcript

  1. Architectures for Modern Web Front Ends 2 0 2 0

    / 0 5 / 2 6 J U G S w i t z e r l a n d Stefan Tilkov @stilkov Lucas Dohmen @moonbeamlabs
  2. Annoying your app users in 10 easy steps

  3. 1. Forbid the use of the back and forward buttons

  4. 2. Send them to the home page when they hit

    “refresh” …
  5. 3. … or at least ensure the browser pops up

    a warning window
  6. 4. Make sure they can’t open a second browser window

  7. 5. Let them see UI decoration and ads first, content

    last
  8. 6. Make sure they can’t bookmark or send a link

  9. 7. Don’t let Google index anything

  10. 8. Show users a picture of your app – it’s

    surely better than nothing
  11. 9. Disable assistive technologies. Who needs a screen reader, anyway?

  12. 10. Ensure non-functioning JavaScript gives them a blank page

  13. History repeating … CORBA Web WS-* REST

  14. What’s the client side analogy?

  15. 1) in the SOAP/WSDL sense “Web app”2) 2) built as

    a careless SPA “Web service”1) > Uses HTTP as transport > Ignores HTTP verbs > Ignores URIs > Exposes single “endpoint” > Fails to embrace the Web > Uses browser as runtime > Ignores forward, back, refresh > Does not support linking > Exposes monolithic “app” > Fails to embrace the browser
  16. The web-native way of distributing logic Process Flow Presentation Domain

    Logic Data Server Client > Rendering, layout, styling on an unknown client > Logic & state machine on server > Client user-agent extensible via code on demand
  17. HTML & Hypermedia • In REST, servers expose a hypermedia

    format • Option 1: Just invent your own JSON-based, incomplete clone • Option 2: Just use HTML • Clients need to be RESTful, too • Option 1: Invent your own, JS-based, buggy, incomplete implementation • Option 2: Use the browser
  18. A great REST hypermedia API is very similar to a

    simple, server-sided rendered web application
  19. The role of JS in modern Web applications

  20. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client HTML
  21. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client JSON
  22. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client JSON JSON API JSON Client
  23. Why Routing? Solution: Store some app state in the URI!

    Bookmarks? Deep links? Reload? Browser Server GET / 200 OK… GET /app.js 200 OK… App start…
  24. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client JSON JSON API JSON Client
  25. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client JSON JSON API JSON Client
  26. Searchability Crawler Server GET / Static HTML Snapshot API run

    App AJAX Fun…
  27. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client JSON JSON API JSON Client Rendering Logic Routing HTML
  28. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client JSON JSON API JSON Client Rendering Logic Routing HTML Same Code
  29. “All your users are non-JS users while they‘re downloading your

    JS” Jake Archibald, developer advocate for Google Chrome
  30. Prerendering Browser Server GET / Static HTML Snapshot API run

    App AJAX Fun… FCP TTI load & run App AJAX Fun…
  31. Hydration How to simulate readiness? What about Events (Clicks etc)?

    How to match server-side HTML to client-side DOM? Browser GET / Static HTML Snapsho FCP TTI load & run App
  32. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client JSON JSON API JSON Client (Pre-)Rendering Logic Routing HTML
  33. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client JSON JSON API JSON Client (Pre-)Rendering Logic Routing HTML Hydration
  34. JSON API Routing Rendering Logic Look & Presentation Logic Server

    Client JSON JSON Client (Pre-)Rendering Logic Routing HTML Hydration Business Logic State Business Logic Same functionality, different languages! State
  35. State Business Logic JSON API Business Logic State Routing Rendering

    Logic Look & Presentation Logic Server Client JSON JSON Client (Pre-)Rendering Logic Routing HTML Hydration high control, high observability low control, low observability
  36. State Routing Rendering Logic Look & Presentation Logic Server Client

    JSON JSON Client (Pre-)Rendering Logic Routing HTML Hydration Business Logic JSON API State Business Logic Much, much more client side JavaScript
  37. 37 Resilience customElement.define( "my-element", MyElement ); Modern API in JS

    Modern API in CSS .item { display: contents; } Firefox 63: It works Firefox 63: It works Chrome 69: Exception Chrome 69: Skips that line
  38. “JavaScript is the most expensive part of your page” Addy

    Osmani, Speed team lead for Google Chrome
  39. Cost of JavaScript on Reddit.com Pixel 3 Moto G4 Alcatel

    2X 5059D 0 seconds 1 second 2 seconds Main thread Worker thread The cost of JavaScript in 2019
  40. Test your app on real, low-cost devices and slow networks

    (No, an emulator is not enough)
  41. None
  42. RAGE CLICKS “15% of users tried to interact sometime between

    onload and interactive.” Akamai: Metrics That Matter RAGE CLICKS
  43. Hydration is not a progressive enhancement, it‘s an uncanny valley

  44. Now what?

  45. • Client-side state handling • Better offline support • Closer

    to desktop model • Better performance • Server-side state handling • Simpler • More resilient & observable • Smaller client footprint • Better performance
  46. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client HTML
  47. State Business Logic Routing Rendering Logic Look & Presentation Logic

    Server Client HTML Rendering Logic Look & Presentation Logic JSON/ HTML
  48. 48 Let's use the technologies from SPAs, but keep the

    architecture of the Web.
  49. Pure SPA SSR+RC Pure SSR • Large number of users

    • Basic UX needs • Support for past, present and future devices • Complex global client state • Offline support • Controlled device landscape • Like SSR, but with • more UX needs • Complex component state • Basic offline support
  50. Krischerstr. 100 40789 Monheim am Rhein Germany +49 2173 3366-0

    Ohlauer Str. 43 10999 Berlin Germany +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany +49 2173 3366-0 Kreuzstr. 16 80331 München Germany +49 2173 3366-0 Hermannstrasse 13 20095 Hamburg Germany +49 2173 3366-0 Gewerbestr. 11 CH-6330 Cham Switzerland +41 41 743 0116 innoQ Deutschland GmbH innoQ Schweiz GmbH www.innoq.com 50 Thanks! Questions? Stefan Tilkov stefan.tilkov@innoq.com +49 170 4712625 stilkov Lucas Dohmen lucas.dohmen@innoq.com +49 151 75062496 moonbeamlabs