Ankündigung

Einklappen
Keine Ankündigung bisher.

Frontend und Backend trennen

Einklappen

Neue Werbung 2019

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

  • BlackScorp
    antwortet
    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

    Einen Kommentar schreiben:


  • lottikarotti
    antwortet
    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.

    Einen Kommentar schreiben:


  • LudwigBr
    antwortet
    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.

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    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.

    Einen Kommentar schreiben:


  • lottikarotti
    antwortet
    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).

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    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.

    Einen Kommentar schreiben:


  • Thallius
    antwortet
    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

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    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.

    Einen Kommentar schreiben:


  • lottikarotti
    antwortet
    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.

    Einen Kommentar schreiben:


  • LudwigBr
    antwortet
    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.

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    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.

    Einen Kommentar schreiben:

Lädt...
X