Ankündigung

Einklappen
Keine Ankündigung bisher.

headless ja oder nein?

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

  • headless ja oder nein?

    Hallo,

    ob man nun headless einsetzt oder nicht, ist eine Frage, die mich zur Zeit beschäftigt und die vorallem immer mehr aktuell werden sollte. Denn das Universum Webentwicklung befindet sich im Wandel, im Wandel hin zu JavaScript und dessen headless, bzw. Single Page Application Ansätze.

    Den Begriff "headless" stelle ich mir so vor (um etwas genauer zu definieren, was hier mit der Frage gemeint ist): Darunter versteht man ein "kopfloses" System, welches ohne Frontend ausgeliefert wird. Also ohne Definition, wie denn letztendlich die HTML Ausgabe auszusehen hat. Es wird lediglich die Business-Logik definiert, also die Datenverarbeitungslogik, völlig unabhängig vom Rendering-Prozess. Dieser ging ja früher in einer klassischen PHP-Anwendung einher mit der Businuss-Logik.

    Nun frage ich mich, ab wann macht der Einsatz Sinn oder sollte man das generell tun? Oder ist komplett davon abzuraten? Mir geht es dabei vorallem um die langfristige Beständigkeit einer Webanwendung. Was soll man nach dem State of the Art tun, um eine beständige Webanwendung zu erhalten?
    Mit beständig meine ich 3 bis 5 Jahre.

    Mit dieser Frage beschäftigen sich anscheinend auch viele CMS Systeme. Manche haben schon umgestellt, manche sind in der Konzeptionsphase und wieder andere denken gar nicht daran. Deswegen meine Frage: Macht das Sinn? Macht das erst ab einer gewissen Größe (= Projektumfang / Bugdet) Sinn? Die Vorteile liegen auf der Hand: Schnelleres Laden, einheitliche Backend API, leichte Einbindung mehrerer Caching Levels, etc.


    MFG

    derwunner


    PS: Die Frage bezieht sich in erster Linie natürlich auf Meinungen. Falls es eher Off-Topic ist, dann bitte dementsprechend verschieben. Ich fand, der Thread passt hier am besten, da es ja etwas mit grundlegender Konzeption zu tun hat.


  • #2
    Logik und Darstellung in einem... wann soll das mal aktuell gewesen sein? Als 64k RAM State-Of-The-Art waren? Hab ich seit CSS 1 nicht mehr gehört, das war doch schon immer Bad Practice, gern in Kombination mit Spaghetticode.
    You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.

    Kommentar


    • #3
      Logik und Darstellung in einem... wann soll das mal aktuell gewesen sein?
      Damit ist wohl eher der normale Lifecycle im Web gemeint.
      Server nimmt Request, verarbeitet ihn, baut entsprechend eine View zusammen und liefert die als Antwort zurück.
      Dagegen stehen dann die JS-Anwendungen die vom Server nur Daten abfragen und sich die View dann selbst aufbauen.

      Standard wäre für mich immer noch ersteres.
      Zweiteres bietet sich an wenn ich eh eine API für die Daten bereitstellen will, bzw. eh schon plane verschiedene Frontends umzusetzen.
      Relax, you're doing fine.
      RTFM | php.de Wissenssammlung | Datenbankindizes | Stay fit

      Kommentar


      • #4
        Geht's denn hier jetzt um Backend/Frontend, oder Model/View/Controller, oder Server/Client, oder PHP/Browser? Sowas wie REACT oder VUE kann man natürlich machen, muss man sich halt die Userbasis ansehen, darüber habe ich auch schonmal nachgedacht, für sowas bin ich aber zu konservativ, eine Webanwendung sollte nicht von Javascript abhängig sein.
        You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.

        Kommentar


        • #5
          Meiner Meinung nach sind - zumindest die meisten - APIs (oder "headless") universeller einsetzbar. Kommt z.B. zur Webanwendung noch eine App dazu, so muss die Business-Logik nur einmal implementiert werden.
          Inwiefern aber ein JavaScript basiertes Frontend immer sinnvoll ist, darüber lässt sich streiten.
          "Software is like Sex, it's best if it's free." - Linus Torvalds

          Kommentar


          • #6
            Zitat von derwunner Beitrag anzeigen
            Den Begriff "headless" stelle ich mir so vor (um etwas genauer zu definieren, was hier mit der Frage gemeint ist): Darunter versteht man ein "kopfloses" System, welches ohne Frontend ausgeliefert wird. Also ohne Definition, wie denn letztendlich die HTML Ausgabe auszusehen hat. Es wird lediglich die Business-Logik definiert, also die Datenverarbeitungslogik, völlig unabhängig vom Rendering-Prozess. Dieser ging ja früher in einer klassischen PHP-Anwendung einher mit der Businuss-Logik.
            "Früher" ist aber schon s(e^2)hr lange her. Business und Presentation Layer voneinander zu entkoppeln ist doch quasi Tradition, auch wenn sich die Methodik stark weiterentwickelt.

            Zitat von derwunner Beitrag anzeigen
            Nun frage ich mich, ab wann macht der Einsatz Sinn oder sollte man das generell tun? Oder ist komplett davon abzuraten? Mir geht es dabei vorallem um die langfristige Beständigkeit einer Webanwendung. Was soll man nach dem State of the Art tun, um eine beständige Webanwendung zu erhalten?
            Mit beständig meine ich 3 bis 5 Jahre.
            Da Software-Produkte i.d.R. ständigen Änderungen unterliegen wirst du hierfür keine Patentlösung finden. Eine saubere Trennung der jeweiligen Layer ermöglicht es Modernisierungen schrittweise durchzuführen, ohne dass das gesamte Ökosystem beeinträchtigt wird.

            Zitat von derwunner Beitrag anzeigen
            .. CMS Systeme ..


            Zitat von derwunner Beitrag anzeigen
            Mit dieser Frage beschäftigen sich anscheinend auch viele CMS Systeme. Manche haben schon umgestellt, manche sind in der Konzeptionsphase und wieder andere denken gar nicht daran. Deswegen meine Frage: Macht das Sinn? Macht das erst ab einer gewissen Größe (= Projektumfang / Bugdet) Sinn? Die Vorteile liegen auf der Hand: Schnelleres Laden, einheitliche Backend API, leichte Einbindung mehrerer Caching Levels, etc.
            Definiere dein Produkt und dessen Eigenschaften. Ab dann gilt: KISS.

            Zitat von chorn Beitrag anzeigen
            Geht's denn hier jetzt um Backend/Frontend, oder Model/View/Controller, oder Server/Client, oder PHP/Browser? Sowas wie REACT oder VUE kann man natürlich machen, muss man sich halt die Userbasis ansehen, darüber habe ich auch schonmal nachgedacht, für sowas bin ich aber zu konservativ, eine Webanwendung sollte nicht von Javascript abhängig sein.
            Ich sehe das genau umgekehrt: moderne und interaktive Web-Anwendungen* sollten primär mit JavaScript umgesetzt werden, denn die User Experience ist dadurch um ein vielfaches besser. Gegen einen, wie auch immer gearteten, Fallback spricht allerdings nichts.

            * = Damit meine ich jetzt keinen Blog oder Online-Magazine, sondern schon sowas wie Airbnb.

            Kommentar


            • #7
              Ob so eine Architektur sinnvoll ist liegt am Content, welchen Du auslieferst.
              Bei den heutzutage üblichen Visitenseiten Webseiten der Meisten Produkte, Mittelständischen Unternehmen, Vereinen macht so eine Architektur keinen Sinn.
              Sogar ein Cms Macht da in meinen Augen wenig Sinn, aber der Kunde ...

              Bei der Backbonification
              http://ofbrooklyn.com/2012/11/13/bac...t-to-backbone/
              sind die beiden Bilder bei how to start relativ gut erklärend, finde ich.

              Kommentar


              • #8
                Also mal kurz zur Klarstellung, was ich meinte und was ich nicht meinte:

                Mit alles in einer Seite meinte ich keine Server-Architektur, sondern das alles in einer PHP Seite landet: Vom öffnenden HTML Doctype, zur Datenbankverbindung, zur Datenverarbeitung, bis hin zum schließenden HTML Element - alles in einer Seite bzw. PHP-Datei. Vielleicht gibts da noch ein paar Functions oder Klassen. Das ist dann aber nur ausgelagert wegen der Übersichtlichkeit, wirklich getrennt nach Schichten oder Layers ist da aber nichts. Sowas meinte ich. Das gibts leider noch häufig. Gerade bei kleinen Skripts wird das gerne gemacht - da muss ich nur mal ins Anfängerboard schauen...

                Und ja, es ging mir in erster Linie darum, ab wann es sich lohnt ein Frontend Framework wie Angular, React oder Vue einzusetzen und damit das V und teilweise das M in MVC ins Frontend zu verlagern. Mit teilweise Model verlagern meine ich, dass es ja auch in Angular & Co. Models gibt, in denen z. B. dann Listen gespeichert werden, die ich mir aus dem Backend geholt habe.

                Kommentar


                • #9
                  Naja. Zwischen Angular/Vue/React und PHP Spaghetti-Code gibt es aber auch noch zwischenstufen wie man seine View organisieren kann. Siehe PHP MVC und Template Engines.

                  Mit dem neu definierten Rahmen bin ich dann doch bei #2
                  Relax, you're doing fine.
                  RTFM | php.de Wissenssammlung | Datenbankindizes | Stay fit

                  Kommentar


                  • #10
                    Gerade bei kleinen Skripts wird das gerne gemacht - da muss ich nur mal ins Anfängerboard schauen...
                    damit hast Du Dir die Frage wohl selbst beantwortet.

                    Und ja, es ging mir in erster Linie darum, ab wann es sich lohnt ein Frontend Framework wie Angular, React oder Vue einzusetzen
                    Das liegt am Content!
                    Es lohnt sich da,m wo sich auch Backbone schon gelohnt hat.

                    Kommentar


                    • #11
                      Zwischen Angular/Vue/React und PHP Spaghetti-Code gibt es aber auch noch zwischenstufen
                      Das finde ich noch ziemlich sanft ausgedrückt. Ich kann nur für Vue sprechen, aber mit Logik und Darstellungsvermischung hat das wenig zu tun. Ganz im Gegenteil, es geht darum die gesamte Darstellung in der einen Datei zu bündeln. Es werden lediglich HTML, CSS und Javascript "durcheinandergeworfen", wobei das auch schon fast übertrieben ist. Drei nacheinander dargestellte Blöcke mit den jeweils relevanten Teilen für diesen View halte ich strukturiert. Da stellt sich eher die Frage, warum ich zusammengehörige Teile (Darstellung) in 3 verschiedene Dateien aufteilen sollte.

                      Die modernen Frameworks sind meiner Meinung nach in Hinblick auf Struktur gut durchdacht. Sicher gibs hier Unterschiede und je nach persönlicher Vorliebe gefallen einige Dinge besser als andere, aber mit PHP Spaghetti-Code, wie man ihn regelmäßig im Einsteigerboard sieht, hat das wenig zu tun.

                      Kommentar


                      • #12
                        Zitat von ChromOxid Beitrag anzeigen
                        Drei nacheinander dargestellte Blöcke mit den jeweils relevanten Teilen für diesen View halte ich strukturiert. Da stellt sich eher die Frage, warum ich zusammengehörige Teile (Darstellung) in 3 verschiedene Dateien aufteilen sollte.
                        Ganz einfach:

                        1. Datei ist der "Controller", er enthält die Logik der Komponenente (laden, speichern, Interaktion mit anderen Komponenten, usw. usf.).
                        2. Datei ist das Template. Es enthält die Darstellungslogik sowie den HTML-Code.
                        3. Datei ist das Layout, also CSS, Sass oder Less
                        (4. Datei ist für Tests)

                        Genau das finde ich an Angular so toll, dass es von Grund auf schon mal gut durchstrukturiert und nicht alles auf ein Haufen zusammengeworfen ist.

                        Kommentar


                        • #13
                          Ok, sehe ich ein, dass PHP-Spaghetti Code nichts mit Angular & Co. zu tun hat und dass es zwischen beiden Gegensätzen auch noch Zwischenstufen gibt.

                          Naja, ich hatte mir eher erhofft, dass mir jemand sagt, z. B. bei Szenario Hotelbuchungsseite lohnt sich der Einsatz, hingegen z. B. bei Szenario Gästebuch eher nicht. Gerade in diesem Bereich hatte ich gehofft, Erfahrungswerte von euch zu hören...

                          Kommentar


                          • #14
                            Zitat von derwunner Beitrag anzeigen
                            Naja, ich hatte mir eher erhofft, dass mir jemand sagt, z. B. bei Szenario Hotelbuchungsseite lohnt sich der Einsatz, hingegen z. B. bei Szenario Gästebuch eher nicht. Gerade in diesem Bereich hatte ich gehofft, Erfahrungswerte von euch zu hören...
                            Wir haben das Know-How, die Tools und die Infrastruktur um jedes unserer Projekte sehr effizient mit React / Angular im Frontend und mit dem ganzen heißen Scheiß im Backend umzusetzen. Die Frage, ob wir nun alles in eine PHP-Datei stopfen, stellt sich dabei nicht - um genauer zu sein: nie! - denn ein Projekt-Template mit Routing, etc. ist in 1-2 Minuten eingerichtet. Die Entscheidung welchen Ansatz wir wählen (insbesondere hinsichtlich der Technologien) hängt hierbei kaum mit der Projektgröße zusammen, sondern maßgeblich mit den Zielen des jeweiligen Projekts / Produkts (da kann User-Experience ein unheimlich wichtiges Ziel sein). Selbst fürs Prototyping nutzen wir lieber simple React / Node.js Setups, weils einfach schnell geht und man das Frontend (oder Backend) im Zweifel einfach wegschmeißen kann.

                            Kommentar


                            • #15
                              lottikarotti Nach etwas googeln werde ich nicht schlauer: Was bezeichnest du als simple React? Meinst du damit einen einfachen React App Aufbau oder ist das Fork vom React Framework?

                              Kommentar

                              Lädt...
                              X