Py4Web

[DasIch]

@__blackjack__: Gibt es schon mit starlette, fastapi und co. die schon erwähnt wurden. Die konkurrieren aber im wesentlichen mit Flask und nicht mit Django. Django selbst hat aber auch schon rudimentären async support, der wird sicherlich auch nur besser werden. Insofern würde ich einem Django-aber-async Framework keine großen Chancen einräumen, es sei den die Django Leute kriegen es nicht auf die Reihe viel Fortschritt zu machen.

Ich hab aber den Eindruck dass der aktuelle Trend sowieso ist alles was "frontend" ist in JS zu machen und "frontend" schliesst mitunter auch Sachen ein die auf dem Server laufen und da React serverseitig rendern. Sprachen die nicht JS sind nutzen HTTP nur noch als RPC und nicht um Webseiten auszuliefern. Dementsprechend verliert auch Django (und ähnliche Frameworks wie RoR) an Relevanz.

Wobei natürlich sich immer die Frage stellt wieviel der Hype mit der Realität zu tun hat aber zumindest bei uns trifft dass schon zu.

[noisefloor]

Hallo,

...aber zumindest bei uns trifft dass schon zu.

Gut zu wissen - ich dachte, Zalando nutzt auch Web2Py, weil Zalando ja auch einen Login für die Kunden braucht *SCNR*

Im Ernst: Die Frage, die wahrscheinlich keiner hier beantworten kann, ist, wie sich da, was die "großen" machen, also nicht nur die ganz großen wie Amazon, Google, Facebook & Co, sondern auch Zalando und ähnlich Sachen in der Liga, auf die mittelgroßen und kleineren Webseiten auswirkt bzw. da rein reflektiert. Sehr viele Webseiten bzw. Webangebote haben ja nicht X Tausend oder X Zehntausend Request pro Sekunden. Und ich denke, dass sich da die etablierten Sachen wie Django oder RoR oder die ganze Sachen, die es in PHP gibt, noch passable lange halten werden. Sicher bin ich mir das nur, dass Py4Web da nicht mit spielen wird.

Gruß, noisefloor

[__blackjack__]

In dem Zusammenhang ein Klassiker: You Are Not Google.

[naheliegend]

async ist doch schon Tornado. Vielleicht gewinnt das dadurch, das mag sein. Generell denke ich ist Python im Web eher nicht auf dem aufsteigenden Ast - da spielen mit Node und Go mehr und mehr andere Sprachen die vorderen Geigen. Finde ich persoenlich auch nicht schlimm. Web habe ich hinter mir

Warum ist Node und Go besser als Python?

[__deets__]

Besser ist relativ. Go ist zb deutlich performanter, und Node ist wegen der Nähe und Wiederverwendbarkeit von JS in Front- und backend beliebt. Wenn du Programmierer hast, die in zwei statt einer Sprache gut sein müssen, macht das einen Unterschied.

[kbr]

Ich hatte jetzt einen Fall, bei dem async sinnvoll war, ebenso das in django bereits integrierte ORM. Django 3.1 macht da schon einen recht brauchbaren Eindruck.

[naheliegend]

Ich hatte jetzt einen Fall, bei dem async sinnvoll war, ebenso das in django bereits integrierte ORM. Django 3.1 macht da schon einen recht brauchbaren Eindruck.

Was war das für ein Anwendungsfall (,wenn man fragen darf)?

[DasIch]

In dem Zusammenhang ein Klassiker: You Are Not Google.

Ein Punkt der hier nicht explizit genannt wird aber wichtig ist: Man greift natürlich bei Google und anderen Organisationen bei neuen Problemen auch ganz pragmatisch zu Lösungen die man schon hat. Nur weil man ein kleineres Problem hat und dieses Werkzeug was man schon hat da etwas überdimensioniert ist erfindet ja niemand das Rad neu (wobei dass natürlich auch vorkommt). Ganz praktisch und pragmatisch schiesst man so halt ab und zu mit Kanonen auf Spatzen.

Du braucht eine Queue für ein paar Events pro Tag? Könntest du jetzt auch einfach in postgres umsetzen. Wenn du aber da schon den Kafka Cluster hast, vielleicht sogar mit tollem Monitoring und praktischerweise kümmert sich ein anderes Team um die Administration, tja dann greift man auch schonmal zu Kafka.

Es ist also völlig egal um welches Problem es geht, selbst bei kleineren Problemen die man vielleicht auch hat, würde ich Lösungen von größeren Organisationen mit ganz viel Vorsicht genießen.

[kbr]

Was war das für ein Anwendungsfall (,wenn man fragen darf)?

Zur Bearbeitung eines Requests wird u.a. eine externe API aufgerufen, die ihre eigene Latenz hat. Es ist natürlich eine Designentscheidung, ob man in einem separaten Thread wartet oder async verwendet.

[noisefloor]

Hallo,

Warum ist Node und Go besser als Python?
[/quote]

"Besser" ist relativ - es kommt drauf an, was du brauchst Neben der bereits genannten Ausführungsgeschwindigkeit hat Go eine einfach zu nutzende Nebenläufigkeit in Form von Goroutines eingebaut. Was halt praktisch ist, wenn man Webanwendungen hat, die viele Requests in kurzer Zeit bearbeiten müssen.

Gruß, noisefloor

[DasIch]

Async ist übrigens auch so eine "You are not Google" Sache. Macht nur Sinn wenn man viel IO macht, während man einen Request verarbeitet. Das tut man in großen Unternehmen sehr häufig, wenn man da Microservices nutzt. Da macht man schonmal einen request für authentication zum authentication service, einen zweiten für authorization zum authorization service und schon ist man bei zwei Requests minimum pro eingehendem Request.

Wenn man aber eine einfache Webanwendung hat die auf eine Datenbank und vielleicht auch noch auf Redis zugreift macht async keinen Sinn, im Gegenteil dürfte der Latenz eher schaden.

[__deets__]

Ich sehe noch einen anderen Vorteil von async: Nebenlaeufigkeit. Viele Leute die zB GPIOs steuern wollen, mit anderen dauerhaft offenen Dateien hantieren, oder Timer-basiert arbeiten, koennen das damit oft ohne auf Threading zurueckgreifen zu muessen.

[Sirius3]

@DasIch: async macht bei Datenbankzugriffen und Redis genauso Sinn, dann das ist ja genauso IO.

[DasIch]

Die Anzahl der Queries die man effizient parallel ausführen kann ist überraschend gering. Das erreicht man auch ohne async problemlos. Wenn du also viele Requests bekommst hängst du dann einfach an deinem Connection Pool. Wenn backpressure nicht richtig implementiert ist (was du ja bei sync io implizit und ohne aufwand hast) akzeptierst du aber weiter Requests und der Server fliegt dir um die Ohren.

Zur backpressure Problematik gibt es auch einen Artikel von Armin Ronacher aka mitsuhiko, der noch mehr ins Detail geht.