Das deutsche Python-Forum

Hallo,
danke für die Einschätzung.

Ich merke gerade, dass selbst Flask relativ schnell relativ unübersichtlich wird. Ich meine Front- und Backend verschwimmt vollkommen. Also ich meine Variablen aus dem Backend im HTML anzeigen lassen und dann selbst im Frontend noch if-else oder for loops einbauen. Ist das normal oder gibt es irgendwie eine "Grundstruktur", die ich beachten sollte?
Bzw. hat man dann eine .py oder für jede Route eine separate Datei?

@naheliegend: Das ist bei Django nicht anders und das ist soweit ich das sehe auch keine Frontend- vs. Backend-Frage. Frontend ist das was im Browser passiert. Templates befüllen passiert bei Dir ja aber noch auf dem Server.

Ich wüsste auch nicht wie Templates ohne Bedingte Verzweigung und Schleifen aussehen sollten. Ohne wäre das nicht brauchbar.

Es ist im Grunde ähnlich wie bei der Trennung GUI und Programmlogik in traditionellen grafischen Anwendungen. In die Templates gehört nur Logik für die Anzeige.

Wie sinnvoll wäre es jede Funktion in ein eigenes Modul zu schreiben?

__blackjack__ hat geschrieben: Sonntag 4. Oktober 2020, 16:38 Ich wüsste auch nicht wie Templates ohne Bedingte Verzweigung und Schleifen aussehen sollten. Ohne wäre das nicht brauchbar.

Mustache geht noch am ehesten in die Richtung. Aber trotz deren Werbespruch ist auch das meiner Meinug nach nicht wirklich "logikfrei"; die Logik ist nur stärker versteckt.

Okey danke.

Benutzt man Sessions oder Tokens bei Logins?

Weißt du was der Unterschied ist?

Sessions: Beim Post wird die Session auf dem Server gespeichert und eine ID an de Client geschickt. Beim nächsten Post wird die ID mitgeschickt und mit dem Dings, was auf dem Server gespeichert wurde verglichen. Response mit "Ja, kenne ich" oder "Nein, kenne ich nicht". Viel Backend work, bei vielen Usern bzw viel Speicherplatzverbrauch

Tokens: Beim Post wird ein Web Token erzeugt mit einem Secret. Wird das per Hash erzeugt oder mit sowas wie RSA oder so? Server sendet das Token an den Client, der speichert es dann wo? Lokal auf der Festplatte? Das Token wird dann beim nächsten Post mitgeschickt im header und der Server - ja, muss dann doch einen key haben um das Token entschlüsseln zu können, oder? Was passiert dann?


------

Wo wir bei den Grundlagen sind: Ich glaube ich habe noch nicht ganz verstanden, wann man SOAP und wann man REST benutzt, bzw. wann SOAP besser sein könnte?

SOAP benutzt man nie, wenn einen dazu keiner zwingt: http://harmful.cat-v.org/software/xml/soap/simple

Deine Überlegungen zu Sessions vs Tokens sind überkandidelt. Benutz, was für dich einfacher ist (zu 99% Sessions). Wenn du mal so weit sein solltest, dass dir das Probleme macht, hast du die Erfahrung einzuschätzen, was da besser wäre.

Stimmt ja fast: bei Sessions bleibt alle Information auf dem Server, und es wird nur eine ID an den Client geschickt. Das können beliebige Daten sein, meist eben der Benutzername, Zugriffsrechte usw. Speicherplatzverbrauch ist eigentlich kein Problem. Vorteil: wenn man eine Datenbank hat, ist das sehr einfach zu implementieren.

Bei Tokens wird alle Information an den Client geschickt. Das können also realistischerweise nur ein paar hundert Bytes sein, meist Benutzername, Zugriffsrechte, etc. Damit der Client diese Daten nicht fälschen kann, muß sie kryptographisch signiert sein. Sowas richtig zu implementieren, ist nicht ganz einfach. Vorteil ist, dass man keine Datenbank oder sonstigen Speicher braucht. Die Token können von einem ganz anderen Server erzeugt werden. Stichwort ist hier lose Kopplung und Microservices.

SOAP ist eine okmplexe XML-basierte Objektorientierte Schnittstelle, bei REST ist viel einfacher, weil ein Funktionsaufruf über die URL referenziert wird.

Und warum wird dann noch so viel SOAP im Interner genutzt? Irgendwelche Vorteile muss das doch haben, außer, dass man nicht http verwenden muss.

SOAP nutzt auch HTTP. Wie kommst du darauf, dass noch so viel SOAP benutzt wird? Wenn es funktioniert ist es einfach zu benutzen. Funktionieren tut es, wenn beide Seiten das selbe Framework in derselben Programmiersprache benutzen. Man muss sich nicht wirklich viele Gedanken machen und so sehen die Schnittstellen dann auch aus.

Ja, aber SOAP kann auch etwas anderes als HTTP nutzen, oder?

