Wenn die Verwendung von "client-Seite "routing" oder "server-side-routing"?

Ich bin ein wenig verwirrt über dieses, und ich fühle mich etwas blöd diese Frage, aber ich will es verstehen.

So, sagen, ich arbeite mit einem client-seitigen web-Frameworks wie Backbone, Angular oder Durandal. Dieser Rahmen umfasst das routing.

Aber ich habe natürlich noch einen server für die Datenbank-Sachen, und so weiter, die hat auch routing.

Meine Frage ist jetzt:

Wenn die Verwendung von "client-Seite "routing" oder "server-side-routing"?

Wie ist es "entschieden", ob das routing ist bereits erfolgt auf der client-Seite ist, oder ob die Anfrage zunächst an den web-server?

Ich habe besonders schwer, sich dies vorzustellen, da die client-Seite tun könnte, routing, bevor der server bekommt zu wissen, über diesen Antrag.

Ich wäre sehr dankbar, wenn jemand erklären könnte, wie diese beiden routing-Systeme arbeiten zusammen.

P. S.: ich habe nicht im Lieferumfang enthalten code-Beispiele, weil ich bin nicht auf der Suche für eine Antwort zu einem bestimmten Rahmen, aber in Bezug auf den routing-Prozeß im Allgemeinen.

  • Was genau meinst du mit server-side-routing? Meinst du schlagen, einen http-Endpunkt definiert durch Ihre API, oder ein http-Endpunkt definiert durch Ihre Datenbank-API? Routing auf dem client-Seite umfasst der UI; routing auf der server-Seite in der Regel umfasst die Ressourcen, die Benutzeroberfläche, oder angetrieben werden, die durch die UI. Könntest du eventuell ein hypothetisches Szenario?
  • Ich stieß zuerst auf diesen, wenn mit Blick auf dieses Projekt: github.com/mikefrey/noah-challenge.git. Er hat einige routing mit Winkel-und einige routing mit Koa (server-Seite, wie express).
  • Ich habe ein ähnliches Verständnis-problem. Ich versuche zu bauen, ein SPA und ein Im, der zurzeit mit sammy.js mit php im backend. Nun ich denke über einen Wechsel von PHP zu Node.js und es ist Express.js,, das scheint genau das zu tun, was Sammy.js das funktioniert, aber auf der server-Seite... verwirrend
