Was kommt nach den SPAs
•
0 gefällt mir•6 views
Sie kennen doch bestimmt das "Gesetz des Instruments": Wer als Werkzeug nur ein modernes Frontend-Framework hat, löst jedes Problem mit einer Single Page-Applikation. So oder so ähnlich, nur halt mit Hammer und Nagel lautet es, beschreibt jedoch ganz gut die aktuelle Situation der JavaScript-Welt. Auf nahezu jede Anforderung wird mit einer aufgeblähten, clientseitig gerenderten SPA geantwortet. Doch ist es schön langsam an der Zeit, dass wir uns fragen sollten: Ist das wirklich alles? Und die Antwort lautet ziemlich sicher "Nein". Doch genau diesem Thema widmen wir uns und werfen einen Blick auf die Alternativen und da gibt es viele. Im React-Ökosystem findet aktuell ein kleiner Umbruch statt. Mit Server Side Rendering, Static Site Generation, Server Components und Frameworks wie Next verschiebt sich ein Teil der Arbeit in Richtung Server. Dieser Trend ist auch bei Vue, Svelte und Angular zu beobachten. Und genau das ist es, was die sogenannten Meta-Frameworks ausmacht. Uns als EntwicklerInnen gibt das mehr Flexibilität, um auf Anforderungen reagieren zu können. Sie müssen nicht mehr den kompletten Quellcode zum Client übertragen, haben bessere Caching-Möglichkeiten und auch die Suchmaschinen sind Ihnen dankbar. Dieser Vortrag gibt Ihnen einen Überblick über die wichtigsten Features von Meta-Frameworks und wo und vor allem wie sie gewinnbringend eingesetzt werden können.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Was kommt nach den SPAs
Ähnlich wie Was kommt nach den SPAs (20)
Mehr von QAware GmbH
Mehr von QAware GmbH (20)
Was kommt nach den SPAs
- 1. Was kommt nach den SPAs?
- 2. Über mich Hallo, ich bin der Basti JavaScript Entwickler aus München https://github.com/sspringer82 @basti_springer Techstack: Node & React
- 3. Meta Frameworks Hybrid Frameworks Fullstack Frameworks
- 4. Meta Frameworks Frameworks die auf anderen Frameworks aufbauen • Etablierte Frameworks wie React, Angular, Vue, Svelte…. nutzen • Und sie verbessern
- 7. Warum ist das relevant?
- 9. Ein Tag im Leben einer SPA Applikation anfragen Ressourcen laden Zeige eine leere Seite Bootstrappe die Applikation Zeige leere Komponenten Zeige die Applikation
- 10. Meta Frameworks Warum sollten wir sie nutzen? • Konventionen & Best practices - opinionated • Kombiniere die Stärken von Client und Server • JavaScript (oder besser: TypeScript) überall • SEO Optimierung
- 11. Client & Server • Client side Framework wird auf dem Server ausgeführt • Basiert auf einer JavaScript runtime (wie Node) • Frontend Structure wird headless auf dem Server gerendert
- 12. Die wichtigsten Features SSR & SSG • Server side rendering • Static site generation
- 13. Konventionen & Best Practices Dateisystembasiertes Routing • Seitenbasierte Applikationsstruktur • Dateien & Verzeichnisse beschreiben die Routen in der Applikation • Routing aka Navigation: • Statische Routen e.g. /legal • Dynamische Routen e.g. /product/1337
- 14. Wir machen also wieder PHP?
- 15. Server side rendering 🦄 Client Server HTML Request
- 16. SSR Applikationen auf dem Server rendern • Das HTML einer Seite wird auf Anfrage auf dem Server generiert und zum Client gesendet • Die Seite wird sofort angezeigt (kein clientseitiges JS) • Verbessert die wahrgenommene Performance • Besser für Suchmaschinen - HTML kann indexiert werden
- 17. SSR Die Vorteile • Sicherheit: JavaScript wird serverseitig ausgeführt - Zugangsdaten können versteckt werden • Flexibilität: Server APIs in einer Frontend-Applikation nutzen • Geschwindigkeit: Mehrere Schritte in einem
- 19. Static site generation Client Server HTML Request 🦄 Build Process
- 20. SSG Ahead of time rendering • HTML-Strukturen zur Buildzeit erzeugen • Der HTML-Code wird im Dateisystem gespeichert und kann mit einem Webserver ausgeliefert werden • Gleiche Performance wie eine statische Seite • Lieblings SPA-Framework verwenden, um statische Seiten zu bauen
- 21. SSG Use case #1: statische Seite • Statische Seite, die immer für alle Benutzer gleich ist • Wird zur Buildzeit erzeugt • Serverseitige Ressourcen können verwendet werden
- 22. SSG Use case #2: dynamische Seite • Der Inhalt der Seite wird durch Variablen beein fl usst • /products/1337 vs /products/42 • Alle möglichen Werte müssen zur Buildzeit bekannt sein • Das Framework generiert statische Seiten für alle möglichen Werte
- 24. Hydration Der Client übernimmt die Kontrolle • Der Server bereitet die HTML Struktur vor • Der HTML-Code wird zum Client gesendet • Die Struktur ist (noch) nicht dynamisch • Das clientseitige Framework übernimmt die Kontrolle • Die Struktur ist dynamisch
- 26. Meta all the things? Meta Frameworks haben aber auch ihre Nachteile • Steile Lernkurve: Neue Konzepte und zusätzliche Abstraktionen • Opinionated Architecture: Zusätzliche Regeln, denen man folgen muss • Overhead: Je nachdem Variante braucht man entweder einen zusätzlichen Server zur build- oder runtime • Vendor lock-in: Die Verwendung von Meta Frameworks kann leicht zum vendor lock-in führen (z.B. Vercel)
- 27. Meta all the things! Wo liegen die Stärken? • Große und komplexe Websites mit vielen Seiten • SEO • Performanceverbesserung • Verbindung von Client und Server
- 29. Meta Frameworks als Backends • Daten serverseitig laden • Meta Frameworks haben Zugri ff auf alle Node APIs • Auch Datenbanken und Web Services • Für ein Meta Framework Frontend braucht man keine traditionellen REST APIs
- 30. ABER Es gibt nicht nur Meta Framework Frontends
- 32. BFF • Das Meta Framework ist eine Zwischenschicht • Es gibt ein reguläres Backend • REST API • GraphQL • Das Meta Framework fragt beim Backend an und erzeugt das Frontend • Für die Kommunikation wird Standardfunktionalität verwendet (z.B. fetch)
- 33. SSR
- 34. Backend for Frontends Frontend BFF BE Request API Request Response Generate HTML Response
- 35. BFF und SSR • Das Backend kann in einer beliebigen Sprache implementiert werden • Backend und BFF können unabhängig deployed werden • Kommunikation on Demand • Requests können gechacht werden
- 38. BFF und SSG • Die Daten werden zur Buildzeit geladen • Das Ergebnis wird zwischengespeichert • Weniger Tra ffi c zum Backend • Daten können veraltet sein - ggf. Rebuild der statischen Artefakte
- 39. Optimierungen • Leichtgewichtige Runtimes wie Vercel Edge • Kein Node.js erforderlich • Keine zusätzlichen Bibliotheken erforderlich
- 40. Optimizations • Eigene fetch Implementierung • O ff ensives Caching • Cache Invalidierung • Manuell • Eventbasiert • Zeitbasiert
- 41. Kein clientseitiges Laden mehr?
- 42. Kein clientseitiges Laden mehr? • Clientseitiges Datenladen nicht empfohlen • Optimierungspotenzial geht verloren • Im Client gibt es eine reguläre SPA • Clientseitiges Laden ist jederzeit möglich
- 43. Data APIs
- 45. Data Routes • Das Meta Framework spielt die Rolle einer API • Nachdem es in Node implementiert ist, kann es auf alle APIs zugreifen • Es kann entweder an ein anderes Backend weiterleiten oder die Anfragen selbst beantworten • Das Meta Framework ist als einziger Einstiegspunkt zum Backend
- 46. Fragen? …dann ist jetzt genau der richtige Zeitpunkt! Rainer Sturm / pixelio.de
- 47. Kontakt Sebastian Springer sebastian.springer@maibornwol ff .de MaibornWol ff GmbH Theresienhöhe 13 80339 München @basti_springer https://github.com/sspringer82