© KenoKickit/Shutterstock.com
Entwickler Magazin
Klassischer Architekturansatz für Webanwendungen

JavaScript? Gern, aber bitte in Maßen

Eine moderne Webanwendung wird natürlich in JavaScript implementiert und erzeugt ihr HTML clientseitig im Browser selbst. Sie 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? Im Gegenteil, damit lassen sich Anwendungen realisieren, die oft sehr viel besser sind als die mit dem Framework der Woche realisierte Single Page App.

Stefan Tilkov, Joy Heron, Lucas Dohmen


Sehen wir uns zunächst an, welche Probleme es bei SPAs gibt. Bei der traditionellen Trennung zwischen Server und Client liegen auf der Clientseite lediglich Aussehen und Verhalten. Zustand, Geschäftslogik, Routing sowie Präsentationslogik und Templating sind ausschließlich auf dem Server zu finden (Abb. 1).

Abb. 1: Traditionelle Trennung zwischen Server und Client

Mit dem Ziel, eine App zu bauen, die schneller reagiert und vielleicht auch offlinefähig ist, wird nun oftmals Verantwortung vom Server auf den Client verschoben. In vielen Unternehmen ist ein zusätzlicher Anreiz, Abteilungen stärker zu trennen. Backend-Experten beispielsweise stellen nur ein API bereit und müssen sich um HTML/CSS/JS nicht kümmern. Zudem kursiert der Irrglaube, dass JSON kleiner sei als HTML. Jon Moore hat in einem Artikel erklärt, wieso das nicht stimmt [1]. Häufig werden die View-Logik sowie das Templating ins Frontend verschoben. Das passiert beispielsweise mit Technologien wie React oder Vue.js (Abb. 2).

Abb. 2: View-Logik und Templating werden ins Frontend verschoben

Ein weiterer Schritt ist oftmals, das Routing ebenfalls in den Client zu verlagern. In React zum Beispiel mit React Router, in Vue.js mit Vue Router. In Frameworks wie Angular oder Ember ist das Routing ebenfalls im Client angesiedelt (Abb. 3).

Abb. 3: Das Routing wandert in den Client

Auf den ersten Blick wirkt diese Verschiebung der Verantwortlichkeiten von Server zu Client erst nur wie das Versetzen einer Grenze. Tatsächlich ist es allerdings so, dass das Verschieben dieser Linie weitere Folgen mit sich bringt.

Vorher haben wir HTML im Client interpretiert – eine Funktionalität, die der Browser mit sich bringt. Nun müssen wir einen JSON-Client sowie ein API zur Verfügung stellen. Das ist auch eine Indirektion: In der Präsentationslogik greifen wir nun nicht mehr direkt auf die Geschäftslogik und den Zustand zu, sondern müssen eine Transformation in JSON und zurück durchführen. Gerade wenn Server und Client von separaten Teams entwickelt werden, erhöht sich hier der Koordinations- und Kommunikationsaufwand.

Wenn wir Geschäftslogik und Zustand vollständig auf dem Server belassen, bleibt die Menge der Kommunikation gleich bzw. erhöht sich in vielen Fällen im Vergleich zum Server-Rendered-Modell. Bewegen wir einen Teil der Geschäftslogik auf den Client, müssen wir nun stets entscheiden, welche Geschäftslogik auf dem Server, welche auf dem Client und welche an beiden Orten vorhanden sein muss. Dabei müssen wir beachten...

Entwickler Magazin
Klassischer Architekturansatz für Webanwendungen

JavaScript? Gern, aber bitte in Maßen

Eine moderne Webanwendung wird natürlich in JavaScript implementiert und erzeugt ihr HTML clientseitig im Browser selbst. Sie 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? Im Gegenteil, damit lassen sich Anwendungen realisieren, die oft sehr viel besser sind als die mit dem Framework der Woche realisierte Single Page App.

Stefan Tilkov, Joy Heron, Lucas Dohmen


Sehen wir uns zunächst an, welche Probleme es bei SPAs gibt. Bei der traditionellen Trennung zwischen Server und Client liegen auf der Clientseite lediglich Aussehen und Verhalten. Zustand, Geschäftslogik, Routing sowie Präsentationslogik und Templating sind ausschließlich auf dem Server zu finden (Abb. 1).

Abb. 1: Traditionelle Trennung zwischen Server und Client

Mit dem Ziel, eine App zu bauen, die schneller reagiert und vielleicht auch offlinefähig ist, wird nun oftmals Verantwortung vom Server auf den Client verschoben. In vielen Unternehmen ist ein zusätzlicher Anreiz, Abteilungen stärker zu trennen. Backend-Experten beispielsweise stellen nur ein API bereit und müssen sich um HTML/CSS/JS nicht kümmern. Zudem kursiert der Irrglaube, dass JSON kleiner sei als HTML. Jon Moore hat in einem Artikel erklärt, wieso das nicht stimmt [1]. Häufig werden die View-Logik sowie das Templating ins Frontend verschoben. Das passiert beispielsweise mit Technologien wie React oder Vue.js (Abb. 2).

Abb. 2: View-Logik und Templating werden ins Frontend verschoben

Ein weiterer Schritt ist oftmals, das Routing ebenfalls in den Client zu verlagern. In React zum Beispiel mit React Router, in Vue.js mit Vue Router. In Frameworks wie Angular oder Ember ist das Routing ebenfalls im Client angesiedelt (Abb. 3).

Abb. 3: Das Routing wandert in den Client

Auf den ersten Blick wirkt diese Verschiebung der Verantwortlichkeiten von Server zu Client erst nur wie das Versetzen einer Grenze. Tatsächlich ist es allerdings so, dass das Verschieben dieser Linie weitere Folgen mit sich bringt.

Vorher haben wir HTML im Client interpretiert – eine Funktionalität, die der Browser mit sich bringt. Nun müssen wir einen JSON-Client sowie ein API zur Verfügung stellen. Das ist auch eine Indirektion: In der Präsentationslogik greifen wir nun nicht mehr direkt auf die Geschäftslogik und den Zustand zu, sondern müssen eine Transformation in JSON und zurück durchführen. Gerade wenn Server und Client von separaten Teams entwickelt werden, erhöht sich hier der Koordinations- und Kommunikationsaufwand.

Wenn wir Geschäftslogik und Zustand vollständig auf dem Server belassen, bleibt die Menge der Kommunikation gleich bzw. erhöht sich in vielen Fällen im Vergleich zum Server-Rendered-Modell. Bewegen wir einen Teil der Geschäftslogik auf den Client, müssen wir nun stets entscheiden, welche Geschäftslogik auf dem Server, welche auf dem Client und welche an beiden Orten vorhanden sein muss. Dabei müssen wir beachten...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang