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

  • lottikarotti
    antwortet
    Zitat von tomBuilder Beitrag anzeigen
    Die Unterscheidung ist vom TE lottikarotti, Back und Frontend ist imho mehrdeutig.
    Nö, der TE bezieht sich hier ganz klar auf Frontend = JS-lastige Client-Anwendung und Backend = serverseitige API.

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    sonst steht man am Ende mit einem Monolithen d und denkt "So, jetzt brauche ich ein Konzept".
    wenn die Application als Monolith erscheint, hat man was falsch gemacht VPh; gängige Pragrammier Paradigment ignoriert, bspw-.

    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:


  • lottikarotti
    antwortet
    Zitat von tomBuilder Beitrag anzeigen
    ES gibt ja noch noscript
    Damit kommst du aber je nach Projekt / Anwendung nicht weit. Bei uns würde eine sinnvolle Non-JS Lösung eine Parallelentwicklung bedeuten. Es bleibt also beim guten alten "Bitte aktiveren Sie JavaScript"-Hinweis

    Zitat von tomBuilder Beitrag anzeigen
    und jeder request mit curl/wget etc ist non-js; aber gut.
    Wenn jemand Daten via curl / wget abrufen will, dann sollte dafür eine API genutzt werden, die sinnvollen Output liefert (JSON, XML, whatever).

    Zitat von tomBuilder Beitrag anzeigen
    Ich finde auch die von Dir gemachtze Unterscheidung von statischen und dynamischen Inhalten wesentli8ch zielführender
    Das bezog sich lediglich auf die beispielhafte Server-Struktur.

    Zitat von tomBuilder Beitrag anzeigen
    als von Front/Backend
    Die Begrifflichkeit ist imho korrekt.

    Zitat von tomBuilder Beitrag anzeigen
    wenn man dies Ajax / nonAjax versteht.
    Beides sind HTTP-Requests. Eine Unterscheidung zwischen "Ajax" und "Non-Ajax" hat imho keinen praktischen Nutzen.

    Einen Kommentar schreiben:


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

    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.)

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    Zitat von xm22 Beitrag anzeigen
    Lustig, das immer wieder zu lesen: Diese ominösen User mi deaktiviertem Javascript. In über 10 Jahren habe ich keinen einzigen kennengelernt.
    Wir haben 6% IE 6 User und 20% non js user weil unsere Kunden Unis und Forschungseinrichtungen sind, keine Ahnung was die da machen. Wenn du eine Browsergames Firma hast die HTML5 Games Entwickelt,dann wäre das in der Tat kein Thema.

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Zitat von lottikarotti Beitrag anzeigen
    Wer eine SPA mit Angular entwickelt, wird auf die User ohne JavaScript verzichten müssen.
    ES gibt ja noch noscript und jeder request mit curl/wget etc ist non-js; aber gut.
    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:


  • hellbringer
    antwortet
    Zitat von xm22 Beitrag anzeigen
    Lustig, das immer wieder zu lesen: Diese ominösen User mi deaktiviertem Javascript. In über 10 Jahren habe ich keinen einzigen kennengelernt.
    Wenn man als Administrator auf einem Window Server arbeitet, ist JavaScript prinzipiell deaktiviert. Kann dann sehr lustig werden, wenn man irgendwo eine Doku braucht, und dann eine verbastelte Webseite ohne JavaScript nicht funktioniert. Ist zum Glück nur sehr selten der Fall. Offenbar schauen verantwortungsbewusste Anbieter noch darauf, dass man ihre Inhalte auch ohne JavaScript abrufen kann.

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    Lustig, 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:


  • lottikarotti
    antwortet
    Zitat von tomBuilder Beitrag anzeigen
    Ob Du die Templates im Client oder auf Server renderst lässt sich ja je nach Request entscheiden dachte ich.
    Wenn man eine SPA mit Frameworks wie Angular oder React entwickelt, dann sieht der Ansatz meist so aus, dass der Server nur noch Daten ausliefert und das Rendern der Templates clientseitig (also im Browser) stattfindet. Es gibt da natürlich auch Ansätze (meist SEO-getrieben) um Content direkt auszuliefern - bei Angular nutzt man dafür bspw. angular/universal. Wer eine SPA mit Angular entwickelt, wird auf die User ohne JavaScript verzichten müssen.

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Zitat von ChromOxid Beitrag anzeigen
    Hier 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.
    Ob Du die Templates im Client oder auf Server renderst lässt sich ja je nach Request entscheiden dachte ich.
    Ich habe das mit Front und Back auch mehr so verstanden:
    https://de.wikipedia.org/wiki/Schichtenarchitektur

    Einen Kommentar schreiben:


  • LudwigBr
    antwortet
    Und mach Dir doch über Skalierbarkeit Gedanken, wenn Du Deine Bottelnecks kennst.
    Grundsätzlich liegst du hier nicht falsch, andererseits ist es auch nicht verkehrt sich vorher bereits ein paar Gedanken zu machen. Gerade wenn es darum geht Designentscheidungen zu treffen die dann wohlmöglich negative Einflüsse haben. Alles in allem war "Skalierbarkeit" aber auch kein ausschlaggebender Punkt für mich.

    Nicht zwingend, dein Router kann Request (ajax/not ajax) unterscheiden und so entsprechende Seiten ausliefern.
    Hier 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 sehe da keine Möglichkeit alles mit einem Request zu erledigen.

    Dies ,macht unter dem Gesichtpunkt "fehledes Js" durchaus Sinn.
    Das wiederum ist mir zugegebenermaßen egal. Mein Frontend wird auf Javascript basieren, wer das nicht Einschalten möchte geht mir dann eben als möglicher Konsument verloren. Wobei ich hier auch denke mit der Aufteilung nicht anders handeln zu können. Wenn mein Frontend, welches die Daten holt, nicht ausgeführt wird, wird auch der Rest nicht funktionieren.

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    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)
    Nicht zwingend, dein Router kann Request (ajax/not ajax) unterscheiden und so entsprechende Seiten ausliefern.
    Dies ,macht unter dem Gesichtpunkt "fehledes Js" durchaus Sinn.

    Und mach Dir doch über Skalierbarkeit Gedanken, wenn Du Deine Bottelnecks kennst.

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:

Lädt...
X