Ankündigung

Einklappen
Keine Ankündigung bisher.

(java vs php) + frameworks

Einklappen

Neue Werbung 2019

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

  • #16
    Zitat von BLU Beitrag anzeigen
    Hallo,

    bei einem privaten Projekt spricht alleine schon deshalb was für PHP, weil man bei den gängigen Hostern keine günstigen Angebote, auf denen du Java-Web-Applikationen zum Laufen bekommst. Ein Tomcat, JBoss,... findest du da nirgends - oder ich habe bisher einfach immer bei den falschen Anbietern geschaut.
    Das Problem sehe ich inzwischen nicht mehr so. Wenn man nach "vserver", "cloud server" oder ähnliches sucht kann man da schon gute Angebote finden, auch kleinere Pakete für ~5€ pro Monat
    [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


    • #17
      Zitat von VPh Beitrag anzeigen

      Das Problem sehe ich inzwischen nicht mehr so. Wenn man nach "vserver", "cloud server" oder ähnliches sucht kann man da schon gute Angebote finden, auch kleinere Pakete für ~5€ pro Monat
      Wobei du da den kompletten Administrationsaufwand eines Servers hast. Kann ziemlich schnell in die Hose gehen wenn man sich nicht drum kümmert.
      Ein Shared Hosting Angebot bei dem sich der Hoster (hoffentlich) darum kümmert ist da schon besser und sicherer.
      "Software is like Sex, it's best if it's free." - Linus Torvalds

      Kommentar


      • #18
        Zitat von knotenpunkt Beitrag anzeigen
        [...]
        In den Universitäten wird PHP immer belächelt und auch so habe ich schon oft gehört, man soll für enterprise Applikationen lieber JAVA verwenden.
        Genau aus diesem Grund setzt Facebook auf PHP (HHVM) und Netflix auf Java. Oder auch nicht... Das Argument ist schwach. Es soll um den Anwendungszweck gehen und nicht um "Enterprise" oder was auch immer. Manchmal ist es auch einfach historisch. Im Web ist PHP sicher state-of-the-art. Soll es Kompatibel sein über Plattformen, dann Java (oder .Net Core?). Soll es fancy und schnell sein, dann vielleicht Go.

        Java muss nicht jedes mal übersetzt werden und ich kann festen State behalten.
        Um etwas ins Software-Design einzusteigen: Wenn du im Web-Umfeld "State" hast, ist etwas falsch. Ein Request ist stateless. State wird bei jedem Request aufgebaut und am Ende von jedem Request verworfen.

        Ich würde behaupten dass Java insgesamt performanter ist, also geschwindigkeitstechnisch, gegenüber PHP.
        Das hätte ich bis zu PHP 5.X behauptet. Jetzt aber mit HHVM und PHP 7....... ? -> vllt. wisst ihr dazu ja mehr.
        Sie weltbekannte Beispiele. Performance lässt sich nicht auf die Sprache abwälzen.

        Agenommen ich setze Frameworks ein, oder habe auch so einiges an State. in PHP muss für jeden Request, das System sozusagen neu zusammengesetzt werden. (glaube in Laravel über 50 DIs, die jedes mal "ge-newt" und verschraubt werden müssen)
        In Java, einmal zum Start und dann nie wieder........
        Symonfy erstellt eine Bootstrap-Datei, die anstelle der Source in Produktiven Environments geladen wird und alle Klassen enthält (so ungefähr). Der komplette DI-Container ist im Produktiven Environment statisch. Also ist dieses Argument nichtig. Zudem gibt es in PHP gute Cache-Strategien (APC, OPCache), die den Speed stark erhöhen.

        [...]In Java gibts ja das Framework Spring (Boot), ein sehr mächtiges Framework......... bin mir nicht sicher ob ich das überhaupt einsetzen möchte, weil es fast zu komplex ist um zu verstehen was das alles unter der Haube macht^^
        Nachteil an dem Framework sind die langen Startzeiten. Möchte ich das neue Projekt auf ner Art Mikroarchitektur aufbauen und das ganze in Containern deployen, so benötigt jeder gestartete Container über ne halbe Minute Startzeit, was bei automatischen Loadbalancern/Container-Nachladeeinheiten sich eher negativ auswirkt------> siehe google Cloud
        Dann mach doch einfach Serverless. Dann ist die Bootzeit ~0. Ich bezweifle, dass die Startzeit von 0.5min bei einem Microservice geschäftskritisch sein wird.

        Zum Design:
        Ich würde auf sogenannte transactionale Scripts (prozeduraler Stil setzen und bin so nicht auf das "pseudo-oo" angewiesen, was meiner Meinung nach nicht wirklich viel Sinn ergibt (siehe hierzu einen anderen Thread von mir))
        Das Argument macht irgendwie deine ganzen (angeblichen) Qualitäten nichtig...

        [/quote]

        Als Datenbank/Datenbanken MySql + irgendwelche NoSql-Datenbanken und dann noch Memcache, für gecachten State, der dann von mehreren "Serverinstanzen" verwendet werden kann
        Ähm... nein? Shared State über mehrere Instanzen? Ähm... Bitte nicht.
        [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

        Kommentar


        • #19
          so erstmal danke für die zahlreichen antworten,

          @JaMA

          Punkt 4 ist nicht ganz richtig. Du hast damit recht, dass der "compilierte" Code gecached wird. Aber dass der Programmstate gecached wird, wäre mir neu, es sei denn derWunner hat mit seinem InterpreterCache recht. Aber selbst wenn es sowas gäbe, müsste man das als Programmierer selbst im Programmcode beachten.
          Vllt. ist das ganze ja trotzdem schneller?, vermutlich nicht!....... Es sei denn man verzichtet auf komplexe Objektverschraubungen bei jedem neuen Request -> guter prozeduraler Stil und kein pseudo-oo mit DI von Services
          Aber ja mich würde interessieren, ob PHP hier schneller performt als JAVA, wenn man einfach programmiert.


          Zum Thema Application-Server: HHVM ist doch sowas?
          das CGI-Zeugs ist definitiv das was xm32 geschrieben hat, ein Prozess-spwaning-(Desaster)....... also nicht wirklich zu gebrauchen.


          @xm32:

          Mit Spring im Allgemeinen habe ich selbst noch nicht gearbeitet, Spring Boot ist gut geeignet für den Einstieg, aber sobald du Sonderwünsche hast, musste doch wieder die romanartigen Dokumentationen vom '"gesamten" Spring durchlesen.
          Laravel, Symphony ist da wesentlich einfacher^^

          Zum Thma, Schnittstellen-Beschleunigen: Ja ich habe bereits an Thrift von Facebook gedacht, aber mir würde schon folgender Ansatz ausreichen: bspw. die ersten 3 zeichen codieren den befehl dann kommt ein trennzeichen und so weiter, also

          057|b|username|blob <- wäre wesentlich schneller zu parsen und auch zu preparsen, also wenn ober liegende schichten sich nur für den befehl also nur 057 interessieren.
          So ein sonderwusch bedeutet ich muss ziemlich tief in das framework eingreifen oder am besten selbst ein kleines schreiben. ich glaube Zweiteres geht wesentlich schneller von der Hand. -> in der JAVA-Welt nen schnellen Webserver (Jersey) verwenden und auf Spring im allgemeinen verzichten.


          Zum Thema 0,5min Startzeit:

          Es war so gemeint, wenn aktuell 20 Instanzen laufen, die User-Request-Rate nimmt zu......... -> es wird noch eine weitere instanz benötigt, dann sollte die schon instant da sein, vor allem weil bei Google der user der auf die neue instanz geroutet wird, so erst mal ne halbe minute warten darf, ist zwar auch anders lösbar, aber in der Google App Engine nicht.

          Diejenigen von euch die noch der Meinung sind, dass man PHP programmiert weil man kostengünstig an entsprechende Hosting-Angebote kommt:
          Ich würde heutzutage auf keinen freien Hoster mehr setzen: wo ich nur PHP ausführen kann. Sprich mindestens V-Server, Root-Server, oder eben cloud.
          Bei Google ist neben PHP, JAVA auch noch Go und nodeJS und anders möglich: https://cloud.google.com/appengine/?hl=de

          Ist kostenfrei für eine Instanz

          Hier gleich mal die Frage, wenn ich so die Preise bei Google vergleiche und das was ich da bekomme, da fahre ich doch mit nem Strato-Server wesentlich günstiger. Ok bei Google bekommt man routing, firewall, loadbalancing, Memcachce und alles mögliche mitgeliefert....... Aber ich finde die preise schon ziemlich happig, oder wie seht ihr das?.... -> im Google Cloud Preisrechner könnt ihr euch das mal anschauen^^



          So aber jetzt wieder zurück zum Thema:

          Was mich eigentlich interessiert ist doch das folgende:
          performance+Ressourcen:

          Da ich jetzt schon länger nichts mehr mit PHP gemacht habe und so noch nicht wirklich in den Genuss von PHP 7 gekommen bin eben auch diese Nachfragen:

          fahre ich performancetechnisch mit php7 hhvm besser , als mit JAVA, wenn ich sehr abgespeckt programmiere, also auf frameworks verzichte (auf beiden seiten!)
          Ram-Technisch definitiv, das ist ne katastrophe bei JAVA

          Was mir an Java eben gut gefällt: die Typsicherheit, das Multithreading und eben dass es ein zusammengeschnürtes Programm ist und keine Scripte
          Was halt gegen Java hier spricht, ist, dass man für gleiche Funktionalität gut ein vielfaches an Codezeilen benötigt wie in PHP


          Dass solche Argumente wie Performance nicht so wichtig sind, sehe ich nicht ganz: Es macht schon einen Unterschied ob ich nacher 20 Root-Server benötige oder 60^^ (Analog Cloud-instanzen)
          Also zumindest für meinen Geldbeutel^^

          Klar hängt viel von der Programmierung ab (hier bin ich sogar mit der prozeduralen Programmierung besser dran!), aber auch ein gewisser Teil von der Sprache




          So jetzt noch kurz zum Thema pseudo-oo-code:
          Ich habe hier im Forum schon vor längerer Zeit mal diesen Thread hier eröffnet: https://www.php.de/forum/webentwickl...al-programming

          ich denke man muss hier etwas mehr differenzieren was OO ist:

          es gibt die OO-prinzipien: also die SOLID-prinzipen....... ich würde diese jetzt nicht nur aufs reine OO beschränken, sondern benenne die hiermit in gute-programmier-prinzipien um.

          Jetzt gibt es noch das OO-Denkmuster:
          Dazu habe ich mal ne gute Graphik gefunden:

          im prozeduralen fliessen Daten/Informationen hin und her also durch die Programmwelt
          im OO gibt es feste Blöcke (Objekte), diese spannen die Programmlandschaft auf. Und diese Blöcke kommunizieren via Messages. Man kann diese Programmlandschaft gut testen, aber leider nur mit sehr viel overhead erweitern, sowohl programmiertechnisch, als auch mehr oder weniger performance-beibehaltend (kommt drauf an wie gut die compiler-optimizer arbeiten^^)
          Das wäre für mich RICHTIGES OO
          Ob das so sinnvoll ist, ist eine andere Frage.

          Und jetzt gibt es noch das pesudo-OO:

          Das sind Programmlandschaften mit vielen Services:
          Die Services kapseln sozusagen prozeduralen Code in sich und sind darüberhinaus noch leicht konfigurierbar, unter anderem mit den Stärken der SOLID-prinzipien:
          Also ich baue sozuagen meine Programmlandschaft OO mittels Services auf, um dann später mit diesen Services wieder prozeduralem Denkstil nachkommen zu können^^


          Und da die ganzen Frameworks meist DI (dependency injection), was perfekt zu Services passt , im Kern umsetzen, sind das hauptsächlich pseudo-oo frameworks^^

          In einer perfekten OO-Welt benötigt man kein DI!, (DI != strategy-pattern, auch wenn sehr ähnlich!)

          So jetzt schreibe ich in dem verlinkten Thread, dass es Code gibt, den man nicht so genau einer Klasse zuordnen kann....... hm wäre ja perfekt für einen Service also.
          Falsch! Hier würde ich dann eine Sachbearbeiter-Klasse (ja ist ähnlich wie ein Service), gebunden an seine "Unterklassen" einführen. So wäre diese Klasse teil der Objektwelt im speziellen und nicht als externer Service zu sehen.
          Das wäre OO. Sinnvoll? Meiner Meinung nach nicht!


          Und auch der Meinung vieler andere nicht! Sieht man ja an den frameworks!
          Man muss aber auch fairerweise zugeben dass das nur pseudo-oo ist und eher dem prozeduralen stil folgt: Was ich auch besser finde!

          Würde ich mein nächstes Projekt in Java umsetzen, dann müsste ich auch auf pseudo-oo zurückgreifen........ ich habe in Java ja nur Klassen zur Verfügung^^
          Aber das wäre nicht schlimm, weil ja der Applikation-Server nur einmal gestartet wird, abgesehen von skalierbaren Cloud-Instanzen


          zum thema transactionale Scripts: https://martinfowler.com/eaaCatalog/...ionScript.html
          Guter Prozeduraler Code performt sehr gut und ist auch gut erweiterbar!
          Vor allem bei den mikorservices wird ja auch wieder auf SOA gesetzt!

          Falls mir aber einer der OO-Enthusiasten mal erklären möchte, wo mein Fehler im Denken liegt, dann gerne her damit: Würde mich auch mal persönlich mit euch treffen^^
          Leider werden an den Universitäten gute Programmierstile kaum gelehrt, da bin ich hier definitiv besser bedient^^


          So da es jetzt kurz nach 4 uhr nachts ist, beende ich das hiermit mal



          LG knotenpunkt

          PS: vllt. sollte ich das ganze auch einfach in C++ schreiben, ich benötige ja ausser Datenbank-libs Webserver-libs, eigentlich nicht viel mehr weiteres^^

          Kommentar


          • #20
            ChristianK

            Um etwas ins Software-Design einzusteigen: Wenn du im Web-Umfeld "State" hast, ist etwas falsch.
            Das ist schon etwas sehr allgemein, oder? Was ist mit persistenten Datenbankverbindungen? Caches? Sessions?

            Shared State über mehrere Instanzen? Ähm... Bitte nicht.
            Dasselbe in grün - Es gibt natürlich etliche Dinge, bei denen man das nicht machen sollte, aber das grundsätzlich abzulehnen, ist schon der falsche Ansatz.

            knotenpunkt

            das CGI-Zeugs ist definitiv das was xm32 geschrieben hat, ein Prozess-spwaning-(Desaster)....... also nicht wirklich zu gebrauchen.
            Wieso "Zeugs"? Hast Du Dir Fast-CGI schon mal angeschaut?

            057|b|username|blob <- wäre wesentlich schneller zu parsen und auch zu preparsen, also wenn ober liegende schichten sich nur für den befehl also nur 057 interessieren.
            So ein sonderwusch bedeutet ich muss ziemlich tief in das framework eingreifen oder am besten selbst ein kleines schreiben.
            Aber erkennst Du nicht das Problem dabei? Wie viel schneller als ein JSON oder gar Thrift-Parser willst Du Dein Framework machen? Ist es das wert, sich den Aufwand zu machen?

            Es macht schon einen Unterschied ob ich nacher 20 Root-Server benötige oder 60^^ (Analog Cloud-instanzen)
            Ich schmeiß mich weg Da ist es wieder, das Performance-Argument. Was, in Gottes Namen, willst Du bauen, dass Du allein 20 Root-Server benötigst? Entwickle doch erstmal sauber Deine Anwendung, bevor Du solch große Brötchen backst. Du sattelst das Pferd von hinten auf.



            Und auch der Meinung vieler andere nicht! Sieht man ja an den frameworks!
            Man muss aber auch fairerweise zugeben dass das nur pseudo-oo ist und eher dem prozeduralen stil folgt: Was ich auch besser finde!
            Ich würde lachen, wenn es nicht so traurig ist. Zu Deinen OO-"Gedanken": Ein großer Teil Deiner Aussagen sind schlicht und einfach falsch. Und wenn jemand ein ganzes Paradigma aufgrund falscher Annahmen ablehnt, wird der auch im prozeduralen Stil keine gute Software entwickeln.


            zum thema transactionale Scripts: https://martinfowler.com/eaaCatalog/...ionScript.html
            Du missinterpretierst die Aussage von Martin Fowler und biegst sie so um, dass sie Dir in den Kram passt. Ich erkläre Dir gern Deinen Irrtum, wenn Du magst. Von mir aus auch per PN. Aber treffen muss ich mich nicht unbedingt

            Guter Prozeduraler Code performt sehr gut und ist auch gut erweiterbar!
            Was auch auf OO zutrifft.

            Zu guter Letzt: Es hat nichts mit Enthusiamus zu tun, wenn jemand etwas vertritt, das sich bewährt hat. Es ist einfach eine Frage des Anwendungsfalls, was sich besser eignet. Bei Deiner Argumentation OO <-> Prozedural fehlt die Differenzierung und Du scheinst eh schon vom _rein_ prozeduralen Konzept. überzeugt zu sein. Willst Du wirklich eine Diskussion darüber oder willst Du nur eine Bestätigung?

            Vor allem bei den mikorservices wird ja auch wieder auf SOA gesetzt!
            Das erinnert mich ganz stark an den Flachwitz "Cola schmeckt besser als aus dem Glas."

            PS: vllt. sollte ich das ganze auch einfach in C++ schreiben, ich benötige ja ausser Datenbank-libs Webserver-libs, eigentlich nicht viel mehr weiteres^^
            Und alles from Scratch selber schreiben?

            Zum Thema Uni: In der Tat wird dort eher akademisch und nicht zielorientiert unterrichtet. Vielleicht fehlt Dir dieser Aspekt einfach noch - Nicht abwertend gemeint

            Meine Prophezeiung: Du wirst am Ende an Deinem "eigenen Framework" schrauben, weil die existierenden Lösungen zu aufgebläht sind - In dem Gedanken, später das gefeierte Quasi-Standard-Framework entwickelt zu haben. Dabei wirst Du vieles lernen, aber Deiner eigentlichen Applikation nicht näher kommen. Nach ein paar Monaten/ca. einem Jahr wird Dir dann auffallen, das Du von vier Rädern zehn neu erfunden hast und es alles schon gibt - Und zwar viel durchdachter.

            Kommentar


            • #21
              Da die Zitieren-Funktion hier im Forum recht mühsam ist:

              Bzgl. State:
              Ja, ich gebe zu, die Aussage ist verallgemeinert. Allerdings sprichst du z.B. mit Persistenten DB-Verbindungen eine Infrastruktur-Sache an und keine Request-Sache. Die DB-Verbindung hat keinen State bzgl. des Request (ausser du eröffnest für einen User X eine Verbindung und cachst diese bis zum nächsten Aufruf). Und hier zeigt die Erfahrung: die Connection zur DB ist schneller aufgebaut aus der Cache entwickelt ist .

              Zudem ist z.B. REST explizit Stateless.

              Und zum Beispiel mit dem Shared State über mehrere Server: Es mag vielleicht Situationen geben, wo dies ein guter Ansatz ist. Ich wage allerdings zu behaupten, dass die Synchronisation dieses States um einiges komplexer ist (insbesondere bei höherer Last), als du dir das mit dieser knappen Aussage vorgestellt hast.

              Bzgl. Root-Server:
              Wenn man schon darüber diskutieren möchte, verwendet doch korrekte Begriffe. Es ist ein Dedicated-Server oder ein Server mit Root-Access. Es gibt ~13 Root-Server auf dieser Welt, und niemand von uns hat einen solchen zur Hand: http://www.root-servers.org/
              [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

              Kommentar


              • #22
                ausser du eröffnest für einen User X eine Verbindung und cachst diese bis zum nächsten Aufruf). Und hier zeigt die Erfahrung: die Connection zur DB ist schneller aufgebaut aus der Cache entwickelt ist
                Ich meinte nicht, diese beiden Sachen zu kombinieren bei php kann man auch gar keine Resourcen cachen
                Allerdings nur bei Sprachen wie php. Wenn Du integrierte Applikationen verwendest, die nicht jedes Mal einen neuen Prozess verwenden, können Connection-Pools etc. offen bleiben.

                Und zum Beispiel mit dem Shared State über mehrere Server: Es mag vielleicht Situationen geben, wo dies ein guter Ansatz ist. Ich wage allerdings zu behaupten, dass die Synchronisation dieses States um einiges komplexer ist (insbesondere bei höherer Last), als du dir das mit dieser knappen Aussage vorgestellt hast.
                Geteilter Memcache z. B.? Instanz-übergreifende Sessions?

                Einen State kann es auch bei REST geben: Denk an einen Prozess, der angestoßen wird (Auch, wenn das jetzt etwas konstruiert klingt). Es ist immer die Frage, was man als State sieht und wie idealisiert etwas ist.

                knotenpunkt Sage mal: Meinst Du vielleicht funktional statt prozedural.

                Kommentar


                • #23
                  moin moin,

                  Wieso "Zeugs"? Hast Du Dir Fast-CGI schon mal angeschaut?
                  Nein, das nicht wirklich


                  Aber erkennst Du nicht das Problem dabei? Wie viel schneller als ein JSON oder gar Thrift-Parser willst Du Dein Framework machen? Ist es das wert, sich den Aufwand zu machen?
                  Naja in dem Fall geht es nicht um Wieviel sondern um das Dass! Ich glaube der Aufwand würde darin bestehen, ein bestehendes Framework umzubiegen, ein eigenes wäre da wesentlich schneller und auch mit sehr wenig Aufwand programmiert
                  Ich habe ja zu Beginn, kurz den Request-Lifecycle skizziert. Soviel Aufwand ist das doch nicht. Eine handvoll Klassen und schon funktioniert das Ganze und zwar so, wie man es sich selbst vorstellt^^


                  Ich schmeiß mich weg Da ist es wieder, das Performance-Argument. Was, in Gottes Namen, willst Du bauen, dass Du allein 20 Root-Server benötigst? Entwickle doch erstmal sauber Deine Anwendung, bevor Du solch große Brötchen backst. Du sattelst das Pferd von hinten auf.
                  Auch wenn ich eigentlich 20tsd-60tsd Server gemeint habe....... es kann doch auch zu Beginn nicht schaden, Wert auf performance zu legen. So komme ich vllt. später auch mit 2 statt 6 servern aus.
                  Also auch ganz Allgemein - wenn man es besser weiß - warum sollte ich meine Anwendung inperformant programmieren?


                  Ich würde lachen, wenn es nicht so traurig ist. Zu Deinen OO-"Gedanken": Ein großer Teil Deiner Aussagen sind schlicht und einfach falsch. Und wenn jemand ein ganzes Paradigma aufgrund falscher Annahmen ablehnt, wird der auch im prozeduralen Stil keine gute Software entwickeln.
                  Was auch auf OO zutrifft.

                  Zu guter Letzt: Es hat nichts mit Enthusiamus zu tun, wenn jemand etwas vertritt, das sich bewährt hat. Es ist einfach eine Frage des Anwendungsfalls, was sich besser eignet. Bei Deiner Argumentation OO <-> Prozedural fehlt die Differenzierung und Du scheinst eh schon vom _rein_ prozeduralen Konzept. überzeugt zu sein. Willst Du wirklich eine Diskussion darüber oder willst Du nur eine Bestätigung?

                  Dann wäre ich daran interessiert, was an den Annahmen so falsch ist. In der Theorie suche ich tatsächlich nach einer Bestätigung. In der Praxis, aber auch gerne eine Diskussion. Wie du ja selbst geschrieben hast, ist das OO ja bewährt. So falsch kann es ja so nicht sein. Also erklär mal.

                  knotenpunkt Sage mal: Meinst Du vielleicht funktional statt prozedural.
                  Wie kommst du auf funktional?
                  Wenn ich in Haskell oder in Scala Funktionen schreibe, die intern keinen state verwenden, also auch nicht im Algorithmus selbst, dann wäre es funktional.



                  Zum Thema stateless noch folgende Frage:
                  JWT-Token machen ja tatsächlich nur dann Sinn, wenn ich später nicht einen shared-Memcache (shared zwischen allen Aktoren/ Mikroservices) darin prüfe ob der Token noch valide ist.
                  Wie macht das Facebook?
                  Klar der Token hat meist immer nur kurze Gültigkeitslaufzeiten von 10min? (oder länger bei Facebook?)
                  Aber wenn ich mich auslogge, Passwort ändere (zumindest war das vor 3Jahren noch so), oder eine Facebook-App deaktiviere, dann sind entsprechende Tokens sofort invalide.
                  Sprich sendet Facebook in dem Fall (im übrigen sehr unwahrscheinlichen Fall, weil wann deaktiviert schonmal jemand eine APP) an ALLE Instanzen bzw. an die shared Memchaches verschiedener Instanzgruppen einen Invalidate-Befehl?
                  Der Vorteil der JWT-Token liegt also darin, nicht jedes mal eine zentrale Datenbank anzupingen, sondern nur im Ausnahmefall eine Benachrichtigung von zentraler Stelle zu bekommen, sehe ich das richtig?

                  (Habe hier jetzt nicht so exakt zwischen den User-Session-Tokens, Short-Lived and long-lived App-Tokens differenziert, sollte aber für meine Fragestellung jetzt auch nicht relevant sein)



                  lg knotenpunkt

                  Kommentar


                  • #24
                    warum sollte ich meine Anwendung inperformant programmieren?
                    Sollst Du ja gar nicht Aber das Problem ist, dass Du nicht eine Frage über Struktur, Best Practises usw. gestellt hast, sondern komplett das Augenmerk auf Performance legst. Und wenn Du schreibst, dass Du sogar Low-Level-Komponenten selber schreiben willst, nur um das letzte Quentchen Leistung herauszukitzeln, anstatt das Ziel im Auge zu behalten.
                    Hier gleich mal die Frage, wenn ich so die Preise bei Google vergleiche und das was ich da bekomme, da fahre ich doch mit nem Strato-Server wesentlich günstiger.
                    Genau dasselbe: Du kümmerst Dich um Sachen, die momentan nicht annähernd relevant sind. Wenn Du eine so krasse Applikation erstellen willst, dann spielt es doch keine Rolle, wo sie am Ende gehostet wird.

                    20tsd-60tsd Server gemeint habe
                    Im Internet ist es ja immer schwierig, das "herauszuhören", daher: Ist das jetzt ironisch gemeint?

                    Wie kommst du auf funktional?
                    Weil ich nicht glaube, dass Du eine rein funktionale Applikation warten möchtest. Java fällt dann flach. Eines der Kernkonzepte dieser Sprache ist OO.

                    zum thema transactionale Scripts: https://martinfowler.com/eaaCatalog/...ionScript.html
                    Der Artikel sagt, dass es Business-Cases gibt, die in einer Transaktion abgearbeitet werden sollen - Von OO oder prozedural oder wie auch immer steht da kein Wort.


                    im prozeduralen fliessen Daten/Informationen hin und her also durch die Programmwelt
                    Du erkennst schon an der Schilderung das Problem, dass Du haben wirst?

                    Und diese Blöcke kommunizieren via Messages
                    Blöcke ist das falsche Wort. Und es gibt etliche Wege, wie die miteinander kommunizieren können.

                    aber leider nur mit sehr viel overhead erweitern, sowohl programmiertechnisch, als auch mehr oder weniger performance-beibehaltend (kommt drauf an wie gut die compiler-optimizer arbeiten^^)
                    Wie kommst Du denn darauf?

                    Das wäre für mich RICHTIGES OO
                    SO kann OO aussehen, aber wo ist das Problem?

                    Und jetzt gibt es noch das pesudo-OO. Das sind Programmlandschaften mit vielen Services:
                    Die Services kapseln sozusagen prozeduralen Code in sich und sind darüberhinaus noch leicht konfigurierbar, unter anderem mit den Stärken der SOLID-prinzipien:
                    Also ich baue sozuagen meine Programmlandschaft OO mittels Services auf, um dann später mit diesen Services wieder prozeduralem Denkstil nachkommen zu können^^
                    Klar - Am Ende ist die Implentierung einer Logik in einer imperativen Sprache immer prozedural. Es geht ja um die Kapselung der Business-Logik.


                    Und da die ganzen Frameworks meist DI (dependency injection), was perfekt zu Services passt , im Kern umsetzen, sind das hauptsächlich pseudo-oo frameworks^^
                    In einer perfekten OO-Welt benötigt man kein DI!, (DI != strategy-pattern, auch wenn sehr ähnlich!)
                    Du verwechselst DI mit DI-Containern.

                    Hier würde ich dann eine Sachbearbeiter-Klasse (ja ist ähnlich wie ein Service), gebunden an seine "Unterklassen" einführen. So wäre diese Klasse teil der Objektwelt im speziellen und nicht als externer Service zu sehen.
                    Welches Problem beschreibst Du hier?

                    Das wäre OO. Sinnvoll? Meiner Meinung nach nicht!
                    Völlig undifferenzierte Aussage

                    Kommentar


                    • #25
                      Nur mal eine Anmerkung in die Runde, aber geht der Trend nicht langsam weg von Mikro-Services, weil viele gleich blind auf diesen Hype-Zug aufgesprungen sind und irgendwann gemerkt haben, dass das nicht nur Vor-, sondern auch Nachteile hat?

                      Kommentar


                      • #26
                        Zitat von hellbringer Beitrag anzeigen
                        Nur mal eine Anmerkung in die Runde, aber geht der Trend nicht langsam weg von Mikro-Services, weil viele gleich blind auf diesen Hype-Zug aufgesprungen sind und irgendwann gemerkt haben, dass das nicht nur Vor-, sondern auch Nachteile hat?
                        Obwohl ich finde dass Microservices (oder SOA im Allgemeinen) eine sehr gute Sache sind, bringen sie extrem viel Komplexität mit, wenn es in den High/Large-Scale Bereich geht. Diese Komplexität wird oftmals unterschätzt und kann nur durch den korrekten Einsatz vielfältiger Tools sinnvoll kontrolliert werden (ich kann hierzu die Netflix-Talks zum Thema sehr empfehlen). Wir betreiben da eher einen progressiven Ansatz und packen nur das in Microservices was aus praktischer Sicht für uns Sinn macht (z.B. wenn Skalierung mit unterschiedlichen Performance-Profilen notwendig ist). Ich denke man sollte eine Lösung niemals blind 1:1 adaptieren.
                        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                        Kommentar


                        • #27
                          Zitat von knotenpunkt Beitrag anzeigen
                          Also auch ganz Allgemein - wenn man es besser weiß - warum sollte ich meine Anwendung inperformant programmieren?
                          Damit du überhaupt eine Anwendung hast? Das Problem ist du weißt es ebend nicht besser. Du suchst Lösungen für Probleme die noch nicht existieren und dich kein Schritt näher an dein eigentliches Ziel bringen. Das ist ein guter Weg in Richtung 0 Server.
                          Nimm die Technologie mit der du zurecht kommst. Versuch die Anwendung so zu gestallten, dass sie über mehrere Server skaliert werden kann und bring das Ding zum laufen. Danach hast du immer noch die Möglichkeit an der Performance zu schrauben, aber mit dem Vorteil, dass du das Ziel gerichtet machen kannst.

                          Kommentar


                          • #28
                            Zitat von knotenpunkt Beitrag anzeigen
                            Punkt 4 ist nicht ganz richtig. Du hast damit recht, dass der "compilierte" Code gecached wird. Aber dass der Programmstate gecached wird, wäre mir neu, es sei denn derWunner hat mit seinem InterpreterCache recht. Aber selbst wenn es sowas gäbe, müsste man das als Programmierer selbst im Programmcode beachten.
                            Bei Java wird der "Programmstate" auch nicht gecached.

                            Zitat von knotenpunkt Beitrag anzeigen
                            Es sei denn man verzichtet auf komplexe Objektverschraubungen bei jedem neuen Request -> guter prozeduraler Stil und kein pseudo-oo mit DI von Services
                            Zitat von knotenpunkt Beitrag anzeigen
                            Man muss aber auch fairerweise zugeben dass das nur pseudo-oo ist und eher dem prozeduralen stil folgt: Was ich auch besser finde!
                            Sorry, aber mit so einem Geschwätz über "pseudo-oo" diffamierst du dich selber.

                            Und da du die Finger nicht von der Performance lassen kannst:
                            Mit deinem selbstgeschrieben Parser wirst du langsamer sein als bestehende Lösungen. Ressourcen wirst du sowieso noch viel mehr benötigen.
                            Aus dem einfachen Grund, dass bestehende Parser aufwendig optimiert wurden.
                            "Software is like Sex, it's best if it's free." - Linus Torvalds

                            Kommentar


                            • #29
                              aber geht der Trend nicht langsam weg von Mikro-Services, weil viele gleich blind auf diesen Hype-Zug aufgesprungen sind
                              Weg nicht, aber die Anwendung wird konsolidierter. Man muss auch zwischen den Spielarten unterscheiden. Was viele als Micro-Service bezeichnen, ist eigentlich ein self contained system.

                              Am Ende macht's wie immer die korrekte Anwendung der verfügbaren Optionen.

                              Kommentar


                              • #30
                                Zitat von knotenpunkt Beitrag anzeigen
                                Also ich baue sozuagen meine Programmlandschaft OO mittels Services auf, um dann später mit diesen Services wieder prozeduralem Denkstil nachkommen zu können^^
                                Ich beschränke mich jetzt einfach mal nur auf diese eine Aussage und auf die Idee dahinter.
                                Spiele ich das mal mit uns stimme dieser Aussage zu. Um hier den überlegenden Vorteil von OO zu erkennen brauchen wir DI - und da passt folgendes zu:

                                Zitat von knotenpunkt Beitrag anzeigen
                                Und da die ganzen Frameworks meist DI (dependency injection), was perfekt zu Services passt , im Kern umsetzen, sind das hauptsächlich pseudo-oo frameworks^^
                                ... im Kern DI umsetzen. Sicher, dass du nicht vom Service-Locator sprichst?
                                DI (wobei ich mich dabei hauptsächlich auf Constructor-Injection beschränke) ist doch einfach nur das Referenzieren von anderen Instanzen von Objekten, die eine bestimmte Form haben.
                                Und das ist doch genau der Punkt. Bei einem prozeduralen Programm habe ich überall statische Aufrufe zu meinen Funktionen drin. Wenn ich meine Umgebung für unterschiedliche Umgebungen konfigurieren will, dann stehe ich bei PP vor schwer lösbaren Problemen, das ich bei OO wesentlich leichter lösen kann. Bei OO brauche ich nur ein stabiles, durchdachtes Interface. Danach kann ich meine Services nach Bedarf austauschen. An zentraler Stelle, dank DI.

                                Ich habe dadurch auch noch einen anderen Vorteil. Denn für mich als Entwickler fühlt sich jedes einzelne Objekt an, wie ein kleines prozedurales Program. Ich habe in Objekten nämlich State. Wenn ich das mit PP nachbilden wollen würde, dann würde ich allen Prozeduren/Funktionen ständig wieder den State als Parameter durchreichen. Was für ein Quatsch, wenn meine Applikation das nicht zwingend so benötigt, was meiner Erfahrung nach praktisch nie der Fall ist. Methoden übergebe ich nur noch ein Minimum an Informationen. Informationen, die ich in den Layer in der Regel auch habe...
                                • Und in einem prozeduralen Programm mit globalem State zu arbeiten, haben die allermeisten Entwickler schon als ein großes Übel erkannt.
                                • Es gibt kein Autoloading für Funktionen. Alles immer Eager laden? Oh man...
                                • PP ist OOP mit wesentlich weniger Funktionsumfang.
                                • Mit PP hat man generell wesentlich(!) weniger Möglichkeiten, sein PHP-Programm statisch zu typisieren.
                                In funktionalen Sprachen arbeitet man zumeist auch mit Konzepten, die sehr OO-Ähnlich sind. Im Prinzip werden dort anonyme Funktionen rumgereicht, die den gewünschten State über mehrere Aufruf-Ebenen kapseln. Ansonsten wird dort wie in PP auch der State als Parameter an Funktionen übermittelt. Aber wesentlich intelligenter, als dies in PHP möglich wäre:
                                https://elixirschool.com/en/lessons/...pipe-operator/
                                https://medium.com/@darioghilardi/im...r-6acb07708b6e
                                https://hackernoon.com/a-free-introd...x-228d0e994fc1

                                Wenn du so sehr an prozeduraler Programmierung hängst, dann ist funktionale Programmierung bzw. Elixir in praktisch jeder Hinsicht das bessere Werkzeug für dich. Besonders im Hinblick auf Performance und Skalierbarkeit (Stichwort OTP).

                                “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

                                Kommentar

                                Lädt...
                                X