Ankündigung

Einklappen
Keine Ankündigung bisher.

Frontend und Backend trennen

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

  • #16
    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.

    Kommentar


    • #17
      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.

      Kommentar


      • #18
        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

        Kommentar


        • #19
          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.

          Kommentar


          • #20
            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.

            Kommentar


            • #21
              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.

              Kommentar


              • #22
                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.

                Kommentar


                • #23
                  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.

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

                  Kommentar


                  • #24
                    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.)
                    Relax, you're doing fine.
                    RTFM | php.de Wissenssammlung | Datenbankindizes | Stay fit

                    Kommentar


                    • #25
                      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.

                      Kommentar


                      • #26
                        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.

                        Kommentar


                        • #27
                          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.

                          Kommentar


                          • #28
                            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
                            Relax, you're doing fine.
                            RTFM | php.de Wissenssammlung | Datenbankindizes | Stay fit

                            Kommentar


                            • #29
                              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.

                              Kommentar


                              • #30
                                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?

                                Kommentar

                                Lädt...
                                X