Webpage updaten ausgehend von Datenbankänderungen

Django, Flask, Bottle, WSGI, CGI…
Antworten
Sternenregen
User
Beiträge: 39
Registriert: Mittwoch 13. Januar 2021, 16:17

Ich möchte in Flask die Webpage aktualisieren. Dies soll aber erst dann geschehen, sobald es eine Änderung innerhalb einer Datenbank (SQL) gibt.
Was wäre der beste und effizienteste Weg dies zu erreichen?
Benutzeravatar
noisefloor
User
Beiträge: 3843
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

in dem die die DB bei jedem Aufruf der Seite ausliest und die Werte dann in die Seite einbaut. Das ist aber eigentlich auch das Standardvorgehen, was quasi auch in allen Tutorials so gemacht / vorgemacht wird.

Gruß, noisefloor
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

Hallo Sternenregen,

wie noisefloor schon sagt ist es in der Regel immer so dass sich die Seite nur aufgrund einer Anfrage vom Benutzer (Browser) ändert. Daher auch Client - Server - Verbindung. Anfrage vom Browser -> der Server antwortet indem er die entsprechende Seite sendet.

Es gibt aber Ausnahmen: Z.B.: wenn du gerade im Browser deine Emails liest und eine neue Nachricht ankommt, wird sie angezeigt ohne dass du etwas tun musstest.
Das geschieht in der Regel über eine Websocketverbindung, die schon beim ersten Laden der Seite aufgebaut wurde. Die Verbindung bleibt bestehen während du auf der Seite bleibst und über eben diese Verbindung kann der Server dann seinerseits den Inhalt der Seite verändern.
Dazu muss auf der Seite der entsprechende Javascript-Code auf Ereignisse vom Server reagieren und den Inhalt der Seite verändern.

Also müssen Javascript auf der HTML Seite und Flask-Server miteinander kommunizieren.

Dazu eignet sich z.B. Flask - SocketIO
https://flask-socketio.readthedocs.io/en/latest/
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Das geschieht in der Regel über eine Websocketverbindung[...]
Das würde ich mal stark bezweifeln. Websockets sind ziemlich kompliziert und aufwendig zu betreiben, da man ja die ganzen Verbindungen offen halten muss und auch irgendwo die korrespondieren Informationen vorhalten muss. Es ist viel einfacher den Client einfach in einer Schleife Requests an eine API schicken zu lassen und darauf zu reagieren. Erfahrungsgemäß macht man es dann auch so, es sei den es ist nicht anders möglich.

Um mal beim Beispiel eines E-Mail Clients zu bleiben: Gmail nutzt keine websockets und scheint in einer Schleife POST Requests nach `https://mail.google.com/sync/u/0/i/s` zu machen um nach neuen E-Mails zu schauen. Wobei es da noch anderen Traffic gibt nach ähnlichem Muster gibt, ich glaub der Rest ist aber Telemetrie.
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

@DasIch,

Es gibt wie immer mehrere Möglichkeiten.
Man muss sich halt überlegen ob es gewünscht ist, 1000 mal den Server anzufragen bevor der mal neue Daten hat.
Da finde ich Websockets eleganter.

Websockets sind nur kompliziert wenn man sie von Grund auf selbst implementiert, was aber nicht nötig ist.

Sie sind auch nichts exotisches sondern fester Bestandteil von Javascript.
Und Flask-SocketIO für Python hatte ich ja schon erwähnt.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Die Implementation ist ja nur ein Teil der Arbeit. Es gibt ja genug andere Sachen über die man nachdenken muss z.B.:
  • Komplexeres Deployment, du brauchst nämlich jetzt eine Message Queue (Redis, RabbitMQ, Kafka, ...). Redis ist noch relativ leicht zu betreiben aber RabbitMQ und erst recht Kafka, ist nichts was man mal ebenso betreibt. Die einzelnen Optionen hier bieten natürlich auch viel Spielraum was Konfiguration angeht. Hier muss man auch mal schauen wie man dass am besten macht. Vielleicht hat man sowas schon aber selbst dann muss man mal schauen ob es der Belastung noch standhalten würde und ggfs. Anpassungen vornehmen.
  • Load Balancing von Websocket Verbindungen und ggfs. auch sprunghafte Veränderungen wenn ein Server neustartet z.B. bei Deployments. Hier muss man auch überlegen ob man am Load Balancing Algorithmus schrauben oder was konfigurieren muss. Vielleicht muss man da auch auf der Client Seite etwas aufpassen.
  • Monitoring, alles was du ggfs. für HTTP hast (Throughput, Latency) musst du jetzt für Websockets nochmal neu lösen. Standard Mechanismen wie Load Balancer Logs oder OpenTelemetry/OpenTracing funktionieren da auch nicht so einfach.
  • Man muss auch mal schauen was dass für neue Fehlerszenarien möglich macht und ggfs. Playbooks anpassen. Was passiert z.B. wenn man Redis als Message Queue nutzt und man verliert die Redis Instanz?
Ganz besonders spannend an der Stelle ist auch was die Dokumentation von Flask-SocketIO und python-socketio zu diesen Themen sagt.

Für eine kleine Demo kannst du sowas ignorieren aber in production sollte man sich über solche Punkte Gedanken machen. Idealerweise nicht erst Montag morgen um 03:00 weil einem der Kram um die Ohren fliegt.