In Artikeln gelesen, dass in der Finanzbranche eher mit SOAPs gearbeitet wird, weil es standardisiert (was auch immer das bedeutet) ist und security gleich mitbringt. Also man muss nichts mehr auf der Anwenderschicht programmieren. Aber das kann doch nicht der einzige Vorteil sein, oder? Es muss doch einen Anwendungsfall geben, wo man zu 100% sagt "jo, nur SOAP und nichts anderes".

Und mit Aussagen wie: "SOAP benutzt man nicht" komme ich nicht so weit.

Ich habe noch nie von einem realen anderen Transport außer HTTP für SOAP gehört. Auch das es per se Sicherheit eingebaut hätte ist falsch. Und hast du den Artikel gelesen, den ich dir geschickt habe? Standardisiert ist SOAP so schlecht, dass im Grunde nur dann etwas klappt, wenn auf beiden Seiten die exakt gleiche Umgebung genutzt wird.

Wir mussten zb mal eine Microsoft basierte Accounting Lösung von Python aus Ansprechen. Das ist nur möglich gewesen, indem wir den mitgelieferten VB.NET client benutzt haben, und dem Netzwerkverkehr mitgeschnitten haben. Und die XML Dokumente dann von Hand in templates umgewandelt & mit den gewünschten Daten befüllt haben. Von wegen „nichts in der Anwendungsschicht programmieren“.

Es gibt aus meiner Perspektive nur einen Grund, SOAP zu benutzen: auf beiden Seiten kommt Software des gleichen Herstellers zum Einsatz. Und die benutzt unter der Haube irgendwas. SOAP. Oder CORBA. Oder Meldereiter. Mir egal. Dann setzt man auch SOAP ein. Weil man davon nix mitbekommt.

Wenn man selbst eine Schnittstelle entwerfen will, benutzt man REST.

Habe ich gelesen, aber nicht so viel verstanden, weil ich nicht weiß, was diese Fachbegriffe sind wie "Interoperability", "WS-I compliant SOAP stack" oder "Doc/Lit". Aber es hört sich scheußlich an.

Kann REST eigentlich auch asynchron laufen, je nachdem wie lange der Server braucht, um eine Antwort zu schicken? Finde nämlich immer "asynchron" als Vorteil auf der SOAP-Seite

Was denn für eine SOAP-Seite?

Wenn man das googelt findet man das hier: https://stackoverflow.com/questions/238 ... t-does-not

Zusammenfassung: wenn man zwei server hat, die sich gegenseitig erreichen können (nicht selbstverständlich!), kann man ein request abschicken mit einer Anfrage, und bekommt ein zweites in Gegenrichtung. Auch das ist mit REST trivial erreichbar. Denn HTTP ist HTTP ist HTTP. Das SOAP das in seinem Tooling irgendwie versteckt, ist theoretisch nett. Dass das weniger wertvoll ist weil inkompatibel haben wir ja schon erarbeitet.

Bei der SOAP vs. REST Gegenüberstellung auf der SOAP-Seite.

Also kann man REST auch asynchron nutzen, wenn man dafür sorgt, dass der Server2 an den man POSTed auch ein POST irgendwann auslöst und der dann vom Server1 verarbeitet werden kann?

Ja. Selten bis nie genutzt. Eher gibt man ein zb Task toke zurück und Pollt von der Client Seite. Funktioniert auch ohne Firewall Einstellungen.

Wenn man bei sich Zuhause im Garten arbeitet, greift man vielleicht zur Schaufel aber nicht zum Schaufelradbagger. Auf ganz ähnliche Weise sollte man auch bei der Software Entwicklung überlegen welches Werkzeug für das Problem und die Situation angemessen ist. Das trifft vor allem dann zu wenn man schaut was große Organisationen tun. Du tust dir keine Gefallen wenn du dich auch am Schaufelradbagger-äquivalent versuchst, es sei den es geht dir um den Lerneffekt. Wobei man auch beim lernen sicherlich besser den Gebrauch der Schaufel drauf hat, bevor es ein paar Nummern größer wird.

Ich würd dir empfehlen einfach eine monolithische Django Anwendung zu bauen, dass passt schon. Vielleicht nicht für immer aber dann bist du auch sicherlich in der Lage die Probleme die du dann hast zu lösen.

naheliegend hat geschrieben: Donnerstag 8. Oktober 2020, 05:54 Und warum wird dann noch so viel SOAP im Interner genutzt?

Die Leute, dir mir begegnet sind und die SOAP gerne benutzen, sind eine echte Teilmenge derjenigen, die Spaß an Java haben und finden, dass XML ein gutes Format für Konfigurationsdateien (und für alles andere eigentlich auch) ist. Sie stammen aus dem "Enterprise" oder (seltener) auch Uni-Feld.

Ich mach erstmal Flask "zu Ende" und dann schaue ich mal nach Django und co.

Was genau machen eigentlich Sockets und gibt es einen Unterschied zu Websockets?