Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Hilfe, wir brauchen ein Frontend

243 views

Published on

Klassische serverseitige Frameworks wie JSF oder Spring MVC haben ausgedient. Heute schreibt man Frontends in Angular, React oder Vue.js, ist doch klar… Aber warum eigentlich? Was bedeuten rein clientseitige Ansätze für die Architektur einer Webanwendung? Und wann sollte man lieber auf die klassischen Frameworks zurückzugreifen? Diese und weitere Fragestellung werden in der Session behandelt.

Published in: Software
  • Get Paid To Waste Time On YouTube!  http://t.cn/AieXipTS
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Hilfe, wir brauchen ein Frontend

  1. 1. Hilfe! Wir brauchen ein Frontend Sven Kölpin - open knowledge GmbH @dskgry @_openknowledge #wissenteilen
  2. 2. Frontend Decision-Making Process
  3. 3. The SPA-Framework is just one of many decisions…
  4. 4. „Server-side rendering“ „Client-side rendering“ (SSR) (CSR)
  5. 5. Server-side rendering GET /index.xhtml Generate HTML html, css, js,… 1 2 3
  6. 6. Client-side rendering GET /index.html html, css + JavaScript 1 2 Generate HTML 3 Generate JSON GET /data.json [data] 4Generate HTML …
  7. 7. SSR Time to interactive Time to interactive CSR
  8. 8. SSR Time to interactive Server == DOM Time to interactive Server == Data CSR
  9. 9. SSR Time to interactive Server == DOM Web Page • Request amount • Request weight Time to interactive Server == Data App • Less requests • Cheaper requests CSR
  10. 10. Client-Side Architecture
  11. 11. Facts There will be a LOT of (Java | Type)Script Code
  12. 12. Facts There will be a LOT of (Java | Type)Script Code State management is complex
  13. 13. Facts There will be a LOT of (Java | Type)Script Code State management is complex Your framework choice is wrong
  14. 14. A lot of code DDD & Clean architecture High cohesion, Low coupling tweet/ tweet.view.js tweet.js tweet.repository.js tweetCreate.service.js likes/ tweetLike.service.js tweetLike.view.js user/ user.view.js user.js user.repository.js
  15. 15. State management Most complex part of SPAs Think about Lifetime Dependencies Sources App B CA Global state Local state URL state Derived state UI state Domain state
  16. 16. Sustainable apps Libraries / Pattern will change → Library management Components will stay → Web Components https://twitter.com/ThePracticalDev/status/715623065078644738
  17. 17. Data Exchange
  18. 18. Let‘s just use our RESTful API
  19. 19. [ { "tweet": "I love the web!", "timeOfTweet": "2019-04-24T08:40:27.5633", "_links": { "self": { "href": "http://localhost:8080/tweets/113" }, "author": { "href": "http://localhost:8080/tweets/113/author" }, "likes": { "href": "http://localhost:8080/tweets/113/likes" } } } ] GET /tweets *API generated with Spring Data Rest
  20. 20. A SPA needs a Use-Case-Centric API
  21. 21. Backend For Frontend (BFF) „Every frontend has it‘s own backend“ Use-case specific APIs Frontend is owner Device specific APIs BFF-Web BFF-IOSBFF-Android Microservice A Microservice N Server Monolith
  22. 22. BFF – Simple Version Monotlih Public API SPA API
  23. 23. BFF – Advanced Version BFF-Web Service A Service B Universal JS SSR your SPA
  24. 24. Query your API Use-case specific queries GraphQL REST queries GET /tweets/?fields=author:(name),tweet,likes { tweets(page:0,size:10) { tweet, likes, author { name } } }
  25. 25. What about - i18n - Validation - Logging
  26. 26. Data that‘s needed before rendering GET /index.html html, css + JavaScript Generate HTML i18n ? User settings ? …
  27. 27. Data that‘s needed before rendering SSR data into HTML Use local storage / indexedDB / HTTP-Cache / Service Workers <body> <script> const i18n = JSON.parse('{"lang":"DE_DE","main.welcome":"Willkommen"}'); const settings = JSON.parse('{"decimal_format":"##.#"}'); ... </script> </body>
  28. 28. Validation Never ever trust the client
  29. 29. Validation: Universal JS Sharable validation rules
  30. 30. Logging What‘s happening on the client?
  31. 31. Authentication & Authorization
  32. 32. Authentication Client-side „session“ via JWT Where to store JWT? credentials JWT JWT Browser Server
  33. 33. Authorization CSR based on roles Menu A Menu B AdminMenu A Menu B { roles: ["user", "admin"] } { roles: ["user"] }
  34. 34. Authorization The client is never safe Never put sensitive data in JavaScript Implications Server based authorization SPA uses code splitting Menu A Menu B { roles: ["user", "admin"] } Admin 401 Hack!
  35. 35. Conclusion
  36. 36. Frameworks & Tools USE THIS!!! Or yarn Helps a lot Must have Cool Cool Underdog Future Keep an eye on
  37. 37. Decision for SPA / CSR Developer team? Who will use it? Mobile / Offline / PWA?
  38. 38. When choosing the SPA path SPAs are not „just frontends“ Modern !== CSR e.g. github Consider compile-to frameworks e.g. vaadin SPA
  39. 39. It‘s ok not to build an SPA in 2k19
  40. 40. sven.koelpin@openknowledge.de

×