InformationsquelleAutor tomet | 2014-05-31
  1. 50

    tl;dr:

    • mit server-side-routing, die Sie herunterladen, wird eine komplett neue Webseite, wenn Sie auf einen link klicken,
    • mit client-side-routing die webapp downloads, Prozesse und zeigt die neuen Daten für Sie.

    Vorstellen, dass Benutzer der Klick auf einen einfachen link: <a href="/hello">Hello!</a>

    Auf eine webapp, die verwendet server side routing:

    • Erkennt der browser, dass der Benutzer geklickt hat, auf ein anchor-element.
    • Wird eine HTTP-GET-request auf der URL, die in der href tag
    • Der server verarbeitet die Anfrage und sendet ein neues Dokument (meist HTML) als Antwort.
    • Der browser verwirft die alte Webseite zusammen und zeigt die neu heruntergeladenen.

    Wenn die webapp verwendet client side routing:

    • Erkennt der browser, dass der Benutzer geklickt hat, auf ein anchor-element, genau wie vorher.
    • Eine client-side code (in der Regel die routing-Bibliothek") fängt diese Veranstaltung, erkennt, dass die URL nicht mit einem externen link, und dann verhindert, dass der browser von der HTTP-GET-Anfrage.
    • Die routing-Bibliothek dann manuell ändert die URL im browser angezeigt (mit dem HTML5-history-API, oder vielleicht URL hashbangs auf älteren Browsern)
    • Die routing-Bibliothek dann ändert den Status der client-app. Zum Beispiel, es kann die root-Reagieren/Winkel/etc-Komponente entsprechend dem Weg Regeln.
    • Der app (vor allem das MVC-Bibliothek, wie die Reagieren), dann Prozesse, der Zustand ändert. Es macht die neuen Komponenten und, falls erforderlich, es fordert neue Daten vom server. Aber dieses mal die Antwort ist nicht unbedingt eine gesamte Webseite, es kann auch "raw" - Daten, in dem Fall der clientseitige code, wandelt ihn in HTML-Elemente.

    Client-side routing-sound komplizierter, weil es ist. Aber manche Bibliotheken machen es wirklich leicht in diesen Tagen.

    Gibt es mehrere positive Seiten der client-Seite-routing: Sie laden weniger Daten für die Darstellung neuer Inhalte, die Sie wiederverwenden können DOM-Elemente, Anzeige be-Benachrichtigungen an Benutzer etc. Aber webapps, die Erstellung des DOM auf der server-Seite sind viel einfacher zu durchsuchen (durch Suchmaschinen), wodurch SEO-Optimierung zu erleichtern. Die Kombination dieser beiden Ansätze ist ebenfalls möglich, die ausgezeichnete Flow-Router SSR ist ein gutes Beispiel dafür.

    • Ich habe eine Neugier in Bezug auf mit client-side-routing die webapp downloads, Prozesse und zeigt neue Daten für Sie. Wenn ich ein 200kb-Skript für jede Seite (wenn man bedenkt, dass 120kb ist, Reagieren selbst), bedeutet das nicht, dass client-side-routing-download 1,5 MB-Skript, auch wenn der Benutzer nicht auf jeder Seite?
    • Nein. Wenn Sie einen 200k-client-Skript im Falle der client-Seite routing, das ist für die gesamte webapp, in der Regel mit dem code für jede Seite und die komplette business-Logik. Sie brauchen nicht einbetten Reagieren in allen Seiten getrennt. Es gibt (in der Regel) nur eine gemeinsame Instanz, die jede JS-Bibliothek, die in der gesamten app.
    • Sie wissen sehr gut, dass das schreiben eine React-Komponente ohne import React from 'react' wird nicht funktionieren, also muss es importiert werden, in jeder Komponente, die ich Schreibe. Aber der 200k-Skript ist für eine Seite im Fall von server-side-routing.
    • Ich bin mir nicht ganz sicher, ob ich dein problem verstanden. Die import Richtlinie nicht einbetten, wird eine neue Instanz von sich auf jede Reagieren Komponente. Aber der clientseitige code, enthält die Logik für alle Seiten, auch diejenigen, die der Benutzer nicht besuchen, wenn das ist Ihre Frage.
    • Aber der clientseitige code, enthält die Logik für alle Seiten, auch diejenigen, die der Benutzer nicht besuchen, ja das war meine Frage, denn es schien so nutzlos, Verkehr erfolgt. Ich weiß, Reagieren Sie nicht eingebettet wird in jeder Komponente, aber ich berechnete die Größe mit so etwas wie reactSize * a theoretical script size (100k) * theoretical number of pages = 1.5m. Danke für die Klarstellung, dass für mich!
    • Sie davon ausgehen, dass die Durchschnittliche benutzerdefiniertes Skript ist über die Größe Reagieren, selbst, pro Seite. Das ist eine Menge. Ich glaube, die Summe aller benutzerdefinierten Skripten ist in der Regel nur ein Bruchteil der Bibliotheken, die Sie verwenden. Hinzu kommt, dass der client nicht zum herunterladen der gesamte HTML-markup auf in-page-navigation, und Sie werden finden, den Verkehr zumindest vergleichbare, möglicherweise sogar weniger.
    • vielen Dank für die Super Erklärung, Bei der Erstellung einer SPA es gibt Routen, die sind nur bekannt die browser. Für Beispiel, '/Kunden/21', Wenn diese route wird manuell eingegeben, was passieren wird, oder wie können wir damit umgehen (eigentlich bin ich nachdem problem zu verstehen, was diese Bibliothek eigentlich tun github.com/johnpapa/lite-server) Jede Hilfe ist willkommen
    • Wenn Sie geben Sie eine URL manuell eine Anforderung an den server. Das SPA ist wie gewohnt heruntergeladen, und dann die router-Bibliothek initialisiert den Zustand Ihrer app auf Basis der URL. Sie können nicht fangen oder überschreiben Sie diese, denn es ist nicht ein DOM-event.

    InformationsquelleAutor aedm
  2. 3

    Ich denke client side routing ist von single page Anwendungen, wo die eigentliche Website ist nie verlassen.

    Routing funktioniert durch anfügen an die aktuelle Seite, auf der client-Seite routing Rahmenbedingungen reagieren.

    index.html - #/mysubpage

    Server side routing ähnlich ist, führt der apache standardmäßig beim Aufruf einer Unterwebsite durch die url, aber node.js nicht, dass durch die Verwendung von Routen, weil die html-Dateien gerendert werden müssen erste.

    Wenn Sie ein SPA mit einem client side routing-Rahmen, und Sie sind mit Node.js Sie müssen noch server side routing zum wechseln zwischen Seiten,

    InformationsquelleAutor Marian Klühspies
  3. 1

    Modernen Anwendungen Häufig sowohl client-side und server-side-routing in eine "gemischte" oder "hybride" Weise, so ist es Recht schwer eine Linie zu ziehen zwischen diesen beiden Techniken.

    Besser zu verstehen wenn und wie Verwendung von server-side-routing und client-side routing, werden Sie wahrscheinlich haben, um herauszufinden was passiert, wenn Sie eine große Anwendung, die verwendet wird, um die Verwaltung einer großen manufactoring company (dies geschieht NICHT sehr oft in der realen Welt. Es ist nur ein gutes Beispiel).

    In diesen Fällen werden Sie wahrscheinlich haben verschiedene Menschen (mit verschiedenen Rollen), die unter verschiedenen Teile von diesem komplexen Umfeld (verschiedene Aspekte oder domains). Zum Beispiel, ein Ingenieur, ein Datei-server mit einer Menge digitaler Dokumente, während die Menschen im Unternehmen arbeiten, Kantine würde, sehen Sie das Menü, um vorbereitet zu sein, die Arbeitszeiten und die-Shop. Das sind ganz andere Anwendung "domains", erfordert völlig unterschiedliche UIs, so es Sinn macht zu dienen, die verschiedenen Thermen, die für jeden Typ von Benutzer.

    In diesem Fall könnten Sie die Verwendung von server-side-routing zu dienen eine bestimmte Benutzeroberfläche (SPA) an einen bestimmten Benutzer, während Sie könnte verwenden Sie die client-Seite routing zu navigieren innerhalb dieser UI (und laden Daten). Denke, diese SPAs als "dashboards" oder "control panels" gewidmet bestimmte "Aufgaben" und durch bestimmte Arten von "Profis".

    Zum Beispiel, könnten Sie eine /myapp/engineering-route für alle Ingenieure und a /myapp/canteen für alle deine Mensa-Personal. Jede dieser URLs eine bestimmte domain und würde dienen eine bestimmte dashboard zu einer bestimmten Art von Benutzer. Diese URLs verwaltet würden server-Seite.

    Statt, die Sie verwenden würden client-Seite routing zu navigieren innerhalb jeder dieser dashboard, laden von Daten und re-Konfiguration der Benutzeroberfläche benötigt.

    Natürlich, Ihre app würde wahrscheinlich auch eine RESTful-API verwendet, die durch Ihre Thermen, um die Daten abzurufen, die Sie benötigen. Die URLs gehören die REST-API verwaltet werden müssen, server-side um Ihre Aufgabe zu erledigen (auch wenn Sie NICHT verbunden, um echte HTML-Seiten) und sind aufgerufen, die nur durch Ihre SPAs "hinter den kulissen". Sie sind in der Regel gehalten in einem abgetrennten, "domain" wie /myapp/api .

    Geschieht das gleiche mit statischen web-Seite (wie die Seite "Kontakt" und "über" - Seite), die sind in der Regel gehalten /myapp/static Ordner (oder "domain") - und managed-server-Seite (dieser Ordner oder "domain" kann - und oft ist - gehostet auf einem anderen server).

    Also, sollten Sie wahrscheinlich verwenden server-side-routing zu separate Anwendungen Domänen voneinander und client-side routing zu navigieren innerhalb jeder Domäne.

    InformationsquelleAutor AlexBottoni
Schreibe einen Kommentar