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

  • #31
    Zitat von lottikarotti Beitrag anzeigen
    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?
    Man man man, immer merken wa?
    Stringend argumentieren != klar werden, aber macht nichts mzuss Dir nicht klar sein.


    Kommentar


    • #32
      Frontend liefert statische Daten aus:
      - HTML
      - JS
      - CSS

      Backend stellt eine API zu Verfügung
      - empfängt und liefert Daten im JSON-Format
      - interagiert mit Datenbanken
      - erreichbar per http/https


      Das JS vom Frontend holt die dynamischen Daten vom Backend ab und bedient die API.
      Ich sehe da keine Widersprüche, oder ähnliches, zu den von dir zitierten Zeilen.

      Oder worum genau geht es dir gerade?
      [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
      [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

      Kommentar


      • #33
        Zitat von tomBuilder Beitrag anzeigen
        Stringend argumentieren != klar werden, aber macht nichts mzuss Dir nicht klar sein.
        Setzen, sechs!

        VPh es geht tomBuilder wohl darum dass nicht *eindeutig* beschrieben wurde, dass es sich bei dem "Frontend" um eine reine JS-basierte SPA handelt die statisch ausgeliefert wird und nur noch mit einer API (Backend) kommuniziert.
        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

        Kommentar


        • #34
          Zitat von VPh Beitrag anzeigen
          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.)
          Hier erntest du meine volle Zustimmung. Genau darum ging es mir, in der Planungsphase mögliche Vor- und Nachteile abzuwägen.

          Zitat von VPh Beitrag anzeigen
          Skalierbarkeit ist übrigens klar ein Vorteil
          Man kauft die Skalierbarkeit allerdings durch ein komplizierteres System, das ist der Nachteil der mitgeliefert wird.
          Wie anfangs von mir angedeutet ist Skalierbarkeit als Thema wohl zu komplex, um es in eine einfache "Vor- und Nachteil" Liste einzutragen. -> Ich verschiebe es nach "diskutabel".

          Zitat von VPh Beitrag anzeigen
          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.)
          Aufjedenfall ein Vorteil, allerdings kein "direkter Vorteil" aus der physikalischen Trennung?! Diesen Vorteil würde ich dem als API gestalteten Backend zuschreiben.


          Zitat von tomBuilder Beitrag anzeigen

          Die Unterscheidung ist vom TE [...], Back und Frontend ist imho mehrdeutig. Ich finde es eine Ausblenden der Middleware in dem Kontext suboptimal.
          Wenn du einen Vorschlag für eine sprachlich saubere Formulierung hast, immer her damit. Die Bezeichnung "Client und Server" (wie von VPh vorgeschlagen) trifft es, aus den von ihm genannten nachteiligen Gründen, meiner Meinung nach nicht besser.
          Den Erklärungen in #32 und #33 nach, haben zumindestens die beiden User exakt verstanden, was ich mit meiner Unterscheidung in "Frontend(server)" und "Backend(server)" meinte.


          Alles in allem bedanke ich mich bei den fleißigen Schreibern. Meine Ausgangsproblematik wurde für mich ausreichend behandelt. Eine weitere Diskussion möchte ich natürlich keinenfalls unterbinden und ich würde sie in jedem Fall weiter verfolgen.

          Kommentar


          • #35
            Aufjedenfall ein Vorteil, allerdings kein "direkter Vorteil" aus der physikalischen Trennung?! Diesen Vorteil würde ich dem als API gestalteten Backend zuschreiben.
            Ah, jo jetzt weiß ich wieder warum ich hier zuerst nichts geschrieben hatte

            Zur Trennung von Backend und Frontend auf verschiedene Server gibt es glaube ich wirklich nicht soo viel zu sagen, da wird es auf die verschiedenen Konfigurationsmöglichkeiten mit der Hardware hinaus laufen.

            Ansonsten steigt die Verfügbarkeit des Services, sobald mehr als je ein Frontend- und ein Backend-Server im Einsatz sind.
            Bei nur einem Frontend- und nur einem Backend-Server ist die Verfügbarkeit geringer als wenn beide Systeme auf dem gleichen Server laufen würden.

            Das Datenbankhandling zwischen den verschiedenen Backend-Servern wird komplizierter, denke ich... hab damit keine Erfahrung.
            [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
            [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

            Kommentar


            • #36
              Zitat von lottikarotti Beitrag anzeigen
              VPh es geht tomBuilder wohl darum dass nicht *eindeutig* beschrieben wurde, dass es sich bei dem "Frontend" um eine reine JS-basierte SPA handelt die statisch ausgeliefert wird und nur noch mit einer API (Backend) kommuniziert.
              Nein, es ging darum scheinbare unmöglichkeiten zu hinterfragen; macht nicht, wenn Du sowas nicht erkennen willst.

              Kommentar


              • #37
                Ich schlage vor, dass du mal ausführlicher schreibst worauf du hinaus willst anstatt nur im einzelnen Satz Andeutungen zu machen.
                macht nicht, wenn Du sowas nicht erkennen willst.
                Bist du zu oft gegen die Glastür gelaufen oder warum bist du heute so bockig?
                [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
                [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

                Kommentar


                • #38
                  Zitat von tomBuilder Beitrag anzeigen
                  Nein, es ging darum scheinbare unmöglichkeiten zu hinterfragen; macht nicht, wenn Du sowas nicht erkennen willst.
                  Sorry Kumpel, aber du bekommst kaum einen verständlichen Satz formuliert und erwartest nun dass wir (oder ich) irgendwas in deinen Aussagen erkennen? Wenn du Fragen stellen willst, dann stelle sie doch einfach. Und unterlasse diese unterschwelligen Beleidigungen. Das ist Kinderkacke.
                  [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                  Kommentar


                  • #39
                    Zitat von VPh Beitrag anzeigen
                    Ich schlage vor, dass du mal ausführlicher schreibst worauf du hinaus willst anstatt nur im einzelnen Satz Andeutungen zu machen.

                    Bist du zu oft gegen die Glastür gelaufen oder warum bist du heute so bockig?
                    HAb ich hab ich,
                    nur das erklären ist wohl gescheitert.
                    Gescheiterte Modelle sollte mann nicht zu häufig wiederhohlen.

                    . Und unterlasse diese unterschwelligen Beleidigungen. Das ist Kinderkacke.
                    Ich habe und wollte Dich nicht beleidigen. Ich bitte Dich zukünftig die selben Samthandschuhe anzuziehen, welche Du von anderen verlangst.

                    Kommentar


                    • #40
                      Zitat von tomBuilder Beitrag anzeigen
                      HAb ich hab ich,
                      nur das erklären ist wohl gescheitert.
                      In der Tat. Was du bspw. damit ausdrücken wolltest ist mir immer noch ein Rätsel (Zitat): "Ich finde es eine Ausblenden der Middleware in dem Kontext suboptimal.".

                      Zitat von tomBuilder Beitrag anzeigen
                      Gescheiterte Modelle sollte mann nicht zu häufig wiederhohlen.
                      Du gibst schon wieder den Foren-Goethe. Ich weiß ehrlich gesagt nicht welchen Zweck das erfüllen soll.

                      Zitat von tomBuilder Beitrag anzeigen
                      Ich habe und wollte Dich nicht beleidigen.
                      Dann lass deine nett gemeinten Nebensätze à la "aber macht nichts mzuss Dir nicht klar sein" doch einfach stecken?

                      Zitat von tomBuilder Beitrag anzeigen
                      Ich bitte Dich zukünftig die selben Samthandschuhe anzuziehen, welche Du von anderen verlangst.
                      Das habe ich nicht verlangt. Aber macht nichts, muss dir nicht klar sein

                      Wie dem auch sei, das artet nun zu sehr aus und ich bin aus diesem Teil der Diskussion raus.
                      [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                      Kommentar


                      • #41
                        Bis vor kurzem war der Thread ganz interessant.

                        Zitat von lottikarotti Beitrag anzeigen
                        Wie dem auch sei, das artet nun zu sehr aus und ich bin aus diesem Teil der Diskussion raus.
                        Können das die anderen bitte nachmachen und die Diskussion wieder auf den sachlichen Boden holen? Könnt euch ja mal per PN auf einen virtuellen Kaffee treffen und sowas klären, falls nochwas offen ist.

                        Danke euch!
                        The string "()()" is not palindrom but the String "())(" is.

                        Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                        PHP.de Wissenssammlung | Kein Support per PN

                        Kommentar

                        Lädt...
                        X