Ankündigung

Einklappen
Keine Ankündigung bisher.

SPA und PHP Backend

Einklappen

Neue Werbung 2019

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

  • SPA und PHP Backend

    Hallo,

    ich habe eine Frage, die ich schonmal gestellt habe, die mich aber immer noch wurmt.

    Mein Problem ist, dass ich ein bestehendes PHP Backend habe, dass ich über Jahre entwickelt habe und dass ich jetzt nicht so einfach über den Haufen werfen kann, nur weil ein paar Frontend Typen das meinen.

    Gibt es also irgendeinen Weg Single Page Applications mit einen PHP Backend zu vereinen? Ich meine, rendering im Backend via Twig & Co. (aus PHP geladen) und im Frontend Angular 2, Vue 2 oder ähnliches.

    Bei Single Page Applications geht es ja soviel ich weiß darum, JSON ans Frontend zu senden, dass dann auf Client Seite gerendert wird. Wirklich mobile first gedacht ist das nicht, denn wie auch schon Hacker Noon festgestellt hat, ist das auf einen Smart Phone mindestens zehnfach langsamer als auf einer Desktop CPU.

    Was ich brauche von den JavaScript Frameworks ist folgendes:
    - einen netten Dialog (Ja, Dialog, nicht nur ein billiges Modal, folglich bleibt mir wohl nichts anderes, als auf jQuery UI zurück zu greifen)
    - Direktiven (eigene HTML Elemente)
    - Ajax Requests
    - Event Handling
    - Form Handling (habe da aktuell recht viel Boilerplate Code mit meiner jQuery Umsetzung, geht um Kalender / Uhrzeit Geschichten und um die Felder vor zu füllen)
    - i18n Unterstützung oder wenigstens irgendeine Internationalisierung, wegen den Kalender / Uhrzeit Sachen

    Mein aktueller Stack sieht vor, Grunt zu verwenden. Das heißt Webpack fällt schonmal raus. Ich brauche Grunt für SCSS (NodeSASS), JavaScript Minify, Gzip, CSS + JS und Sync für andere Assets (Schriftarten, Bilder usw. aus den node_modules Paketen). Vielleicht wäre auch ein kompletter Umstieg auf Webpack denkbar, wenn das meine Anforderungen abbilden kann.

    Querverweise bzw. bisherige gestellte Fragen dazu:
    http://stackoverflow.com/questions/4...hp-mvc-backend
    http://stackoverflow.com/questions/4...cture-thoughts

    Bei meinen ersten Gehversuchen mit Vue2 + Typescript bin ich auch schon hingefallen: https://forum.vuejs.org/t/cant-get-c...working/7791/7

    Ich meine, ich bin glücklich mit den Dingen, wie sie in Angular 1 waren. Das würde genau meine Anforderungen abbilden. Allerdings ist Angular 1 veraltet, folglich bin ich bei VueJS gelandet. Bei VueJS gefällt mir die Freiheit wie man hat, man kann sich also sein Frontend ähnlich aufbauen, wie man es von PHP mit composer kennt. Am liebsten würde ich Vue2 mit Typescript, rxjs für xhr und einen kleinen Wrapper um den document.querySelector verwenden. Mit Vuex ist dann auch Form Handling dabei.

    Mit meiner Problemstellung sollte ich doch hier genau richtig sein, ich meine wie habt ihr das gemacht? Wie habt ihr von jQuery zu einem modernen JavaScript Framework gerefactored mit einem bestehenden PHP Backend?


    Danke schonmal,

    derwunner

  • #2
    Zitat von derwunner Beitrag anzeigen
    Mein Problem ist, dass ich ein bestehendes PHP Backend habe, dass ich über Jahre entwickelt habe und dass ich jetzt nicht so einfach über den Haufen werfen kann, nur weil ein paar Frontend Typen das meinen.
    Manchmal muss man mit der Zeit gehen. Auch wenn man es nicht gerne hört und es viel Zeit kosten kann. Am Ende lohnt es sich.

    Zitat von derwunner Beitrag anzeigen
    Gibt es also irgendeinen Weg Single Page Applications mit einen PHP Backend zu vereinen? Ich meine, rendering im Backend via Twig & Co. (aus PHP geladen) und im Frontend Angular 2, Vue 2 oder ähnliches.
    Ein wirklich ernst gemeinter Rat von mir: versuche nicht Angular auf Templates zu stülpen, die serverseitig gerendert werden. Das wird nicht funktionieren oder du fliegst langfristig total auf die Nase damit, weil du dir dein Design entgegen Angulars Natur kaputtmachst. Angular ist meiner Meinung nach prädestiniert für SPAs, also degradiere dein Backend zu einer REST-API und lass Angular die Templates clientseitig rendern. Wenn du dich für diesen Schritt entscheidest, gehst du imho den richtigen Weg.

    Zitat von derwunner Beitrag anzeigen
    Bei Single Page Applications geht es ja soviel ich weiß darum, JSON ans Frontend zu senden, dass dann auf Client Seite gerendert wird. Wirklich mobile first gedacht ist das nicht, denn wie auch schon Hacker Noon festgestellt hat, ist das auf einen Smart Phone mindestens zehnfach langsamer als auf einer Desktop CPU.
    Mit Angular2 und ahead-of-time compilation lässt sich hier a) eine sehr gute Performance erreichen und b) die Gesamtgrößte des JS-Bundles deutlich verkleinern. Außerdem wirst du in den meisten Anwendungsfällen keinerlei Unterschied merken. Ich habe sehr große mobil-optimierte Angular-Anwendungen gebaut die teilweise mit komplexen Datagrids, Dialogen, zig Tabs und hunderten Eingabefeldern arbeiten - und die Bottlenecks sind (wenn man es richtig macht) selten Angular anzukreiden.

    Zitat von derwunner Beitrag anzeigen
    Mein aktueller Stack sieht vor, Grunt zu verwenden. Das heißt Webpack fällt schonmal raus. Ich brauche Grunt für SCSS (NodeSASS), JavaScript Minify, Gzip, CSS + JS und Sync für andere Assets (Schriftarten, Bilder usw. aus den node_modules Paketen). Vielleicht wäre auch ein kompletter Umstieg auf Webpack denkbar, wenn das meine Anforderungen abbilden kann.
    Welche Tools du für deinen Workflow nutzt ist eigt. irrelevant. Wenn du aber Angular2 nutzen solltest, empfehle ich doch webpack und / oder angular-cli.

    Zitat von derwunner Beitrag anzeigen
    Bei VueJS gefällt mir die Freiheit wie man hat, man kann sich also sein Frontend ähnlich aufbauen, wie man es von PHP mit composer kennt.
    Ich weiß nicht ob ich dich richtig verstanden habe, aber das Package-Management funktioniert auch bei Angular 1 & 2 via npm "so wie man es von PHP mit composer kennt".

    Zitat von derwunner Beitrag anzeigen
    Am liebsten würde ich Vue2 mit Typescript, rxjs für xhr und einen kleinen Wrapper um den document.querySelector verwenden. Mit Vuex ist dann auch Form Handling dabei.
    Dann nimm das doch?

    Zitat von derwunner Beitrag anzeigen
    Mit meiner Problemstellung sollte ich doch hier genau richtig sein, ich meine wie habt ihr das gemacht? Wie habt ihr von jQuery zu einem modernen JavaScript Framework gerefactored mit einem bestehenden PHP Backend?
    Indem ich eine parallele Neuentwicklung vorgenommen habe. Modul für Modul, als korrekte SPA mit REST-API. Die neuen Module wurden dann über iframes in die alte App eingebettet, bis die alte App vollständig abgelöst werden konnte. Das war ein langwieriger Prozess, nun haben wir aber eine saubere Architektur.

    PS: Wenn es nur um ein paar Dialoge geht, solltest du tatsächlich überlegen ob du nicht einfach bei jQuery bleibst. Wenn die Anwendung langfristig eine hohe Dynamik auf dem UI erreichen soll, dann solltest du eine Neuimplementierung betroffener Modul in Erwägung ziehen.
    [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

    Kommentar


    • #3
      lottikarotti Also soll ich komplett, um SPA konform zu sein, JSON an das Frontend senden und das rendern Angular 2 überlassen? Man könnte z. B. auch vorgerendertes HTML im JSON String mit übergeben. Ganz werde ich das auch nicht vermeiden können, da ich nach dem MVC entwickle und Variablen an meine View übergeben muss. Dazu kommt, dass das Backend demänchst auf Twig umgestellt wird. Wie sieht es damit aus?

      Kommentar


      • #4
        Zitat von derwunner Beitrag anzeigen
        lottikarotti Also soll ich komplett, um SPA konform zu sein, JSON an das Frontend senden und das rendern Angular 2 überlassen?
        Das ist meine Empfehlung, ja.

        Zitat von derwunner Beitrag anzeigen
        Man könnte z. B. auch vorgerendertes HTML im JSON String mit übergeben.
        Wozu? Angular 2 muss die Templates ohnehin selbst rendern. Du kannst höchstens innerhalb des root-Elements (AppComponent) statisches HTML für die Suchmaschinen ausgeben (sofern das relevant ist):

        HTML-Code:
        <my-app>
          <!-- some static content here -->
        </my-app>
        Dieser Inhalt wird rausgekickt und ersetzt, sobald Angular 2 <my-app> gerendert hat.

        Zitat von derwunner Beitrag anzeigen
        Ganz werde ich das auch nicht vermeiden können, da ich nach dem MVC entwickle und Variablen an meine View übergeben muss.
        Das ist ja kein physikalisches Gesetz. Du wirst, wenn du eine saubere SPA mit Angular bauen willst, auf das serverseitige Prerendering verzichten müssen. Alles andere führt entweder zu unnötig komplexen Gebilden oder zusätzlichem Mehraufwand / hebelt die Vorteile von Angular aus.

        Zitat von derwunner Beitrag anzeigen
        Dazu kommt, dass das Backend demänchst auf Twig umgestellt wird. Wie sieht es damit aus?
        Die vom Backend verwendete Template-Engine ist völlig Wuppe. Wenn es zu Konflikten bei der Template-Syntax kommt, kannst du Twig einfach umkonfigurieren.
        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

        Kommentar


        • #5
          lottikarotti Zum Twig Zitat, bzw. darüber: Ja stimmt, daran habe ich gar nicht gedacht. Ich könnte ja z. B. das JSON mithilfe von Twig ausgeben. Bzw. in der Angular App die ein oder andere zusätzliche Ajax Request generieren, um an die Daten zu kommen.

          Wie würde denn ein sauberer Ansatz aussehen, bei den man Design von Logik trennen kann? Also dass der Designer hergeht und nur noch die Angular Templates ändert, jedoch die JSON Response und das ganze Backend unangetastet bleibt?
          Dann kann man zwar den Designer Twig nicht an die Hand geben, aber das muss dann wohl verkraften.

          Kommentar


          • #6
            Zitat von derwunner Beitrag anzeigen
            lottikarotti Zum Twig Zitat, bzw. darüber: Ja stimmt, daran habe ich gar nicht gedacht. Ich könnte ja z. B. das JSON mithilfe von Twig ausgeben. Bzw. in der Angular App die ein oder andere zusätzliche Ajax Request generieren, um an die Daten zu kommen.
            Das kannst du natürlich machen, aber es spricht auch nichts gegen ein initiales Ajax-Request. Je nachdem ist es vielleicht sogar sinnvoll den localStorage einzubeziehen.

            Zitat von derwunner Beitrag anzeigen
            Wie würde denn ein sauberer Ansatz aussehen, bei den man Design von Logik trennen kann? Also dass der Designer hergeht und nur noch die Angular Templates ändert, jedoch die JSON Response und das ganze Backend unangetastet bleibt?
            Dann kann man zwar den Designer Twig nicht an die Hand geben, aber das muss dann wohl verkraften.
            Um ein Design zu entwickeln, reicht es doch eigentlich aus, wenn der "Designer" eine statische HTML-Vorlage liefert, die später in ein Angular-Template umgebaut wird. Sollte der Designer tatsächlich an die echten Templates ran müssen, dann sind das eigenständige .html Dateien. Er kommt also im Idealfall nicht mit dem Code oder irgendwelchen JSON-Daten in Berührung. Zum Testen muss dann allerdings die Anwendung laufen.
            [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

            Kommentar


            • #7
              Ja, dass nichts gegen einen intialen Ajax-Request spricht, stimmt auch wieder.

              Was ich vor habe und was ich brauche kann ich denke ich an einem Beispiel erklären:
              Gegeben sei ein Event Termin-Eintrage-Formular mit Start- und Endzeit und Datum, den Event Namen und Teilnehmer, sowie optionale Felder, die editierbar werden, nachdem die jeweilige Checkbox angeklickt (checked) werde. Das ganze wird in einem Dialog dargestellt, der einfach ein- und ausgeblendet wird (mittels der css Eigenschaft display). Das heißt die Textfeldwerte müssen via JavaScript änderbar sein.
              Klickt man nun auf einem Termin in dem Kalender, dann muss der Dialog erneut aufgehen und es müssen sich folglich alle Textfeld-Werte ändern mitsamt den optionalen Textfeldern, sofern im Termin hinterlegt.

              Das ganze gibt es aktuell bei mir schon, mittels calendar (bin mir gerade nicht sicher, ob der JS Kalender wirklich so heißt, er baut auf jeden Fall auf moment.js auf), jQuery Dialog und dem Klick Ereignis auf den Kalender, bzw. auf einen Termin im Kalender. Das Formular selbst hat einen ui datepicker für das Datum und einen ui spinner für Uhrzeit. Die richtige lokale Uhrzeit wird über globalize angezeigt.
              Es braucht also Funktionen, die folgendes können:
              - auf das Klick Ereignis reagieren
              - Dialog zeigen und verstecken
              - Dialog beim Zeig mit gegeben Werten befüllen
              - Dialog leeren, falls vorher ein Termin angeklickt wurde und jetzt ein neuer Termin erstellt werden soll
              - geänderten Termin per Ajax ans Backend senden
              - neuen Termin per Ajax ans Backend senden
              - Fallunterscheidung für neuen oder bereits bestehenden Termin
              - optionale Checkbox Textfelder de- und aktivieren
              - optionale Textfelder vorbefüllen beim Termin Bearbeiten
              - usw.

              All das erzeugt aktuell viel jQuery Boilerplate Code, unter anderem wegen der Globalize Definition auf die ui spinner, sowie die Textfelder leeren, was ich für jedes Textfeld einzeln machen muss.

              Das ganze könnte man schöner mit dem Angular Form Handling/Validator ausdrücken, bzw. mit dem input[type=number] als Angular Pendant zu ui spinner. Nur wie mache ich das am besten, also wie teile ich den Code am besten auf, damit Angular voll ausgereitzt wird und ich konventionell im SPA Kontext bleibe?

              Kommentar


              • #8
                Also hast du im Prinzip eine Liste mit Terminen und einen Dialog für die Termin-Details. Ich würde für beides jeweils eine eigene Komponente erstellen. Bspw. EventListComponent und EventListEntryComponent. Wenn ein Termin angeklickt wird, aktivierst du die EventListEntryComponent via ngIf und gibst über entsprechende Bindings die notwendigen Daten rein. Wenn es notwendig ist, dass der Dialog irgendwelche Daten nachträglich vom Server beziehen muss (weil bspw. die Liste nicht alle Daten verfügbar hat) führst du innerhalb von EventListEntryComponent einen Ajax-Request durch. Vom groben Konzept könnte das so aussehen: Angular1 Beispiel. Das lässt sich auch 1:1 auf Angular2 übertragen.

                Für Dialoge empfiehlt es sich allerdings, mit einer eigenen Komponente zu arbeiten, die deine Dialoge automatisch am Ende des DOM platziert. So vermeidet man unerwünschte Überblendungen bei komplexeren Layouts. Unter Angular1 arbeite ich mit einer eigenen Komponente ngComponentsQueue. Hier das Beispiel dazu: ngComponentsQueue. Das ermöglicht u.A. auch verschachtelte Aufrufe von Dialogen.
                [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                Kommentar


                • #9
                  Danke, so in etwa hatte ich mir das vorgestellt. Nur der Kalender ist keine einfache Liste, sondern ein jquery Kalender (den es aber auch für Angular gibt), aber das Prinzip bleibt das selbe. Das ganze daraufhin umzuschreiben, sollte nicht allzu schwierig sein, ebenso Form Validation mittels Angular.
                  Einen Dialog im Dialog brauche ich nicht. Der Dialog aus dem Beispiel ist ein modaler Dialog, der sich beim Schließen nur versteckt (css display: none), und der sich beim erneuten Klicken auf ein Event oder auf "Event anlegen" einfach wieder öffnet mit den vorgefüllten Feldern, sofern ein bestehendes Event geändert werden soll.

                  Kommentar


                  • #10
                    Jetzt muss ich doch nochmal nachfragen, denn das lässt mir noch keine Ruhe das Thema.

                    Gibt es denn wirklich keinen anderen sauberen Ansatz? Denn das Backend zum REST Service zu dekradieren, dass dann nur noch JSON zurück gibt, würde das V aus MVC ja komplett streichen. Und ich würde nur ungern auf die tollen Template Engines im Backend verzichten.

                    Kommentar


                    • #11
                      Zitat von derwunner Beitrag anzeigen
                      Gibt es denn wirklich keinen anderen sauberen Ansatz?
                      Nope.

                      Zitat von derwunner Beitrag anzeigen
                      Denn das Backend zum REST Service zu dekradieren, dass dann nur noch JSON zurück gibt, würde das V aus MVC ja komplett streichen.
                      Der Ort an dem MVC / MVVM / MVVC / whatever stattfindet wird dadurch nur verlagert. Im Prinzip bildet jede einzelne Angular-Komponente das MVC-Pattern ab.

                      Zitat von derwunner Beitrag anzeigen
                      Und ich würde nur ungern auf die tollen Template Engines im Backend verzichten.
                      Was gibt's denn an der Template Engine von Angular auszusetzen?
                      [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                      Kommentar


                      • #12
                        Zu beidem, weil gleichbedeutend:
                        Zitat von lottikarotti Beitrag anzeigen
                        Der Ort an dem MVC / MVVM / MVVC / whatever stattfindet wird dadurch nur verlagert. Im Prinzip bildet jede einzelne Angular-Komponente das MVC-Pattern ab.

                        Was gibt's denn an der Template Engine von Angular auszusetzen?
                        Nichts gibt es aus der Angular Template Engine auszusetzen, nur das würde dann Twig vollkommen unnütz machen. Da habe ich so bisschen Gewissensbisse.

                        Kommentar


                        • #13
                          Zitat von derwunner Beitrag anzeigen
                          Nichts gibt es aus der Angular Template Engine auszusetzen, nur das würde dann Twig vollkommen unnütz machen. Da habe ich so bisschen Gewissensbisse.
                          Und?
                          [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                          Kommentar

                          Lädt...
                          X