Ankündigung

Einklappen
Keine Ankündigung bisher.

große Webseite mit viel Daten in SPA?

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • große Webseite mit viel Daten in SPA?

    Hallo Leute,

    ich frage mich, ob es noch sinnvoll ist, eine große Webseite, die viel Daten hat, noch im Single Page Application Konzept zu machen? State of the Art wäre es, aber ich denke, es wäre nicht so sinnvoll so viele Daten in JavaScript vorzuhalten.

    Es wird eine große Seite mit vielen Unterseiten, die widerrum viele Funktionen haben werden. Soll man das nun wirklich alles in SPA pressen? Ich meine, wie macht Facebook das? Die sollten ja vor dem gleichen Problem stehen.

    Es wird ein komplett neues Projekt und ich wollte es diesmal gleich richtig machen.


    MFG

    derwunner


  • #2
    das liegt weder an der Masse der Daten insgesamt noch an der Zahl an "Unterseiten" sondern an der Struktur.
    Facebook (ich kenne es nicht und rate mal ins Blaue) hat:
    -Posts
    -Friends
    -Comments
    -Pictures

    was sich so recht einfach in ein gängiges JS-MVC pressen lässt.

    Also, was ist das für eien Seite ?

    Kommentar


    • #3
      Zitat von derwunner Beitrag anzeigen
      ich frage mich, ob es noch sinnvoll ist, eine große Webseite, die viel Daten hat, noch im Single Page Application Konzept zu machen? State of the Art wäre es, aber ich denke, es wäre nicht so sinnvoll so viele Daten in JavaScript vorzuhalten.
      Dein Misskonzept ist der Gedanke viele Daten am Client vorhalten zu müssen. Es sollten nur die Daten am Client liegen, die dort auch angezeigt werden, der Rest ist im Backend. Also egal, ob du 1MB, 1GB, 1TB oder mehr Daten hast. Es wird immer die gleiche Menge zum Client übertragen.

      Kommentar


      • #4
        Das ist doch genau der Vorteil von einer JS-SPA im Gegensatz zu einer "klassichen" PHP-Anwendung, dass man nur noch das Grundgerüst der Seite ausliefert und die Daten dann abhängig von den User-Aktionen dynamisch nachlädt.

        Wenn man sich bspw. Shops (als einfaches und gängiges Beispiel) anschaut, die ja neben den Produktdaten auch noch Massen an Bildern nachladen müssen, dann läuft das Ganze doch auch super performant.

        Eine Frage in die Runde: Kann hier bspw. Meteor durch die Synchronisation von Server und Client einen Vorteil hinsichtlich der Performance bieten? Ich habe selbst (leider) auch noch nicht damit gearbeitet, aber einige Videos gesehen und finde es extrem interessant.

        Kommentar


        • #5
          Zitat von hellbringer Beitrag anzeigen
          Dein Misskonzept ist der Gedanke viele Daten am Client vorhalten zu müssen. Es sollten nur die Daten am Client liegen, die dort auch angezeigt werden, der Rest ist im Backend. Also egal, ob du 1MB, 1GB, 1TB oder mehr Daten hast. Es wird immer die gleiche Menge zum Client übertragen.
          Ok, das klingt gut & logisch.

          Ich denke, ich habe auch das Grundkonzept von SPA falsch vestanden: Wie der Name schon sagt, gibt es immer nur eine Seite. Das heißt, die App läuft z. B. unter /index und man kann auch nur /index aufrufen. Wenn man z. B. /posts/3 aufruft, dann springt der Frontend Router an, sprich, es wird weiterhin nur /index aufgerufen und anhand der definierte Route weiß man, welche Unterseite mit welchem Template aufgerufen werden muss.
          Das heißt auch, wenn der User auf der Seite navigiert, dann bleibt er physisch auf der selben Seite, es werden nur Daten und Templates für die Unterseite nachgeladen.

          Kommentar


          • #6
            Wenn Du es so konfigurierst?
            es macht durchaus in manchen Fällen auch Sinn statische Seiten zu haben..

            meistens ist es so gelöst, soweit ich gesehen habe:

            /index.php ist verzeichniss index wird also / aufgerufen
            /#post/3 oder auch /#/post/3 deutet auf js hin (muss aber nicht zwingend)

            /impressum ist eine meistens eher statische seite



            Kommentar


            • #7
              Ich denke, ich habe auch das Grundkonzept von SPA falsch vestanden: Wie der Name schon sagt, gibt es immer nur eine Seite. Das heißt, die App läuft z. B. unter /index und man kann auch nur /index aufrufen. Wenn man z. B. /posts/3 aufruft, dann springt der Frontend Router an, sprich, es wird weiterhin nur /index aufgerufen und anhand der definierte Route weiß man, welche Unterseite mit welchem Template aufgerufen werden muss.
              Was ist /index? Frontend-Router?

              I. d. R. ist es so, dass Du ein separates Frontend oder eine Route in Deinem wie auch immer gearteten Backend hast, dass Dir Deinen Einstieg in die Applikation in Form von HTML gibt. Daneben gibt es dann die Assets aber die sollten statisch geladen werden.

              Die Daten hingegen werden dann per Ajax vom Backend - mittlerweile meist per rest (oder etwas, das nah dran ist) & json - nachgeladen. Die Daten wohgemerkt. Die Aufbereitung findet dann im Frontend statt. Die URL im Browser muss dabei nicht mit der, die im Backend aufgerufen wird, übereinstimmen.

              So ist die Reinform - Es gibt aber auch Zwischenstufen wie z. B. serverseitig gerenderte Komponenten, die direkt html statt reine Daten ausliefern.

              Kommentar

              Lädt...
              X