Klar ist polling nicht sonderlich elegant aber dass hast du bei einer existierenden Anwendung an einem Tag implementiert und du hast ein robustes Ergebnis, angenommen die Anwendung ist sonst ok. Ich würde tendenziell bezweifeln dass es jemand hinbekommt ein vergleichbar robustes Ergebnis mit Websockets in einem Monat zu erreichen.
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

Hallo DasIch,

einige deiner Aussagen sind übertrieben und teilweise auch falsch.
Aber das kann man ewig weiter diskutieren.
Wenn du keine websockets verwenden willst oder musst, kommst du bestimmt auch ohne sie gut klar.
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

@rogerb: also jemanden vorzuwerfen, er wuerde etwas falsches erzaehlen, ohne das zu belegen, ist schon ein bisschen stark. DasIch hat hier nix falsches erzaehlt, sondern aus seiner Arbeit bei einem der wenigen echten Hyperscaler eine andere Sicht auf Probleme. Wer in seinem Spassprojekt eine neue Technologie einfuehren will, kann das gerne machen. Wenn man das auf tausenden Systemen tun will, muss man sich eben andere Fragen stellen und beantworten, als nur ein saloppes "finde ich eleganter" beizubringen. Und diese Perspektive bringt er hier ein.

Ich persoenlich wuerde uebrigens auch durchaus Websockets nehmen, aber eben auch nur fuer meinen privaten Spass. Auf Arbeit aber zb nutzen wir die auch nicht, sondern SSE, weil das einbringen einer weiteren Technologie entsprechende Folgenabschaetzungen mit sich bringt. Nur weil DU diese Anforderungen nicht hast, reden Leute, die das haben, keinen Unsinn.
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

__deets__ hat geschrieben: Freitag 21. Mai 2021, 14:28 also jemanden vorzuwerfen, er wuerde etwas falsches erzaehlen, ohne das zu belegen, ist schon ein bisschen stark.
Naja, es war halt offensichtlich falsch.
Man braucht für Websockets nun mal nicht automatisch eine Message Queue und auch kein Load-Balancing.

Aber das werdet ihr beide wissen, wenn ihr ehrlich seit.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Von der Flask-SocketIO Dokumentation:
If using multiple processes, a message queue service is used by the processes to coordinate operations such as broadcasting.
Ich gehe mal davon aus dass man in einer Produktivumgebung mindestens zwei Prozesse auf zwei unterschiedlichen Servern hat um zu gewährleisten dass die Anwendung noch funktioniert, falls ein Server abstürzt. Damit der Traffic bei den Servern ankommt braucht man dann auch einen Load Balancer. Auch bei Deployments ohne Downtime hättest du zwei Prozesse (und vielleicht auch Server), wobei ein neuer Prozess gestartet wird und erst wenn der läuft der alte gestoppt wird. Man kann zwar mit DNS Traffic switchen aber auch hierfür würde sich ein Load Balancer anbieten.

Zugegeben man "braucht" dass nicht, du kannst natürlich auch akzeptieren dass deine Anwendung offline ist wenn ein Server abstürzt oder du ein Update machst. Mein Anspruch – und ich hab den Eindruck dass dies auf dieses Forum grundsätzlich zutrifft – ist es aber Antworten zu geben die auch dann noch gelten wenn es ins professionelle geht und da ist sowas nicht akzeptabel.

Ich hab auch nichts gegen Websockets. Sie haben sicherlich ihre Daseinsberechtigung und in Situationen in denen eine niedrige Latenz wirklich wichtig ist, haben Websockets sicherlich einen Vorteil. Websockets haben aber auch einige größere Nachteile. Man muss sich mit denen genauso auseinandersetzen wie mit den Vorteilen und schauen ob der Einsatz in der konkreten Situation sinnvoll ist.

Eine solche Situation wäre meiner Meinung nach z.B eine Chat Anwendung. Da ich an sowas nicht arbeite hab ich mal nachgeschaut und tatsächlich nutzt Slack auch Websockets in ihrem Web Client und bieten eine WebSocket API für Bots an. Google Chat scheint aber keine Websockets zu nutzen, man kann also wohl auch hier ohne auskommen.
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

Egal ob man nun Websockets oder long-polling benutzt , man läuft in Ähnliche Probleme, was sas Wiederverbinden bei Netzwerkproblemen betrifft. Da man sich bei zweiteres eh um mehr selbst kümmern muss, fällt das vielleicht nicht so sehr auf.
LukeNukem
User
Beiträge: 232
Registriert: Mittwoch 19. Mai 2021, 03:40

DasIch hat geschrieben: Freitag 21. Mai 2021, 22:49 Von der Flask-SocketIO Dokumentation:
If using multiple processes, a message queue service is used by the processes to coordinate operations such as broadcasting.
Ich gehe mal davon aus dass man in einer Produktivumgebung mindestens zwei Prozesse auf zwei unterschiedlichen Servern hat um zu gewährleisten dass die Anwendung noch funktioniert, falls ein Server abstürzt.
Das ist absolut korrekt. Zusätzlich möchte ich anmerken, daß in so einem Fall idealerweise auch der Sessionstore und alle anderen Zustände in einen verteilten Service wie zum Beispiel Redis gelegt werden sollten. Obendrein kann man die Workload dann sehr einfach verteilen und die ganze Angelegenheit bei Bedarf auch horizontal skalieren, und einen beliebigen Loadbalancer ohne weitere Konfigurations- und Deploymentaufwände benutzen.
Antworten