Zitat von tomBuilder
Beitrag anzeigen
Ankündigung
Einklappen
Keine Ankündigung bisher.
Frontend und Backend trennen
Einklappen
Neue Werbung 2019
Einklappen
X
-
-
sonst steht man am Ende mit einem Monolithen d und denkt "So, jetzt brauche ich ein Konzept".
Die Unterscheidung ist vom TE lottikarotti, Back und Frontend ist imho mehrdeutig. Ich finde es eine Ausblenden der Middleware in dem Kontext suboptimal.
Einen Kommentar schreiben:
-
Zitat von tomBuilder Beitrag anzeigenES gibt ja noch noscript
Zitat von tomBuilder Beitrag anzeigenund jeder request mit curl/wget etc ist non-js; aber gut.
Zitat von tomBuilder Beitrag anzeigenIch finde auch die von Dir gemachtze Unterscheidung von statischen und dynamischen Inhalten wesentli8ch zielführender
Zitat von tomBuilder Beitrag anzeigenals von Front/Backend
Zitat von tomBuilder Beitrag anzeigenwenn man dies Ajax / nonAjax versteht.
Einen Kommentar schreiben:
-
Es war so klar, dass sich die Diskussion nach dem Kommentar in die Richtung entwickelt inb4 Autovergleich
Und mach Dir doch über Skalierbarkeit Gedanken, wenn Du Deine Bottelnecks kennst.
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.)
Skalierbarkeit ist übrigens klar ein Vorteil
Man kauft die Skalierbarkeit allerdings durch ein komplizierteres System, das ist der Nachteil der mitgeliefert wird.
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.)
- 1 Likes
Einen Kommentar schreiben:
-
Zitat von xm22 Beitrag anzeigenLustig, das immer wieder zu lesen: Diese ominösen User mi deaktiviertem Javascript. In über 10 Jahren habe ich keinen einzigen kennengelernt.
Einen Kommentar schreiben:
-
Zitat von lottikarotti Beitrag anzeigenWer eine SPA mit Angular entwickelt, wird auf die User ohne JavaScript verzichten müssen.
Ich finde auch die von Dir gemachtze Unterscheidung von statischen und dynamischen Inhalten wesentli8ch zielführender als von Front/Backend wenn man dies Ajax( nonAjax versteht.
Einen Kommentar schreiben:
-
Zitat von xm22 Beitrag anzeigenLustig, das immer wieder zu lesen: Diese ominösen User mi deaktiviertem Javascript. In über 10 Jahren habe ich keinen einzigen kennengelernt.
Einen Kommentar schreiben:
-
Ein Gast antworteteLustig, das immer wieder zu lesen: Diese ominösen User mi deaktiviertem Javascript. In über 10 Jahren habe ich keinen einzigen kennengelernt.
Das Frontend vom Backend zu trennen macht in jedem Fall sind. Ob das getrennte Applikationen sind oder in einem Projekt vereint, ist da nebensächlich.
Das Argument 'Performance' im Kontext dieses Threads ist auch so etwas, um das Du Dir garantiert noch keinen Kopf machen musst.
Einen Kommentar schreiben:
-
Zitat von tomBuilder Beitrag anzeigenOb Du die Templates im Client oder auf Server renderst lässt sich ja je nach Request entscheiden dachte ich.
Einen Kommentar schreiben:
-
Zitat von ChromOxid Beitrag anzeigenHier kann ich dir nicht folgen. Es ist doch wurscht ob der Request ein Ajax Request ist oder nicht. Wenn ich Frontend und Backend voneinander trenne und mein Frontend sich die Daten via Ajax vom Backend holt, geht der erste "Userrequest" beim Frontendserver ein. Der kann nichts anderes tun als das statische Frontend ausliefern, welches sich dann "selbstständig" die nötigen Daten vom Backendserver holt.
Ich habe das mit Front und Back auch mehr so verstanden:
https://de.wikipedia.org/wiki/Schichtenarchitektur
Einen Kommentar schreiben:
-
Und mach Dir doch über Skalierbarkeit Gedanken, wenn Du Deine Bottelnecks kennst.
Nicht zwingend, dein Router kann Request (ajax/not ajax) unterscheiden und so entsprechende Seiten ausliefern.
Ich sehe da keine Möglichkeit alles mit einem Request zu erledigen.
Dies ,macht unter dem Gesichtpunkt "fehledes Js" durchaus Sinn.
Einen Kommentar schreiben:
-
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)
Dies ,macht unter dem Gesichtpunkt "fehledes Js" durchaus Sinn.
Und mach Dir doch über Skalierbarkeit Gedanken, wenn Du Deine Bottelnecks kennst.
Einen Kommentar schreiben:
-
Zitat von ChromOxid Beitrag anzeigenWie sparsam wird hier mit der "Anforderung der Daten" (Ein Ajax request, oder kommen hier andere technologien ins spiel?) umgegangen?
- 1 Likes
Einen Kommentar schreiben:
-
Bei mir kam das so an als wolle der TE über das Konzept an sich sprechen
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.
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.
Einen Kommentar schreiben:
-
Zitat von BlackScorp Beitrag anzeigenja 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 BlackScorp Beitrag anzeigenGenau, ich lasse mir meine Privaten Hobby Projekte gegen bezahlung von anderen machen
Zitat von BlackScorp Beitrag anzeigenJo, wie gesagt, für ein Privates Hobby Projekte aber dennoch overpowered
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.
Einen Kommentar schreiben:
Einen Kommentar schreiben: