Ankündigung

Einklappen
Keine Ankündigung bisher.

Frontend und Backend trennen

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

  • Frontend und Backend trennen

    Hallo zusammen,

    bei der Planung eines neuen Projektes bin ich dabei unterschiedliche Frontendalternativen "auszuprobieren".
    Mein Backend basiert auf php und soll "APImäßig" aufgebaut sein und (json kodierte) Daten zurückgeben, welche via Ajax-Requests eingebunden werden sollen.

    Nun stellt sich mir die Frage, was für Folgen es hat Frontend und Backend komplett voneinander zu trennen. Mit "trennen" ist gemeint, beide "Teile" auf einem eigenen Server zu betreiben.
    Wobei mich sowohl der Performanzaspekt, als auch Aspekte welche meinen Code bzw. alles drum herum betreffen, interessieren.

    Vorteile:
    - Unabhängigkeit, dadurch Vereinfachung der Installation (Konkretes Beispiel: Mein php Teil wird aktuell in einer virtuellen Maschine betrieben, die vue.js cli Installation mag (meine) virtuelle Maschine nicht)
    - erzwungene Struktur (Es gibt keine Möglichkeit beide Teile zu vermischen und z.B. Datenbankanfragen in der Ausgabe zu erledigen.)
    - Performanz durch Spezialisierung (#3)

    Nachteile:
    - Erstmalige Auslieferung nicht mit einem Request möglich. (Auf einem System könnte man Daten beim Laden direkt mit Ausliefern und nur Aktualisierungen (ohne Neuladen) müssten sich des Ajax-Requests bedienen)

    diskutabel:
    - Skalierbarkeit
    -> 2 Load Balancer erforderlich (#2)
    -> Frontend nur statischen Content (#4)
    -> #24

    Freuen würde ich mich über jegliche Art von Kommentar hierzu. In erster Linie interessiert mich, ob ich hier "Nachteile" übersehe bzw. hier noch ungenannte Konsequenzen mit einhergehen. Aber auch über die Nennung weiterer "Vorteile" oder Anmerkungen freue ich mich.

    Liebe Grüße
    ChromOxid


  • #2
    Ich stelle mir die Skallierung schwierig vor, du müsstest vor dem Front End und dem Backend dann ein Loadbalancer schalten



    Ist halt unnötiger Mehraufwand.

    apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

    Kommentar


    • #3
      Grundsätzlich liegst du da natürlich nicht falsch. Wobei es durchaus einige Szenarien gibt in denen kein Mehraufwand entsteht, bzw. keine 2 Load Balancer notwendig sind. (immer dann wenn auf einer Seite nur ein Server steht. Für das Frontend, was ausschließlich für das "Erstmalige Ausliefern" zuständig ist vermutlich nicht unwahrscheinlich)

      Womöglich könnten aber auch positive Performanzeffekte entstehen. Die Webserver könnten individuell nach "Stärken" genutzt werden und entsprechend konfiguriert werden. Beispiel: der Frontendserver liefert nur statische Daten aus, d.h. da muss keine serverseitige Sprache dazwischenfunken.

      Nichts desto trotz ändere ich das mal oben ab, vermutlich hast du Recht und Skalierbarkeit ist zumindestens kein Vorteil.

      Kommentar


      • #4
        Ich sehe da zwecks Skalierbarkeit keine Probleme. Der Server für das Frontend liefert letztlich nur noch statischen Content aus (HTML, JS, Bilder). Da die Performance aufzudrehen ist relativ einfach und günstig. Die API wäre im Prinzip ein eigenes System mit eigenem Loadbalancer. Dort wird sowieso die Hauptlast liegen - und die Skalierung (je nach Anwendung, Datenbank, etc.) vermutlich auch schwieriger sein. Für den Anfang ist es aber vermutlich einfacher Front- und Backend auf dem gleichen Server zu betreiben. Auslagern kann man später immer noch, wenn man das System entsprechend darauf auslegt und der Zeitpunkt gekommen ist.

        Kommentar


        • #5
          Ich, als PHP Entwickler, verstehe das eh nicht Ich versuche bei mir im Code so wenig wie möglich JavaSCript gedöns zu haben, damit kann ich dann besser meine Unit Tests schreiben. Wenn ich dran denke dass ich noch tests in JavasSCript machen muss für das Front End, viel zu viel Aufwand.

          apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

          Kommentar


          • #6
            Zitat von BlackScorp Beitrag anzeigen
            Ich, als PHP Entwickler, verstehe das eh nicht Ich versuche bei mir im Code so wenig wie möglich JavaSCript gedöns zu haben, damit kann ich dann besser meine Unit Tests schreiben. Wenn ich dran denke dass ich noch tests in JavasSCript machen muss für das Front End, viel zu viel Aufwand.
            PHP ist solange ein guter Plan wie Du nur statischen Kontent mit ein paar "Formularen" hast. In dem Moment wo Du "bewegte" Software machen willst/must hast du mit PHP komplett verloren. Und das wird halt immer mehr gefragt. Alles soll sich bewegen, alles per Maus verschiebbar etc. Selbst in Buiseness Software wird ist sowas jetzt Standard. Diese alten PHP typischen Programme will heute eigentlich keiner mehr haben.

            Gruß

            Claus
            Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

            Kommentar


            • #7
              Zitat von Thallius Beitrag anzeigen

              PHP ist solange ein guter Plan wie Du nur statischen Kontent mit ein paar "Formularen" hast. In dem Moment wo Du "bewegte" Software machen willst/must hast du mit PHP komplett verloren. Und das wird halt immer mehr gefragt. Alles soll sich bewegen, alles per Maus verschiebbar etc. Selbst in Buiseness Software wird ist sowas jetzt Standard. Diese alten PHP typischen Programme will heute eigentlich keiner mehr haben.

              Gruß

              Claus
              Nein das Verstehe ich, meistens hast du aber eben einen erst Zustand deiner Software, dieser wird mit PHP Erzeugt und oben drauf hast du dann JavaScript gedönst. Bei uns funktioniert es auch so, dass ich PHP Seitig viele Tests habe und nur ein paar für JavaScript, eben für die speziellen Dinge.

              Bei einer Kompletten Trennung von Back und Front-End musst du ja dann quasi Doppelte Anzahl an Tests schreiben die im Grunde das Gleiche Testen, einmal im Front End und einmal im Backend. Auch wie soll man das Deployen? Was wenn PHP Code ausgerollt wurde und JavaScript erhält eine Antwort die es noch nicht kennt? Dann müsste man ja zum Ausrollen den Server ausschalten, damit der User garnicht sowas sieht.
              apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

              Kommentar


              • #8
                Zitat von BlackScorp Beitrag anzeigen
                Nein das Verstehe ich, meistens hast du aber eben einen erst Zustand deiner Software, dieser wird mit PHP Erzeugt und oben drauf hast du dann JavaScript gedönst.
                Das ändert sich durch die Trennung von Front- und Backend grundlegend. Bei uns fordert die JS-App die benötigten Daten - abhängig von der aktuellen URL (clientside routing) - von der API an und rendert anschließend das UI. Wenn die API offline ist, erhält der Nutzer eine entsprechende Fehlermeldung und kann gewisse Dinge sogar offline erledigen.

                Zitat von BlackScorp Beitrag anzeigen
                Bei einer Kompletten Trennung von Back und Front-End musst du ja dann quasi Doppelte Anzahl an Tests schreiben die im Grunde das Gleiche Testen, einmal im Front End und einmal im Backend.
                Na ja, es gibt zwar Überschneidungen, aber das Backend hat auch viele Aufgaben (i.d.R. Business-Logik) die das Frontend nicht hat und umgekehrt. Eine höhere Komplexität fordert natürlich auch mehr Arbeit. Dafür fällt serverseitig das Rendern von HTML-Templates völlig weg. Man liefert nur noch Daten aus. Der PHP-Layer wird bei meinen Anwendungen immer dünner.

                Zitat von BlackScorp Beitrag anzeigen
                Auch wie soll man das Deployen? Was wenn PHP Code ausgerollt wurde und JavaScript erhält eine Antwort die es noch nicht kennt? Dann müsste man ja zum Ausrollen den Server ausschalten, damit der User garnicht sowas sieht.
                Bei Updates erhalten unsere Nutzer bspw. einen entsprechenden Hinweis. Über eine Versionierung von App und API kann festgestellt werden ob der Client veraltet ist. In diesem Fall muss der Nutzer ein Update machen (ein Klick aufs Wölkchen).

                Kommentar


                • #9
                  Und du würdest dir zutrauen alleine diese ganze Microservice Architektur aufzustellen und auch alleine zu Pflegen?

                  Mein gegenargument ist halt, der Aufwand lohn sich nicht wenn man es selber machen muss. Die Vorteile sehe ich hier nur in Teams.
                  apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

                  Kommentar


                  • #10
                    Ich freue mich über die rege und kontroverse Beteiligung.

                    Nein das Verstehe ich, meistens hast du aber eben einen erst Zustand deiner Software, dieser wird mit PHP Erzeugt und oben drauf hast du dann JavaScript gedönst. Bei uns funktioniert es auch so, dass ich PHP Seitig viele Tests habe und nur ein paar für JavaScript, eben für die speziellen Dinge.
                    Auch wenn ich diese rangehensweise gut nachvollziehen kann und in vielen Fällen als praktikabel erachte, glaube ich, dass man sich davon etwas "lösen" muss. Frontend und UI wird gefühlt immer wichtiger, vermutlich weil hier Differenzierung möglich ist. Vom Backend erwartet man, dass es läuft und tut was es soll. Das Frontend ist einfach dichter am Kunden / Konsumenten und "beeindruckt einfacher". Deshalb wundert es mich nicht, dass es inzwischen unzählige Javascriptframeworks gibt, die darauf abzielen die von Thallius angesprochene "bewegte Software" bereitzustellen.
                    Genau diese rangehensweise hatte ich auch im Kopf, als ich oben den ersten Nachteil verfasst habe, dass ist natürlich nichtmehr möglich.

                    Bei einer Kompletten Trennung von Back und Front-End musst du ja dann quasi Doppelte Anzahl an Tests schreiben die im Grunde das Gleiche Testen, einmal im Front End und einmal im Backend. Auch wie soll man das Deployen? Was wenn PHP Code ausgerollt wurde und JavaScript erhält eine Antwort die es noch nicht kennt? Dann müsste man ja zum Ausrollen den Server ausschalten, damit der User garnicht sowas sieht.
                    Ein komplexes Frontend bringt natürlich mehr Aufwand mit sich (für alle anderen Fälle lohnt sich eine Trennung wohl auf keinen Fall), wobei ich das hier ähnlich wie lottikarotti sehe und neben einigen Überschneidungen auch klare Unterschiede bei denen man nicht "doppelt testet".
                    Punkt 2 kann ich nicht wirklich nachvollziehen, was passiert denn bei dir beim deployen im "klassischen" Fall? Hier werden die Server doch auch wenigstens einen Moment nicht erreichbar sein?

                    Und du würdest dir zutrauen alleine diese ganze Microservice Architektur aufzustellen und auch alleine zu Pflegen?

                    Mein gegenargument ist halt, der Aufwand lohn sich nicht wenn man es selber machen muss. Die Vorteile sehe ich hier nur in Teams.
                    Hier kann ich dich wieder komplett nachvollziehen, damit hast du vermutlich nicht unrecht. Wie so oft die Abwägung zwischen möglichst strukturiert, sauber und offen für neues und einer Deadline, bis zu welchem Grad das für das jeweilige Projekt Sinn ergibt muss man wohl selbst entscheiden.

                    Das ändert sich durch die Trennung von Front- und Backend grundlegend. Bei uns fordert die JS-App die benötigten Daten - abhängig von der aktuellen URL (clientside routing) - von der API an und rendert anschließend das UI. Wenn die API offline ist, erhält der Nutzer eine entsprechende Fehlermeldung und kann gewisse Dinge sogar offline erledigen.
                    In genau diese Richtung möchte ich gehen.

                    Danke für die vielen Antworten, die mir bisher den Eindruck geben, dass meine Absichten zumindestens nicht völlig abwägig sind und ich keine "großen Konsequenzen" komplett übersehen habe.

                    Kommentar


                    • #11
                      Zitat von BlackScorp Beitrag anzeigen
                      Und du würdest dir zutrauen alleine diese ganze Microservice Architektur aufzustellen und auch alleine zu Pflegen?
                      Ist das für das Thema wichtig? Wir haben für die Infrastruktur (VMs, Loadbalancer, Webserver, Datenbanken, Konfigurationen etc.) Administratoren die sich um das kümmern was wir nicht können bzw. wofür wir keine Zeit haben. Für die lokale Entwicklung braucht man keine 1:1 Nachbildung dieser Struktur. Da reicht ein Webserver mit zwei Virtual-Hosts vollkommen aus.

                      Zitat von BlackScorp Beitrag anzeigen
                      Mein gegenargument ist halt, der Aufwand lohn sich nicht wenn man es selber machen muss. Die Vorteile sehe ich hier nur in Teams.
                      Wenn man es nicht selber macht, weil man es nicht kann, nicht will oder einfach zu wenig Zeit dafür hat, dann lässt man es machen. Das ist für mich aber kein wirkliches Gegenargument. Es kann für die Skalierung sogar hilfreich sein, wenn man den einen Teil (den statischen Content in dem Fall) auslagern und unabhängig skalieren kann. Bei uns bspw. benötigt dieser Part nämlich deutlich weniger Power als die API oder die Datenbank.

                      Kommentar


                      • #12
                        Zitat von lottikarotti Beitrag anzeigen
                        Ist das für das Thema wichtig?
                        ja die Frage war "Ich möchte in meiner Freizeit ein neues Projekt machen und dort hatte ich die Idee mal das Front End von Backend zu trennen" (ist jetzt grob zusammengefasst)

                        Zitat von lottikarotti Beitrag anzeigen
                        Wenn man es nicht selber macht, weil man es nicht kann, nicht will oder einfach zu wenig Zeit dafür hat, dann lässt man es machen. Das ist für mich aber kein wirkliches Gegenargument.
                        Genau, ich lasse mir meine Privaten Hobby Projekte gegen bezahlung von anderen machen

                        Zitat von lottikarotti Beitrag anzeigen
                        Es kann für die Skalierung sogar hilfreich sein, wenn man den einen Teil (den statischen Content in dem Fall) auslagern und unabhängig skalieren kann. Bei uns bspw. benötigt dieser Part nämlich deutlich weniger Power als die API oder die Datenbank.
                        Jo, wie gesagt, für ein Privates Hobby Projekte aber dennoch overpowered

                        apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

                        Kommentar


                        • #13
                          Zitat von BlackScorp Beitrag anzeigen
                          ja die Frage war "Ich möchte in meiner Freizeit ein neues Projekt machen und dort hatte ich die Idee mal das Front End von Backend zu trennen" (ist jetzt grob zusammengefasst)
                          In der Fragestellung wurde nichts von einem Hobby-Projekt erwähnt. Bei mir kam das so an als wolle der TE über das Konzept an sich sprechen - und nicht darüber ob es für ein Hobby-Projekt (oder sonst irgendein Szenario) zu dick aufgetragen ist.

                          Zitat von BlackScorp Beitrag anzeigen
                          Genau, ich lasse mir meine Privaten Hobby Projekte gegen bezahlung von anderen machen
                          Ich sehe grundsätzlich kein Problem darin Dienstleistungen in Anspruch zu nehmen - Hobby hin oder her. Natürlich wird man aber abwägen ob das im ersten Schritt notwendig ist - aber das habe ich ja bereits angesprochen und die Alternative (=ein Server) genannt.

                          Zitat von BlackScorp Beitrag anzeigen
                          Jo, wie gesagt, für ein Privates Hobby Projekte aber dennoch overpowered
                          Jetzt ist es schon ein privates Hobby-Projekt.

                          Ich schlage vor der TE meldet sich einfach selbst zu Wort wenn er weitere Bedingungen (bspw. Wartbarkeit, Aufwand, etc.) in die Diskussion einfließen lassen will.

                          Kommentar


                          • #14
                            Bei mir kam das so an als wolle der TE über das Konzept an sich sprechen
                            Korrekt.

                            Mich würde noch eine Frage hierzu interessieren:
                            Das ändert sich durch die Trennung von Front- und Backend grundlegend. Bei uns fordert die JS-App die benötigten Daten - abhängig von der aktuellen URL (clientside routing) - von der API an und rendert anschließend das UI. Wenn die API offline ist, erhält der Nutzer eine entsprechende Fehlermeldung und kann gewisse Dinge sogar offline erledigen.
                            Wie sparsam wird hier mit der "Anforderung der Daten" (Ein Ajax request, oder kommen hier andere technologien ins spiel?) umgegangen?
                            In meinem Fall könnte ich mir spontan wenigstens 3-4 voneinander unabhängige Datenbereiche vorstellen, welche auch unabhängig aktualisiert werden sollen. Nichts desto trotz könnten die z.B, inital einmal zusammengefasst werden um aus 4 einzelnen Requests 1 großen zu machen. Ist das sinnvoll oder "Oprimierung" am falschen Ende?
                            Ich bin mir darüber im Klaren, dass man natürlich keine ganz eindeutige Antwort darauf geben kann, da es hier noch die eine oder andere weitere Abhängigkeit gibt. Eine Tendenz würde mich dennoch interessieren.

                            Kommentar


                            • #15
                              Zitat von ChromOxid Beitrag anzeigen
                              Wie sparsam wird hier mit der "Anforderung der Daten" (Ein Ajax request, oder kommen hier andere technologien ins spiel?) umgegangen?
                              Das kommt ganz auf die Datenmenge und deren Verwendungszweck an. Und natürlich auch auf die Anwendung. Grundsätzlich ist es natürlich ideal nur ein Request dafür aufzuwenden. Es kann aber auch durchaus sein, dass es Daten gibt die man - zwischen den Sessions - im localStorage behalten kann (bspw. Wörterbücher oder andere Daten die vom Nutzer unabhängig sind). An deiner Stelle würde ich erstmal damit beginnen ein Request für die Initialisierung rauszuschicken. Wenn es irgendwann notwendig wird, kannst du das immer noch zerlegen oder anders gestalten.

                              Kommentar

                              Lädt...
                              X