Verständnisfrage Webframework / Socketserver

Django, Flask, Bottle, WSGI, CGI…
Antworten
WbSrvr
User
Beiträge: 4
Registriert: Dienstag 1. Februar 2022, 06:19

Hallo Zusammen, ich habe noch eine Frage zum Thema Webserver / Webanwendung

Ich habe einen Rechner in einem lokalen Netzwerk. Auf Anfrage durch Clients soll er mir Python Scripte ausführen und Informationen berechnen (Z.B. Bildverarbeitungsfunktionen) und wieder zu den Clients schicken.
Im Moment ist das System noch per socketserver Modul mit TCP ausgeführt.

Grundsätzlich habe ich verstanden, dass Webframeworks wie Flask / Django die folgenden Vorteile gegenüber den Socketserver Modulen haben:

-loggen viele "Absturzgründe" mit (z.B. a harddrive crash, backend server overloade,programming error in a library.....)
-haben eingebaute Features für Sicherheit ( z.B.. gegen Cross-Site Scripting (XSS), Security Headers...)
-stellen einfache "Bausteine" für Authentification bereit
-vereifachter Zugriff / Handling mit verschiedenen DBMS

Zudem ist ein großer Vorteil, dass die Frameworks einen festen Aufbau haben was zur Folge hat, dass sich andere Nutzer/Entwickler leicht zurecht finden.

Für mich wäre aber am aller Wichtigsten, dass die Verbindung Client / Server
- robust (Fehler werden Abgefangen ohne Absturz)
- stabil (Lange Laufzeit ohne Absturz)
ist.

1. Kann jemand mal erklären ob diese beiden Eigenschaften auch durch ein Webframework abgesichert werden (und wie)?
2. Was sind noch Gründe dafür, dass ich ein Webframework nutzen sollte? (ggü. selbst geschriebenem "socket-server" -Code)

Vielen lieben Dank!
Sirius3
User
Beiträge: 17710
Registriert: Sonntag 21. Oktober 2012, 17:20

Wenn Du eigenen socket-server-Code geschrieben hast, dann ist der mit großer Wahrscheinlichkeit fehlerhaft, weil es nicht einfach ist, ein Protokoll auf Basis von TCP korrekt zu implementieren.
Deshalb erfindet man nicht selbst etwas, wenn es schon ein etabliertes Protokoll gibt, das die Anforderungen erfüllt, und HTTP ist sehr flexibel und für viele Fälle geeigent.
Der Vorteil ist, dass man sich nicht selbst um den Server kümmern muß und dass es für jede Programmiersprache auch schon auf Client-Seite fertige Pakete gibt, oder schöne graphische Oberflächen, die sich Browser nennen.
Da hat man auch null Aufwand, sich mit dem Protokoll auseinanderzusetzen und kann sich ganz auf die eigentliche Verarbeitung konzentrieren.
Ob etwas robust und stabil programmiert ist, hängt natürlich davon ab, wie Du Dein Programm geschrieben hast. Aber da man bei HTTP selbst sehr viel weniger Code schreiben muß, ist die Anzahl der Zeilen, wo man einen Absturz verursachen kann, sehr viel kleiner.
Antworten