wake-up-neo.com

Wann ist "clientseitiges Routing" oder "serverseitiges Routing" zu verwenden?

Ich bin etwas verwirrt darüber und ich fühle mich etwas dumm, diese Frage zu stellen, aber ich möchte sie verstehen.

Angenommen, ich arbeite mit einem clientseitigen Web-Framework wie Backbone, Angular oder Durandal. Dieses Framework beinhaltet das Routing.

Aber ich habe natürlich immer noch einen Server für Datenbanksachen und so weiter, der auch Routing hat.

Meine Frage ist jetzt: 

Wann ist "clientseitiges Routing" oder "serverseitiges Routing" zu verwenden? 

Wie wird "entschieden", ob auf Client-Seite bereits Routing ausgeführt wird oder ob die Anforderung zuerst an den Webserver gesendet wird? 

Es fällt mir besonders schwer, mir das vorzustellen, weil der Client das Routing durchführen könnte, bevor der Server diese Anforderung überhaupt kennenlernt. 

Ich wäre sehr dankbar, wenn jemand erklären könnte, wie diese beiden Routingsysteme zusammenarbeiten.

P .: Ich habe keine Codebeispiele beigefügt, da ich keine Antwort auf ein bestimmtes Framework suche, sondern allgemein auf den Routing-Prozess.

53
tomet

tl; dr:

  • beim serverseitigen Routing laden Sie eine neue Website herunter, wenn Sie auf einen Link klicken.
  • beim clientseitigen Routing lädt die webapp neue Daten herunter, verarbeitet sie und zeigt sie an.

Stellen Sie sich den Benutzer vor, auf einen einfachen Link zu klicken: <a href="/hello">Hello!</a>

In einer Webanwendung, die serverseitiges Routing verwendet:

  • Der Browser erkennt, dass der Benutzer auf ein Ankerelement geklickt hat.
  • Es stellt eine HTTP-GET-Anforderung an die im Tag href gefundene URL
  • Der Server verarbeitet die Anfrage und sendet ein neues Dokument (normalerweise HTML) als Antwort.
  • Der Browser verwirft die alte Webseite insgesamt und zeigt die neu heruntergeladene an.

Wenn die Webanwendung clientseitiges Routing verwendet:

  • Der Browser erkennt, dass der Benutzer wie zuvor auf ein Ankerelement geklickt hat.
  • Ein clientseitiger Code (normalerweise die Routing-Bibliothek) fängt dieses Ereignis ab, stellt fest, dass es sich bei der URL nicht um einen externen Link handelt, und verhindert, dass der Browser die HTTP-GET-Anforderung stellt. 
  • Die Routing-Bibliothek wird dann ändert manuell die URL im Browser angezeigt (mithilfe der HTML5-Verlaufs-API oder möglicherweise URL-Hashbangs bei älteren Browsern).
  • Die Routing-Bibliothek dann ändert den Status der Client-App. Beispielsweise kann die Stammkomponente React/Angular/etc gemäß den Routenregeln geändert werden.
  • Die App (insbesondere die MVC-Bibliothek wie React) verarbeitet dann Statusänderungen. Es rendert die neuen Komponenten und fordert bei Bedarf neue Daten vom Server an. Diesmal ist die Antwort jedoch nicht notwendigerweise eine gesamte Webseite, sondern kann auch "Rohdaten" sein. In diesem Fall werden sie vom Client-Code in HTML-Elemente umgewandelt.

Das clientseitige Routing hört sich komplizierter an, weil es so ist. Aber manche Bibliotheken machen es heutzutage wirklich einfach.

Es gibt mehrere Vorteile des clientseitigen Routings: Sie laden weniger Daten herunter, um neue Inhalte anzuzeigen, Sie können DOM-Elemente wiederverwenden, Benachrichtigungen über das Laden an Benutzer anzeigen usw. Allerdings können Webapps, die das DOM auf Serverseite generieren, viel einfacher durchsucht werden (durch Suchen) Engines), wodurch die SEO-Optimierung vereinfacht wird. Die Kombination dieser beiden Ansätze ist ebenfalls möglich, der ausgezeichnete Flow Router SSR ist ein gutes Beispiel dafür.

49
aedm

