SS2019: Technologierecherche – Frontend Strategie
PWA ist eine App-Strategie und eine Zusammensetzung aus den Stärken von Native Apps und Web Apps. Dabei werden die vorhandenen Techniken, wie die Realisierung der Offline-Nutzung oder der Installation auf dem Homescreen implementiert. Diese Strategie wurde im Jahr 2015 das erste Mal von Google vorgestellt. PWAs werden üblicherweise mit den Web-Technologien HTML, CSS und JavaScript entwickelt. Das Wort >>Progressiv<< im Begriff Progressive Web App bedeutet, dass sich die PWA und deren Funktionsumfang an die Umstände des jeweiligen Webbrowsers anpasst. Dieses Prinzip wird auch Feature Detection genannt.
„A PWA is a website running in a browser that will progressvely add more features based on compatibility. The features involve using serivce workers for offline usage, optional web push notification, and letting the user install the web app in the home screen through the manifest“ Quelle: Firtman, M. (2016). High Performance Mobile Web: Best practices for optimizing mobile web apps.
Das Ziel von PWAs ist die Benutzererfahrung von Web Apps/Webseiten zu verbessern, indem dem Nutzer natives Verhalten geboten wird. Ebenfalls ein Ziel von PWAs ist eine einzige Codebasis zu besitzen, um die Entwicklung für alle Plattformen abzudecken, damit die PWA in Zukunft auch als Alternative zu Native Apps entwickelt und genutzt werden, um den Aufwand und die daraus resultierenden Entwicklungskosten zu reduzieren.
Mozilla.org führt eine Abbildung auf, die die Eigenschaften von PWAs aufzeigt:
Quelle: https://developer.mozilla.org/de/docs/Web/Progressive_web_apps
| Eigenschaft | Technische Komponente(n) |
|---|---|
| Homescreen-Installation | Web App Manifest |
| Offline | Service Worker/Application Shell Architektur |
| Progressive | JavaScript (Feature Detection) |
| Benachrichtigung | Service Worker/Notifications API |
| Responsive | Web-Technologien |
| Sicher | HTTPS |
Das Web App Manifest enthält Informationen über eine Anwendung in einer JSON-Datei
Quelle: https://developers.google.com/web/fundamentals/web-app-manifest/
Ein Service Worker ist ein Skript, dass separat vom Browser läuft. Service Worker befinden sich dabei zwischen Web Apps, bzw. dem Webbrowser und dem Netzwerk und fungieren hierbei im Wesentlichen als Vermittler. Dabei werden sie in einem separaten Thread abgrenzend von der Benutzeroberfläche ausgeführt. Wird eine Web App geschlossen läuft der Service Worker im Hintergrund weiter. Mit dem Service Worker sollen insbesondere Ressourcen dem Cache hinzugefügt werden, damit diese bei einem Offline-Zustand geladen werden. Als Alternative kann der Service Worker ebenfalls Ressourcen über das Netzwerk anfragen und anschließend dem Cache hinzugefügt werden.
Quelle: Die Application Shell Architektur trennt den Inhalt von der statischen Navigation um den Nutzer die Benutzeroberfläche ebenfalls in einem Offline-Zustand oder bei einer schlechten Internetverbindung unmittelbar zur Verfügung zu stellen. Dabei wird die Benutzeroberfläche unmittelbar nach der Installation des Service Workers dem Cache hinzugefügt.
Quelle: https://developers.google.com/web/fundamentals/architecture/app-shell
- Lighthouse
- Vereinfachte Updates aufgrund einer einzelnen Plattform
- Schnellere, einfachere und kostengünstigere Entwicklung
- App-Store unabhängig
- ...
Ein Service Worker ist ein Skript, dass separat vom Browser läuft. Service Worker befinden sich dabei zwischen Web Apps, bzw. dem Webbrowser und dem Netzwerk und fungieren hierbei im Wesentlichen als Vermittler (Proxy). Dabei werden sie in einem separaten Thread abgrenzend von der Benutzeroberfläche ausgeführt. Wird eine Web App geschlossen läuft der Service Worker im Hintergrund weiter. Mit dem Service Worker sollen insbesondere Ressourcen dem Cache hinzugefügt werden, damit diese bei einem Offline-Zustand geladen werden können. Als Alternative kann der Service Worker ebenfalls Ressourcen über das Netzwerk anfragen und anschließend dem Cache hinzugefügt werden.
-
Install: Um den Service Worker für die Anwendung installieren zu können muss diese registriert werden (nicht in der Service-Worker-Datei). Zum Error kann es kommen wenn statischen Ressourcen/Daten nicht gecached werden konnten.
-
Activate: Nach der Installation folgt die Aktivierung des Service Workers. Nach der Aktivierung des Service Workers ist die Installation abgeschlossen und der Service Worker kann unter dem angegebenen Scope (Geltungsbereich) genutzt werden.
-
Idle: Keines der registrierten Events wird aufgerufen und der Service Worker wartet auf neue Events.
-
Fetch: Der Service Worker agiert als Proxy zwischen Anwendung und Netzwerk und überwacht Anfragen an das Netzwerk.
-
Terminated: Der Service Worker wird nicht weiter benötigt und wurde beendet.
Der Service Worker verfügt über ein Cache Interface, das den Entwicklern die Kontrolle gibt, welche Ressourcen und Daten gespeichert werden sollen. Unter anderem können Entwickler selbst entscheiden welche Ressourcen und Daten zuvor gespeichert werden und als statische Ressourcen gelten und welche dynamischen Ressourcen bei immer ständig ändernden Daten dem Cache hinzugefügt werden sollen.
Des Weiteren hat der Entwickler die Entscheidungsfreiheit, ob die angefragten Ressourcen zuerst versucht werden soll aus dem Cache zu holen und bei keinem Ergebnis eine Netzwerkanfrage starten soll oder umgekehrt. Es gibt verschiedenen Caching-Strategien die eingesetzt und implementiert werden können, um z.B. die Anwendung den Nutzern Offline zur Verfügung zu stellen oder um die Performance zu verbessern.
Caching-Strategien
- Network only-Strategie
Bei der Network only-Strategie wird von vorne rein versucht die Ressourcen/Daten über das Netzwerk anzufragen. Da spielt es keine Rolle welche Ressourcen zuvor gecached wurden.
Code-Beispiel:
- Cache only-Strategie
Bei der Cache only-Strategie wird versucht Ressourcen/Daten ausschließlich vom Cache anzufordern.
- Network, falling back to cache-Strategie
Bei der Network, falling back to cache-Strategie wird versucht die Ressourcen/Daten über das Netzwerk anzufordern. Sollte das nicht gelingen wird geschaut ob sich die Ressourcen/Daten im Cache befinden und aus diesem geladen. Jedoch kann das dazu führen, dass Nutzer eventuell nicht die neusten Ressourcen/Daten ausgeliefert bekommen. Deshalb ist es unter anderem auch notwendig den Cache immer zu aktualisieren.
- Cache, falling back to network-Strategie
Bei der Cache, falling back to network-Strategie soll zuerst versucht werden die Ressourcen/Daten aus dem Cache zu laden. Sollte diese Variante kein Ergebnis liefern wird versucht die Ressourcen/Daten über das Netzwerk anzufragen.
- Cache & Network Race
- Cache then network-Strategie
- Generic Fallback-Strategie
Die Generic Fallback-Strategie ist eine Erweiterung der Cache, falling back to Network-Strategie. Es kann vorkommen, dass die angefragten Ressourcen/Daten weder aus dem Cache noch über das Netzwerk angefragt werden können. Für den Fall das keine Netzwerkverbindung besteht und die Ressourcen/Daten nicht im Cache liegen wird eine Fallback bereitgestellt, um die Seite nicht komplett leer zu lassen.
React ist eine JavaScript-Bibliothek und ein komponentenorientierter Ansatz zum Erstellen von Benutzeroberflächen. React wird unter anderem von Facebook, Instagram oder AirBnB verwendet. React machte schnell auf sich aufmerksam wegen seines virtuellen DOMs und der Renderingperformanz. Die Motivation hinter React war es, seinen Frontendcode leichter darstellbar und besser wartbar zu machen.
Mit React können zusammensetztbare UI-Komponenten erstellt werden. Diese Komponenten enthalten eine XML/HTML-Ähnliche Syntax. Dabei reagieren die einzelnen Komponenten auf Datenänderungen. Durch die Datenänderungen werden die Komponenten in einen neuen Zustand gebracht und erhalten neue Daten.
- Komponentenarchitektur
- Virtueller DOM
Eines der stärksten Features von React ist die Komponentenzusammensetzung, was auch als component composition bezeichnet wird. Durch dieses Feature ist es möglich das UI in kleine unabhängige Komponenten aufzuteilen.
Für die Performanz ist von Vorteil, unbrauchbare DOM-Manipulationen zu minimieren oder zu vermeiden. Bei Datenänderungen lässt React es so aussehen, als ob die gesamte Seite neu gerendert wird. Dies funktioniert mit dem virtuellen DOM
Anstatt das reale DOM bei jeder Änderung zu aktualisieren, erstellt React eine virtuelle Struktur, die wie der gewünschte Zustand des DOM aussieht. React hält das reale DOM mit dem virtuellen synchron. Bei der Änderung des Zustands der Anwendung verwendet React Algorithmen (diffing-Algorithmus, um das echte DOM mit den virtuellen zu vergleichen. Durch den Vergleich versucht dieser Algorithmus so wenig Veränderungen wie möglich vorzunehmen. Dabei kann der diffing-Algorithmus die Differenz zum realen DOM berechnen und nur den Teil des DOM aktualisieren, der geändert wurde.