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

  • LudwigBr
    hat ein Thema erstellt Frontend und Backend trennen.

    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

  • hausl
    antwortet
    Bis vor kurzem war der Thread ganz interessant.

    Zitat von lottikarotti Beitrag anzeigen
    Wie dem auch sei, das artet nun zu sehr aus und ich bin aus diesem Teil der Diskussion raus.
    Können das die anderen bitte nachmachen und die Diskussion wieder auf den sachlichen Boden holen? Könnt euch ja mal per PN auf einen virtuellen Kaffee treffen und sowas klären, falls nochwas offen ist.

    Danke euch!

    Einen Kommentar schreiben:


  • lottikarotti
    antwortet
    Zitat von tomBuilder Beitrag anzeigen
    HAb ich hab ich,
    nur das erklären ist wohl gescheitert.
    In der Tat. Was du bspw. damit ausdrücken wolltest ist mir immer noch ein Rätsel (Zitat): "Ich finde es eine Ausblenden der Middleware in dem Kontext suboptimal.".

    Zitat von tomBuilder Beitrag anzeigen
    Gescheiterte Modelle sollte mann nicht zu häufig wiederhohlen.
    Du gibst schon wieder den Foren-Goethe. Ich weiß ehrlich gesagt nicht welchen Zweck das erfüllen soll.

    Zitat von tomBuilder Beitrag anzeigen
    Ich habe und wollte Dich nicht beleidigen.
    Dann lass deine nett gemeinten Nebensätze à la "aber macht nichts mzuss Dir nicht klar sein" doch einfach stecken?

    Zitat von tomBuilder Beitrag anzeigen
    Ich bitte Dich zukünftig die selben Samthandschuhe anzuziehen, welche Du von anderen verlangst.
    Das habe ich nicht verlangt. Aber macht nichts, muss dir nicht klar sein

    Wie dem auch sei, das artet nun zu sehr aus und ich bin aus diesem Teil der Diskussion raus.

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Zitat von VPh Beitrag anzeigen
    Ich schlage vor, dass du mal ausführlicher schreibst worauf du hinaus willst anstatt nur im einzelnen Satz Andeutungen zu machen.

    Bist du zu oft gegen die Glastür gelaufen oder warum bist du heute so bockig?
    HAb ich hab ich,
    nur das erklären ist wohl gescheitert.
    Gescheiterte Modelle sollte mann nicht zu häufig wiederhohlen.

    . Und unterlasse diese unterschwelligen Beleidigungen. Das ist Kinderkacke.
    Ich habe und wollte Dich nicht beleidigen. Ich bitte Dich zukünftig die selben Samthandschuhe anzuziehen, welche Du von anderen verlangst.

    Einen Kommentar schreiben:


  • lottikarotti
    antwortet
    Zitat von tomBuilder Beitrag anzeigen
    Nein, es ging darum scheinbare unmöglichkeiten zu hinterfragen; macht nicht, wenn Du sowas nicht erkennen willst.
    Sorry Kumpel, aber du bekommst kaum einen verständlichen Satz formuliert und erwartest nun dass wir (oder ich) irgendwas in deinen Aussagen erkennen? Wenn du Fragen stellen willst, dann stelle sie doch einfach. Und unterlasse diese unterschwelligen Beleidigungen. Das ist Kinderkacke.

    Einen Kommentar schreiben:


  • VPh
    antwortet
    Ich schlage vor, dass du mal ausführlicher schreibst worauf du hinaus willst anstatt nur im einzelnen Satz Andeutungen zu machen.
    macht nicht, wenn Du sowas nicht erkennen willst.
    Bist du zu oft gegen die Glastür gelaufen oder warum bist du heute so bockig?

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Zitat von lottikarotti Beitrag anzeigen
    VPh es geht tomBuilder wohl darum dass nicht *eindeutig* beschrieben wurde, dass es sich bei dem "Frontend" um eine reine JS-basierte SPA handelt die statisch ausgeliefert wird und nur noch mit einer API (Backend) kommuniziert.
    Nein, es ging darum scheinbare unmöglichkeiten zu hinterfragen; macht nicht, wenn Du sowas nicht erkennen willst.

    Einen Kommentar schreiben:


  • VPh
    antwortet
    Aufjedenfall ein Vorteil, allerdings kein "direkter Vorteil" aus der physikalischen Trennung?! Diesen Vorteil würde ich dem als API gestalteten Backend zuschreiben.
    Ah, jo jetzt weiß ich wieder warum ich hier zuerst nichts geschrieben hatte

    Zur Trennung von Backend und Frontend auf verschiedene Server gibt es glaube ich wirklich nicht soo viel zu sagen, da wird es auf die verschiedenen Konfigurationsmöglichkeiten mit der Hardware hinaus laufen.

    Ansonsten steigt die Verfügbarkeit des Services, sobald mehr als je ein Frontend- und ein Backend-Server im Einsatz sind.
    Bei nur einem Frontend- und nur einem Backend-Server ist die Verfügbarkeit geringer als wenn beide Systeme auf dem gleichen Server laufen würden.

    Das Datenbankhandling zwischen den verschiedenen Backend-Servern wird komplizierter, denke ich... hab damit keine Erfahrung.

    Einen Kommentar schreiben:


  • LudwigBr
    antwortet
    Zitat von VPh Beitrag anzeigen
    I disagree.
    Wenn man ein neues Projekt plant macht es schon Sinn sich vorher über die Vor- und Nachteile sowie überhaupt die Umsetzbarkeit verschiedener Architekturen zu informieren. Das mit dem "Warte auf die Bottlenecks" sehe ich bei Implementationsdetails als sinnvoll, wo man sonst schnell seine Zeit mit Mikrooptimierungen verschwendet.
    Beim Konzept des Systems darf man aber gerne schon vorher Zeit investieren, sonst steht man am Ende mit einem Monolithen d und denkt "So, jetzt brauche ich ein Konzept". (Jaja, für die meisten Hobbyprojekte würde auch Spaghetticode reichen um die Anforderungen für die ersten 3 Jahr abzudecken, hier geht es aber (imo) eher darum wie man es "akademisch" richtig angeht.)
    Hier erntest du meine volle Zustimmung. Genau darum ging es mir, in der Planungsphase mögliche Vor- und Nachteile abzuwägen.

    Zitat von VPh Beitrag anzeigen
    Skalierbarkeit ist übrigens klar ein Vorteil
    Man kauft die Skalierbarkeit allerdings durch ein komplizierteres System, das ist der Nachteil der mitgeliefert wird.
    Wie anfangs von mir angedeutet ist Skalierbarkeit als Thema wohl zu komplex, um es in eine einfache "Vor- und Nachteil" Liste einzutragen. -> Ich verschiebe es nach "diskutabel".

    Zitat von VPh Beitrag anzeigen
    Nächster Pluspunkt:
    Da dein Backend unabhängig vom Browser als Client funktioniert kannst du die API über jede Anwendung verwenden die HTTP-Requests senden kann. Also auch Android-, IPhone-, Winphone-App oder irgend eine Desktop-GUI oder Konsolenanwendung.
    (Das heißt du könntest auch 2 verschiedene Browser-Frontends bauen, eines mit JavaScript und ein anderes bei dem noch eine Serverseitige Sprache mit einwirkt um die Daten abzuholen.)
    Aufjedenfall ein Vorteil, allerdings kein "direkter Vorteil" aus der physikalischen Trennung?! Diesen Vorteil würde ich dem als API gestalteten Backend zuschreiben.


    Zitat von tomBuilder Beitrag anzeigen

    Die Unterscheidung ist vom TE [...], Back und Frontend ist imho mehrdeutig. Ich finde es eine Ausblenden der Middleware in dem Kontext suboptimal.
    Wenn du einen Vorschlag für eine sprachlich saubere Formulierung hast, immer her damit. Die Bezeichnung "Client und Server" (wie von VPh vorgeschlagen) trifft es, aus den von ihm genannten nachteiligen Gründen, meiner Meinung nach nicht besser.
    Den Erklärungen in #32 und #33 nach, haben zumindestens die beiden User exakt verstanden, was ich mit meiner Unterscheidung in "Frontend(server)" und "Backend(server)" meinte.


    Alles in allem bedanke ich mich bei den fleißigen Schreibern. Meine Ausgangsproblematik wurde für mich ausreichend behandelt. Eine weitere Diskussion möchte ich natürlich keinenfalls unterbinden und ich würde sie in jedem Fall weiter verfolgen.

    Einen Kommentar schreiben:


  • lottikarotti
    antwortet
    Zitat von tomBuilder Beitrag anzeigen
    Stringend argumentieren != klar werden, aber macht nichts mzuss Dir nicht klar sein.
    Setzen, sechs!

    VPh es geht tomBuilder wohl darum dass nicht *eindeutig* beschrieben wurde, dass es sich bei dem "Frontend" um eine reine JS-basierte SPA handelt die statisch ausgeliefert wird und nur noch mit einer API (Backend) kommuniziert.

    Einen Kommentar schreiben:


  • VPh
    antwortet
    Frontend liefert statische Daten aus:
    - HTML
    - JS
    - CSS

    Backend stellt eine API zu Verfügung
    - empfängt und liefert Daten im JSON-Format
    - interagiert mit Datenbanken
    - erreichbar per http/https


    Das JS vom Frontend holt die dynamischen Daten vom Backend ab und bedient die API.
    Ich sehe da keine Widersprüche, oder ähnliches, zu den von dir zitierten Zeilen.

    Oder worum genau geht es dir gerade?

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Zitat von lottikarotti Beitrag anzeigen
    Wenn das für dich noch nicht klar geworden ist, dann frag den TE doch einfach was er mit Frontend und Backend konkret meint, statt hier rumzuquatschen?
    Man man man, immer merken wa?
    Stringend argumentieren != klar werden, aber macht nichts mzuss Dir nicht klar sein.


    Einen Kommentar schreiben:


  • lottikarotti
    antwortet
    Zitat von tomBuilder Beitrag anzeigen
    aus dem ersten Post...
    So richtig stringend argumentiert da der TE nicht.
    Wenn das für dich noch nicht klar geworden ist, dann frag den TE doch einfach was er mit Frontend und Backend konkret meint, statt hier rumzuquatschen?

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Zitat von lottikarotti Beitrag anzeigen
    Nö, der TE bezieht sich hier ganz klar auf Frontend = JS-lastige Client-Anwendung und Backend = serverseitige API.
    Mit "trennen" ist gemeint, beide "Teile" auf einem eigenen Server zu betreiben.
    erzwungene Struktur (Es gibt keine Möglichkeit beide Teile zu vermischen und z.B. Datenbankanfragen in der Ausgabe zu erledigen.)
    Beispiel: der Frontendserver liefert nur statische Daten aus, d.h. da muss keine serverseitige Sprache dazwischenfunken.
    aus dem ersten Post...
    So richtig stringend argumentiert da der TE nicht.

    Einen Kommentar schreiben:


  • VPh
    antwortet
    wenn die Application als Monolith erscheint, hat man was falsch gemacht VPh; gängige Pragrammier Paradigment ignoriert, bspw-.
    Eben, deshalb plant man die Architektur ja im voraus und nicht erst wenn man auf Probleme stößt.

    "Frontend und Backend" - mir ist da auch "Client und Server" als Bezeichnung lieber. Kann auch verwirrend werden weil der Client ja für den Enduser die Rolle als Server annimmt :> Aber das wird schon durchschaubar sein

    Einen Kommentar schreiben:

Lädt...
X