Ich denke clientseitiges Routing wird von Einzelseitenanwendungen verwendet, bei denen der tatsächliche Standort niemals verlassen wird.

Das Routing funktioniert durch Anhängen an die aktuelle Seite, auf die clientseitige Routing-Frameworks reagieren.

index.html #/mysubpage

Serverseitiges Routing ähnelt dem, was Apache standardmäßig beim Aufrufen einer Unterwebsite über seine URL ausführt. Node.js verwendet dies jedoch mithilfe von Routen, da die HTML-Dateien zuerst gerendert werden müssen.

Wenn Sie über ein SPA mit einem clientseitigen Routing-Framework verfügen und Node.js verwenden, benötigen Sie immer noch serverseitiges Routing, um zwischen Standorten zu wechseln

3

Moderne Anwendungen verwenden häufig sowohl clientseitiges als auch serverseitiges Routing auf "gemischte" oder "hybride" Weise, so dass es ziemlich schwierig ist, eine Grenze zwischen diesen beiden Techniken zu ziehen.

Um when und how besser verstehen zu können, um serverseitiges Routing und clientseitiges Routing zu verwenden, müssen Sie wahrscheinlich herausfinden, was passiert, wenn Sie über eine große Anwendung verfügen, die zum Verwalten verwendet wird eine große Herstellerfirma (dies kommt in der realen Welt NICHT sehr oft vor. Es ist nur ein nützliches Beispiel).

In diesen Fällen haben Sie wahrscheinlich verschiedene Personen (mit verschiedenen Rollen), die unterschiedliche Teile dieser komplexen Umgebung sehen (verschiedene Aspekte oder Domänen). Ein Techniker würde beispielsweise einen Dateiserver mit einer Vielzahl digitaler Dokumente sehen, während die Mitarbeiter der Unternehmenskantine das Menü für die Vorbereitung, den Arbeitsplan und den Laden sehen würden. Dies sind völlig unterschiedliche Anwendungsdomänen, für die völlig unterschiedliche Benutzeroberflächen erforderlich sind. Daher ist es sinnvoll, für jeden Benutzertyp unterschiedliche SPAs bereitzustellen.

In diesem Fall können Sie serverseitiges Routing verwenden, um serve eine bestimmte Benutzeroberfläche (SPA) für einen bestimmten Benutzer zu erstellen, während Sie clientseitiges Routing für navigate innerhalb dieser Benutzeroberfläche (und verwenden können) zu laden Daten). Stellen Sie sich diese SPAs als "Dashboards" oder "Bedienfelder" vor, die bestimmten "Aufgaben" gewidmet sind und von bestimmten Arten von "Profis" verwendet werden.

Sie könnten beispielsweise eine/myapp/engineering-Route für alle Ingenieure und eine/myapp/canteen für Ihr Kantinenpersonal haben. Jede dieser URLs würde ein bestimmtes Domäne und dienen ein bestimmtes Dashboard für einen bestimmten Typ von Benutzer darstellen. Diese URLs würden serverseitig verwaltet.

Stattdessen würden Sie clientseitig routing zu navigieren in jedem dieser Dashboard verwenden, Daten laden und die Benutzeroberfläche nach Bedarf neu konfigurieren.

Natürlich verfügt Ihre App wahrscheinlich auch über eine RESTful-API, mit der Ihre SPAs die benötigten Daten abrufen. Die zur API REST gehörenden URLs müssen serverseitig verwaltet werden, um ihren Job auszuführen (auch wenn sie NICHT echten HTML-Seiten zugeordnet sind) und werden nur von Ihren SPAs "hinter den Kulissen" aufgerufen. Sie werden normalerweise in einer getrennten "Domäne" wie/myapp/api aufbewahrt.

Das gleiche passiert bei statischen Webseiten (wie der "Kontaktseite" und "Info" -Seite), die sich normalerweise in einem/myapp/static-Ordner (oder "Domäne") befinden und auf der Serverseite (dieser Ordner oder "Domäne") verwaltet werden be - und wird häufig auf einem anderen Server gehostet).

Daher sollten Sie wahrscheinlich serverseitiges Routing für separate Anwendungsdomänen voneinander und clientseitiges Routing für navigate in jeder Domäne verwenden.

1
AlexBottoni