Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, heute in der 29. Episode.
Wir machen heute REST, Representational State Transfer.
Was ist das eigentlich? Und hier ist der Dominik und ich bin da mit dem Jochen und heute wieder mit dem Johannes.
Hallo, Glück! Hallo Johannes, hallo.
Ihr kennt uns ja vielleicht schon, wenn ihr gehört habt, wir waren öfter schon mal in dieser Konstellation.
Das heißt, wir stellen uns heute nicht vor. Aber wie gesagt, wir machen REST, Representational State Transfer.
und
ja, den frage ich dann zuerst, was ist denn das?
Ja, ich dachte, wir wollen nicht
vielleicht zuerst ein News machen, weil ich habe da auch noch so ein paar Sachen...
Nein, nein, wir wollen erst mal kurz das Topic erklären und dann machen wir News.
Oh, da kommen wir nicht mehr zu den News.
Doch, die kommen noch zu den News.
Na gut, okay, machen wir es jetzt andersrum.
Erklär mal ganz kurz, was REST ist. Aber nur ganz kurz.
Ja, das ist Elevator-Fischung.
Also,
man stellt sich vor, man hätte da so eine Dampfmaschine.
Ne, warte mal.
Also, REST ist,
Also ich glaube, das beste Beispiel für, wie kann man sich das vorstellen, was das eigentlich ist, ist, man nimmt halt irgendwie das Web.
Das ist ja mal krass.
Genau, das ist das Web.
Dann hat man dann so einen Browser und das ist eigentlich Rest.
Also das Web ist schon Rest.
Okay.
Okay, News.
Ich erkläre das immer anders.
Ich erkläre das immer im Unterschied zu dem, was es nicht ist.
und was man früher gemacht hat, um
APIs zu machen, war LPC,
Remote Procedure Call,
wo man halt Funktionen hatte, die man aufgerufen hat
mit irgendwelchen Daten. Und REST
ist jetzt eben nicht Funktionen, die man aufruft,
sondern Objekte, die man abruft und verändert.
Und
das ist für mich so der Knackpunkt, was
REST zu REST macht.
Dass man nicht Funktionen aufruft, sondern
Objekte
abruft und verändert.
Jetzt suchen wir das Objekt News ab.
Jetzt machen wir News?
Ja, jetzt machen wir News.
Gut, okay, machen wir ein News.
Python 3.9.2.
Pattern Matching.
Genau, Pattern Matching ist auch tatsächlich der erste Punkt, den ich auf der Liste habe.
Alle anderen Punkte sind unwichtig.
Pattern Matching.
Case, Switch, Case.
Hast du da eigentlich dir schon mal Gedanken gemacht über Pattern Matching?
Nur ganz am Rande.
Ich fand das so gut, dass ich direkt einen Blogartikel auf meinen selten benutztes Blog geschrieben habe,
weil das so wichtig ist und so toll, dass ich, ja klar, kriegt ihr natürlich einen Link dazu.
dass ich das sofort schreiben musste
und
Pattern Matching ist so ein Feature
was es in anderen Sprachen
in vielen funktionalen Sprachen gibt
was man auch da kennt
und wenn man das einmal gesehen hat, dann kann man nicht mehr ohne
und
ich habe früher an der Uni
funktionales Programmieren gelernt und gemacht
und war dann etwas schockiert als ich zu Python
kam und die hatten das nicht
und habe es aber irgendwann vergessen, dass es das in Python
nicht gibt
und jetzt gibt es es irgendwann
endlich wieder.
Ja, aber es gibt doch If-Else, warum brauche ich denn dann ein
Switchcase? Ja, das ist prinzipiell
richtig, man kann das alles mit If-Else machen,
man kann auch prinzipiell jede Schleife
aus While-Loops machen, man kann prinzipiell
auch alles aus Goto zusammenbauen,
man macht es nicht, weil es nicht
gut ist und
weil es bequemere Dinge
gibt. Und gerade jetzt das Pattern-Matching,
was in Python reinkommt, ist
meiner Meinung nach ein sehr mächtiges Pattern-Matching.
Die können matchen auf Typen und
auf Werte und die können Variable Capture
machen,
wo eben so ganz komplizierte
Fälle, die ein
sehr langes If wären,
dann auf einmal sehr einfach zu
schreiben. Was ist ein Variable Capture?
Was
Pattern Matching macht, ist
im Wesentlichen ein If, wo ich nicht
hinschreibe, dass eine Bedingung wahr oder
falsch ist, sondern ich
schreibe eine Datenstruktur hin.
Und wenn diese Datenstruktur
vorgefunden wird,
dann trifft dieses Pattern zu.
Die erste coole Sache, die da passiert ist, dass man nicht mehr irgendwelche Dictionaries .get machen muss
oder irgendwelche Listen gucken muss, ob die Länge größer 0 ist und dann das erste Element rausholen
sondern man schreibt einfach hin, aus der Liste, das erste Element soll ein Attribut haben x
und das soll den Wert y haben.
Und wenn diese Struktur zutrifft, dann ist dieses Pattern gematcht.
Ich habe in dem eben genannten Blogartikel ein Beispiel, wo es sehr eindeutig wird.
Variable Capture heißt, dass ich in dieses Muster, was ich hinschreibe, in diese Datenstruktur, nicht nur konkrete Werte reinschreiben darf, sondern ich darf auch Variablen Namen reinschreiben.
Und wenn diese Variablen Namen gefüllt werden können, dann stehen die mir in dem Branch, der dann aufgerufen wird, zur Verfügung.
Das heißt, wenn ich zum Beispiel sage, das Pattern, was ich schreiben möchte, ist, das erste Element der Liste ist der Float X, dann kann ich in dem Branch, der dann zutrifft, auf die Variable X zugreifen und es ist automatisch sichergestellt, dass das ein Float ist, also es ist schon gecastet.
Und das heißt Variable Capture, weil eben diese Variable sozusagen aus diesem Muster raus eingefangen wird.
Das klingt sehr nützlich und wenn man das auch mit Typen und so machen kann.
Das klingt, das ist super nützlich. Gerade das erste Beispiel, was man da sieht, ist eben diese Typen. Wenn ich eine Funktion schreibe, die vier verschiedene Typen annehmen kann, dann schreibe ich jetzt einfach match type von x, case int und dann ist es ein int oder case dr, dann ist es ein dr. Das ist so viel einfacher, als das mit ifs zu machen. Das ist sehr, sehr schön.
Ja, fand ich auch. Es gab aber viel Gegenstimmen, muss ich sagen.
Ja, es gab ganz schön Gegenwind.
Es gibt ja schon seit einiger Zeit irgendwie Leute, denen
das alles kompliziert wird und ich meine,
da gab es ja auch diese große Kontroverse
beim Walrus
Operator.
Ja, auch bei den Typen,
bei den Type Annotations.
Ja, aber die sind auch, 3.10 ist
doch irgendwie so eine Muss-Version, oder?
Das ist nicht so eine Kann-Version, was da alles kommt. Also die
Type Annotations, die dabei sind, dass man einfach
hinter schreiben kann, die Klasse
beispielsweise, die das sein soll oder
deren Instanz das sein soll, ohne
dass man da groß Typer importiert
und dann kann man so einen Union Operator dahinter
setzen, also diesen
und dann kann man da zwei
verschiedene Typen haben und so, das sieht alles
total schick aus, also ich finde, so wollte ich das
schon immer lesen
Ja, also ich weiß
nicht so genau, ich meine, bei denen, ich finde das
diese Type Annotations
die sind halt an manchen Stellen total nett
ob ich das jetzt an allen Stellen
im Code gerne hätte, weiß ich jetzt auch nicht
Das ist ja das Schöne
Genau, genau.
Und da, wo es halt Sinn macht,
da kann man es dann halt dazu tun
und dann ist es auch nett. Ich finde auch tatsächlich,
das mache ich in letzter Zeit häufiger,
entweder
Dataclasses,
oder Pydentic verwenden
und tatsächlich Klassen
so hinzuschreiben, ist deutlich
angenehmer als das irgendwie...
Hatten wir Pydentic schon mal?
Ja, ich weiß nicht genau,
ob ich es mal gepickt hatte
oder so. Kann sein.
Was macht Pydentic?
Du hast es auf jeden Fall mal erwähnt, glaube ich.
Verlinke es auf jeden Fall nochmal, das ist ziemlich cool.
Ja, genau.
Ja, und also ich finde
die
diese Art
sozusagen das Klassen hinzuschreiben
sowieso irgendwie macht irgendwie
nett. Ich sehe, ich habe auch schon
irgendwie hier in Pydentic in der Doku mal rumgewühlt.
Also eigentlich wollte ich wissen, was das ist.
Ja, das ist so
eine Art Mischung aus
MyPy und Dataclasses, oder?
Man kann leicht Datentypen definieren
mit bestimmten Typen und der prüft die dann auch noch
Genau, also es prüft
es halt auch zur Laufzeit
und es ist halt auch so, dass man dann
halt so eine eingebaute Serialisierung nach
JSON oder so auch mitkriegt, weswegen
man es eigentlich auch super für so REST-Geschichten
verwenden kann
REST?
REST ist das denn, Jochen?
Ja, Moment
Erstmal die Reste der News, bitte
Was haben wir denn da noch?
so ein Pattern Matching
ja, coole Sachen, da sind wir uns alle einig
irgendwie komisch, naja
es gibt neue Releases von
UV Loop und Async PG
und so, aber
da war jetzt auch nichts weltbewegendes dabei
aber Async PG ist auch so ein Ding
was man sich unbedingt mal angucken kann
wovon hast du gerade gesprochen?
ja, UV Loop ist halt so eine schnelle
also ist die
Python-Version oder
Abstraktionen-Drapper
um LibUV und das ist eine super schnelle
Abstraktion über
die ganzen
betriebssystemspezifischen Schnittstellen,
sowas wie EpoL oder KQ oder
was weiß ich nicht, was da sonst so.
TCP Completion Ports oder
I.O. Completion Ports.
Ich glaube, das ist mehr Stuff
für die Web-Server-Folge, die wir immer machen.
Ja, genau, aber auf jeden Fall,
man kann damit schnell I.O. machen
und das Ganze halt in der
Event-Loop und das ist auch das, was unter Node.js
zum Beispiel darunter liegt. Und genau
davon gab es jetzt gerade eine neue Version und
Async-PG
ist halt ein Async
Library,
um halt auf Postgres zuzugreifen und das ist halt
auch sehr praktisch, weil also
das normale Psycho-PG,
das man so verwendet, kann das halt nicht und
eigentlich wäre das ja auch saukool, wenn man das
Async machen könnte und Async-PG ist auch
richtig schnell. Async auf Datenbank
stelle ich mir schwierig vor mit Transaktionen und so, weil
Nö, das ist alles, eigentlich
ist das überhaupt kein Problem. Also
Es gibt halt nur einen Warenzustand dann immer
und das ist egal
Du kannst ja auch sonst auch
Du kannst ja schon mehrere Sachen gleichzeitig machen
Nur ist es halt so, dass du normalerweise
dann halt warten musst
Du schickst halt irgendwie
Es fällt immer an die Datenbank und dann blockierst du halt
ein Code
Du machst es halt synchron
Das ändert nicht die Datenbank, Dominik
Sondern es ändert nur, wie du die Verbindung der Datenbank hältst
Ja
Aber wo wir gerade bei PsychoPG sind
PsychoPG3 ist angekündigt
und was du gerade unterwegs
die koordinieren sich
gerade mit den Django-Leuten,
dass die Datenbankverbindungen da
cooler sind. Die haben zum Beispiel
Connection-Pooling im Adapter drin.
Das ist auch eine sehr schöne, da hatte ich jetzt letztens
so ein Problem tatsächlich auch,
dass irgendwie die Connections rausgelegt
sind. Bei Django gibt es glaube ich
im Grunde zwei Arten, entweder
man macht halt eine Verbindung pro Request oder man
setzt halt das auf irgendeine Zeit oder so
und dann wird die Connection so lange aufgehalten.
Aber, und das war mir halt nicht so
und Jochen unterhalten sich über die Programmiersprache Python
Ja
Ja, aber Pooling wäre auf jeden Fall
eine schöne Geschichte, weil manchmal ist ja auch
eine Verbindung nicht genug
Ja, und generell
ist es ja gut, wenn da ein paar Verbindungen
offen sind, weil man braucht die halt doch
häufig
Ja, ansonsten, was hatte ich noch gelesen?
Es gab irgendwie einen Artikel
zu Security-Geschichten
Dependency-Conclusion
Ich weiß nicht, ob ihr den auch gelesen habt
Gab es einen Artikel zu?
Es gab da schon ein paar Artikel zu.
Dependency Confusion.
Ja, sehr deprimierendes Problem, ehrlich gesagt.
Das musst du aber denken, was ist Dependency Confusion?
Ja, da gab es doch so ein,
da hat doch eine dreieinhalbtausend Sachen bei PyPy hochgeladen, oder?
Ja.
Und genau,
das ist halt so, oft,
wenn da Leute die Version,
die sie haben wollen, nicht explizit festlegen,
dann muss man halt nur eine Version
haben, die ein bisschen höher ist.
oder wenn sie sich vertippen
genau
dann kann man das sozusagen hijacken
und dann kann man den Software installieren
die auch im Großen und Ganzen
das tut, was sie erwartet haben
was sie sich installieren wollten, aber halt auch
vielleicht ein bisschen mehr oder so
Also ein Beispiel wäre, wenn
zum Beispiel jemand eine Bibliothek hochlädt, die
Django heißt, nur ohne D vorne dran
und wenn
jemand halt dann Django installiert, das geht auch
hat auch die gleichen Versionen, aber
und macht halt gleichzeitig Bitcoin-Mining oder sonst irgendwas.
Oder Backdoors auf oder sonst irgendwas.
Man weiß es nicht genau.
Und da gab es eben so einen Vorfall, dass jemand 3.500 solche Bibliotheken auf PyPI hochgeladen hat,
die sehr suspicious waren und die dann auch wieder gelöscht wurden.
Ja, also der Artikel, den ich da gelesen hatte, derjenige, der das gemacht hat,
der hat das tatsächlich quasi auch im Auftrag von größeren Firmen gemacht.
Und der hat damit quasi alle großen Firmen aufgemacht.
und hat da auch überall
quasi das
Preisgeld dafür gekriegt,
die man halt für
Millionenweise.
Also das hat sich gelohnt.
Und das ist auch wirklich ein fieses Problem
und es gibt eigentlich nicht so,
es ist so ein bisschen doof.
Poetry könnte doch helfen, oder?
Wenn ich jetzt irgendwie die Hashes von Independent ziehe damit.
Nein, leider nicht.
Nein, warum?
Weil du ja immer noch den Namen eingeben musst
irgendwann.
Ja, aber wenn das bei einer
PyProject-Hummel schon gepinnt ist, richtig
Dann hoffe ich mal, dass du
die richtige gepinnt hast
Zum ersten Mal muss ich aufpassen, wenn ich das
eintrage, aber
Und jemand muss aufpassen
Was meinst du mit jemand?
Ja, du siehst es ja nicht, du merkst es ja nicht
Das geht ja
Das funktioniert ja, das macht ja genau das, was es soll
Nur halt irgendwann
auch noch was anderes
Und wenn du nicht gerade dann drauf guckst
Das ist ja immer das Problem mit irgendwelchen Dependencies, also wenn man irgendwie
sich sowas wie PyPy auf den Rechner holt oder Node.js
oder was auch immer und irgendwelche Pakete von irgendwo installiert, ohne genau zu wissen,
was für ein Source Code denn da drin steckt oder jedes Mal nachzugucken, ob denn da in der
neuen Version vielleicht was Falsches drin ist, dann
Ja, das Problem haben wir an vielen Stellen, das haben wir natürlich auch bei Docker zum Beispiel, wenn man sich da irgendwelche
Images sieht, wo man nicht weiß, was da drin ist. Das Problem haben wir auch bei Distributionen, aber jetzt wenn man
eine Distribution nimmt und man installiert
per Apt irgendwas bei Debian oder so,
dann kann man
ja davon ausgehen, wenn man jetzt nicht, was natürlich
auch viele Leute machen, was natürlich auch wieder so ein Ding ist,
wo man sich sagen kann, aus Sicherheitsperspektive
ist das ganz übel, wenn man da halt
irgendwelche Dritt-Repositories
sich reinholt,
kann man auch alles installieren.
Das ist den meisten Leuten vielleicht auch nicht so ganz klar.
Aber wenn man jetzt nur
die Debian-Repositories
drin hat, dann kann man ja davon ausgehen,
okay, das hat irgendeiner, der das maintained,
hat sich das angeguckt, hat geguckt, ob das die richtige
Software ist, hat daraus ein Paket gebaut,
hat das Ganze signiert und so und dann kann man sich
schon relativ sicher sein, okay, das, was da landet,
ist tatsächlich nicht irgendeine
Malware oder so. Aber welche
Python-Version haben die gerade?
Genau, das ist
das Problem.
Und diese ganzen Bibliotheken musst
ja dann auch, du kannst ja dann nicht mit Pip irgendwas installieren,
sondern musst ja dann eigentlich. Und ich
kenne solche Firmen, ich habe Kunden
gehabt, die das gesagt haben, wir wollen
keine Dependencies reinholen von irgendwoher, sondern wir wollen die Betriebssystempakete
haben und dann hast du ein echtes Problem. Ja, dann haben die doch keine Software mehr.
Viele, viele Sachen. Ja, bist halt bei Django 2. irgendwas. 1. 2.0.
Ja, aber ist doch Quatsch. Also dann mache ich doch lieber irgendeinen Server auf, der vielleicht
kompromittiert werden kann und mache dann andere Sachen sicher. Mache dann Singles
Point of Truth oder sowas und dann habe ich halt die Daten abgesichert über eine Authentifizierung.
Weiß nicht. Ja, an irgendeiner Stelle musst du
irgendjemandem vertrauen und das ist
ein Problem. Und selbst wenn es nur derselbe
ist. Und das ist meistens der größte
Fehler.
Ja, aber zum
Thema Sicherheit habe ich auch noch was sehr Interessantes gelernt.
Ihr wisst ja sicherlich,
alle die zuhören, wissen sicherlich, was
COS ist.
Cross Origin Requests
Safety? Security?
Oh,
das ist eine gute Frage, weiß ich jetzt gar nicht.
Ich weiß es auch nicht,
aber ich weiß, dass es das gibt
und ich weiß, dass das sehr gut ist, weil das bedeutet
dass man nicht einfach irgendwoher
Ressourcen abrufen kann
Resource Sharing? Ah, okay
Cross-Original Resource Sharing, okay
Das gibt es
nicht für Websockets, Websockets haben keinen Kurs
Wenn ich einen Websocket
irgendwo hin aufmache, dann kann ich darüber alles abrufen
Oh
Und das ist
Ja, genau so habe ich auch reagiert
Das war mir jetzt nicht klar
Oh shit
Aha!
Genau.
Also die Annahme ist, dass der
Server das macht, dass der den Origin-Header
überprüft und das dann halt ablehnt.
Aber prinzipiell
muss er das nicht. Im Prinzip kannst du eine Verbindung
irgendwo hin aufmachen und sagen,
ich bin der Websocket von so und so.
Und ja.
Also das ist doch so eine Sache, wenn das im Header drinstehen müsste,
macht dann nicht sowas wie
Django Channels sowas in den
Headers mit...
Das weiß ich nicht. Und das ist genau das Problem.
Und es ist auch, glaube ich, nicht die Aufgabe von
Channels, sondern es wäre eigentlich die
Aufgabe von dem terminierenden Webserver.
Und auch da
weiß ich es nicht. Und weiß ich nicht, ist in der
Sicherheitswelt...
Das ist immer, wenn es
so ganz überraschend und komisch ist,
dann ist es kein gutes Zeichen.
Auch da habe ich einen Link
gefunden, der das alles erklärt
und wie man damit umgeht und so weiter.
Damit verlinken wir einfach.
Aber ich habe zum Kurs was gelesen
in Django REST Framework,
weil die nämlich inklusive Sockets das integrieren
wollen mit Kurs.
Steht zumindest in dem Feature.
Ja gut, dann überprüfen die das halt.
Das ist ja sehr gut.
Was uns zu unserem Topic
drücken könnte, wenn ihr denn mit den News von so weit seid.
Ja, das ist nicht mehr viel.
Tatsächlich
jetzt hatten wir auch schon mal, da waren wir ein bisschen
voreilig, irgendwie hatten wir ja schon
30 Jahre Python gefeiert, so der offizielle
30 Jahre Dings, das war
vorletzte Woche oder sowas.
Letzte? Ich weiß nicht mehr genau.
Da müsste man jetzt ein Glas Sekt aufmachen.
Ja, müsste man jetzt eigentlich.
Ja, ist jetzt Python offiziell 30 Jahre draußen.
Hurra!
Dann ist es ja älter als ich.
Ich wollte sagen, genau.
Ich hatte mir mein Geld geklaut.
Entschuldigung, Dominik.
Dann ist es ja älter als Dominik und ich.
Ja, es gibt noch ein zweites.
Ich habe noch einen Versuch für den Witz.
Es gibt ja noch ein zweites Jubiläum.
die Python Software Foundation ist 20 Jahre alt geworden.
Und die
ist dann ja älter als ich.
Okay, verdammt.
Das funktioniert nicht beliebig
nach unten.
Wir nehmen dir alle ab, dass du erst 19 bist, Jochen.
Die ganzen Geschichten, wo du
über Computerspiele aus den 90ern erzählst,
das ist alles nur, was du gehört hast,
was du gelesen hast.
Genau.
Das ist eine Tarnung.
Ja, wenn man letzten Montag in einem Schaltjahr geboren
worden wäre, dann hätte man tatsächlich das Problem gehabt,
und Jochen unterhalten sich über die Programmiersprache Python
Du hattest mir, Johannes, glaub ich mal
so einen Link geschickt auf so einen Benchmark
Ja, oh
Da arbeiten wir jetzt auch schon eine Weile
dran, Jochen
Ja, und genau, da ging
auch über Hacker-News und dann
war es irgendwie, war da auch bei Python-Bytes drin
und so und da ging es darum
da hatte ja jemand irgendwie, weiß nicht genau
was da, also da ging es halt um
Jemand hat irgendwas gebenchmarked
Und das Einzige, was ich dazu im Grunde
nur anmerken wollte, also
also
mit so einem Körnchen Salz
sollte man da vielleicht
mit dazu tun.
Also du sagst, man müsste das mal selber machen.
Das ist das, was ich da raushöre.
Genau.
Ich könnte das bestimmt fortsetzen.
Lügen, dreiste Lügen.
Haben kurz...
Nee, halt, warte.
Benchmark.
Aber ich glaube, das ist mal
eine eigene Episode, oder?
wenn wir mal über diesen Benchmark sprechen, den wir
jetzt schon seit drei Monaten in der Mache haben.
Achso, ja.
Wir wollen beweisen, dass Python
die schnellste Sprache ist unter der Sonne.
Nee, aber vielleicht schnell genug.
Wir wollen beweisen, wie man damit schnell
sein kann.
Oh, das ist ein Thema
für eine eigene, ich glaube, da brauchen wir wirklich
Dann machen wir eine eigene Geschichte zu.
Okay, ich wollte nur sagen, also wenn man
jetzt diesen Artikel sich anguckt, vielleicht nochmal
also wenn man es wirklich wissen will,
muss man es selber messen.
und ja, also
es ist nicht so ganz einfach, also zum Beispiel
eben bei dem Artikel, dass ich es dann so angucke,
wie wenn da so
HTTP-Doodles oder
bei Scenic ist das dann installiert und im anderen
nicht und HTTP-Parsing kann ja dann
das Nadelöhrer, also ich will gar nicht
anfangen davon, stimmt,
da machen wir mal irgendwann, wenn wir Ergebnisse haben,
aber ja,
Benchmark ist alles nicht so einfach.
Man kann nur so viel verraten, wir haben extra
VMs bei einem Hoster gekauft,
um genügend Bandbreite und alles zu haben
und wir haben sie bisher nicht gebraucht.
Ja.
Gut.
Ja, gut.
Jetzt dachte ich, Entschuldigung, jetzt müsst ihr mir das erzählen.
Jetzt bin ich sonst die ganze Zeit neugierig.
Jochen hat einfach schon sehr viele Dinge ausprobiert
und wir haben es bisher nicht geschafft,
so viel Bandbreite zu verbrauchen,
dass wir mehr Bandbreite,
also dass wir
ein Netzwerk sinnvoll
benutzen hätten können.
Also das war das mit dem Gigabit, was du nicht kriegst
ausgelastet.
Was war die erste Teil, Jochen, die du hattest?
Was war dein erstes Ergebnis? Wie viele
Kilobit hast du?
Schon ein paar Megabyte pro Sekunde,
aber halt noch...
Weit entfernt.
Ja, ist noch nicht da, wo es hin muss.
Ja, also es geht darum, dass halt die Konkurrenz von
Python-Web-Applikationen
oder was ging's?
Nee, also das Ziel da war es eigentlich rauszukriegen,
braucht man sowas wie ein Nginx eigentlich noch davor
oder kann man das nicht einfach alles jetzt wo,
in der schönen neuen Async-Welt, so alle gut,
ich meine, das ist halt irgendwie so eine Tradition
geworden, dass man da halt irgendwie fürs File-Serving
irgendwie ein Nginx davor hat oder das halt
über einen CDN macht.
Ja, oder das halt irgendwie von Amazon machen lässt
oder so, das ist halt irgendwie so, das macht man halt so.
Die Frage ist, gibt's dafür eigentlich
jetzt noch so einen Grund, weil tatsächlich
kann man ja mit Async und der ganzen Wintergut
und den ganzen schönen Dingen, die es jetzt alles gibt,
Also man könnte das ja eigentlich auch selber machen
Die Frage ist halt nur, ist das schnell genug?
Also wenn ich jetzt 100 Gigabit saturieren möchte
Hm, okay, dann
nehme ich vielleicht doch was anderes
Aber wenn
ich jetzt sowieso relativ
wenn ich jetzt sagen wir mal nur so ein Gigabit habe oder so an einem Server
Dann kann es ja sein, dass es
völlig egal ist, ob ich NGTX nehme oder
irgendwie Python, weil es ist schnell genug
Und Gigabit ist ja heutzutage eigentlich gar nicht mehr so wahnsinnig
viel, vielleicht reicht es ja
Und das hört ihr weiter in unserer Webseite
Genau, dann haben wir das ein bisschen
ange teasert, aber genau. In der Benchmark-Episode.
Ja.
Genau. Wir wollten nämlich noch eine
Datentypen-Folge machen, die haben wir auch noch aufgeschoben.
Nur für alle, die sich dann überräumen.
Ja.
Ja, okay.
Ja, ist eine spannende Sache.
Da gibt es viele schöne Dinge.
Ich habe noch was zum Thema Web-Server.
Habe ich kürzlich gefunden. Fly.io.
Habe es noch nicht selber
ausprobiert, aber das scheint so ein bisschen
wie das developerfreundliche
Heroku zu sein.
Mit einfachem
Deployment überall.
Wo man
quasi einfach Docker-Container hinschickt
und die lassen wieder laufen, wo man sie haben möchte.
Das sah sehr gut aus auf den
ersten Blick und der hat auch sehr viele
schöne technische Artikel geschrieben.
Also es hat mir gut gefallen.
Ich habe noch keine Gelegenheit gehabt, das auszuprobieren,
aber ich habe mir vorgenommen,
das auszuprobieren.
Sehr cool, weil da gab es mich, das habe ich heute irgendwann gehört,
glaube ich,
auch eine neue Episode vom Django Chat Podcast,
wo Peter Baumgartner
von Lincoln Group,
der auch dieses High-Performance-Django-Buch,
der hat das, glaube ich, geschrieben
und der hat auch so ein Ding
gebaut. Ich meine, Heroku
ist ja auch immer so die Empfehlung für, wenn man sich keine Gedanken
machen möchte, aber Heroku
ist halt auch... Und viel Geld hat.
Und viel Geld hat, ist halt recht teuer und es ist halt auch
so, dass deren...
Es ist doch eher so Ruby und Rails-Ding und deren
Django Support erfährt jetzt nicht immer unbedingt die Liebe, die man jetzt sich erhoffen würde, vielleicht von so einem Hoster.
Um es mal so vorsichtig zu formulieren.
Und der hat halt jetzt auch sowas gebaut, nämlich das nennt sich Uppack.io und ist halt auch im Grunde sowas wie Heroku.
Also sozusagen, du kannst deinen Kram auf AWS hosten, nur halt mehr so auf Django optimiert und so.
Aber cool, ja, ist schön zu sehen, dass es da mehr Optionen gibt.
Spannend, dass es so viele Firmen
im indischen Ozean gibt, das ist schon
sehr cool
IO ist für den indischen Ozean
Achso
Ja, der indische Ozean hat mal
ausnahmsweise mal was richtig gemacht
mit der Wahl des Problems
Ja, Glück gehabt
Glück gehabt
Ja
Pack IO sagst du, Jochen
du tust uns den Linker sicherlich
Genau, Uppack mit 3P.
Das ist ein bisschen schlecht vielleicht, ich weiß nicht genau.
Naja, aber genau, ich tue den Link in die Shownotes,
dann kann man sich das angucken.
Ja.
Jetzt haben wir nur noch Reste übrig, oder?
Ja, jetzt haben wir nur noch Reste übrig.
Es ist nur noch der Rest.
Dann müssen wir jetzt über die Reste reden.
Ja.
Also, wo waren wir eben stehen geblieben, Johannes?
Representationist?
Ja, im Vergleich zu Remote Procedure Call.
Also ich meine, Remote Procedure Call,
das ist so die Technologie, die man kennt
und das ist so ein bisschen so die
Sache, die man halt machen möchte, wenn man
sagt, okay, ich habe jetzt hier ein Programm geschrieben und das ist
lokal, aber es wäre doch viel cooler,
wenn das irgendwo anders laufen würde.
Und dann macht man sich
halt irgendwie so ein Endpoint, wie auch immer,
der geartet ist, ja.
Java, XML,
LPC.
Klar, das ist das Erste, was mir jetzt in den Gedanken kommt.
Ja, das hatten wir auch.
Sprich es ruhig aus, so wie es früher war,
das SOAP zum Beispiel.
Ja, das hat man früher einfach so gemacht.
Und das ist dann im Wesentlichen halt eine Java-Bibliothek, die man sich einbindet,
die Funktionen anbietet, die aber nicht lokal ausgeführt werden, sondern remote.
Und das können alle möglichen Funktionen sein.
Die können was berechnen oder die können eine Datenbank abrufen
oder die können einen Roboter starten oder die können die Kamera oder keine Ahnung,
irgendwas können die machen.
Und das siehst du denen aber erstmal nicht an, weil die eben so gepackt sind,
eben gerade diese Java XML LPC
die macht dann eine Java-Klasse
und wenn ich da alle Verbindungsdaten reingegeben
habe richtig und mich korrekt verbunden
habe, dann funktioniert die wie eine lokale Funktion.
Und das ist ja auch so ein bisschen das,
was im Namen steckt. Remote Procedure Call
heißt einfach, es gibt
normale Funktionen, also normale
Prozeduren und es gibt Prozeduren, die sind auf einem anderen
Rechner. Und
das ist das was man fr gemacht hatte und das war ganz ganz schlimm Das war ganz ganz schrecklich Warum Weil es hat nicht funktioniert und man wusste nie was dann das Ergebnis ist und wie lange das dauert und man hatte quasi gar keine Garantien gar nichts und diese Interfaces bauen war auch ganz schrecklich
und Jochen unterhalten sich über die Programmiersprache Python
Also ich weiß es natürlich nicht, ich war nicht dabei, aber ich denke, dass das eben der Grund war, warum man zu REST APIs oder einer der Gründe, warum man zu REST APIs gegangen ist, wo es eben nicht darum geht, Prozeduren aufzurufen, also wo man nicht sagt, mach irgendwas, sondern wo man im Endeffekt nur sagt, entweder gib mir ein Objekt oder nimm dieses Objekt.
Könnte man ja vielleicht auch so formulieren, dass man sagt, man versucht einfach die Dinge, die im HTTP-Protokoll eingebaut sind, auch tatsächlich zu benutzen, so wie sie halt
schon da sind und nicht
weil das ist halt eigentlich glaube ich auch der Vorwurf
sozusagen von Restseite, die man
an so Sachen wie Soap oder auch
Sachen, wo dann andere Leute versucht haben, Korba
irgendwie zu retten
in der Webwelt, macht, dass man sagt, ja
ihr habt hier so ein altes, überholtes
Architekturmodell, von dem wie
eure verteilte Anwendung funktionieren soll
und jetzt versucht er jetzt,
das Web zu degradieren, dass das nur
ein Transport-Layer ist für eure Idee,
die auch schon vorher eigentlich
nicht funktioniert hat.
Was war in Form war?
Da gibt es eine
schöne Organisation mit dem Kürzel
OMG.
Oh mein Gott.
Common Object Request Broker Architecture.
Genau, und die hat das
standardisiert. Das ist die Object Management
Group.
Ich hatte auch
Ich hatte viel Spaß mit Cobra
schon
und ja, das war
das war
auch alles nicht schön.
Das klang alles nach einer guten Idee
und dann hat man es versucht
zu verwenden
und dann sind schreckliche Dinge passiert.
Ich meine, vielleicht haben Leute das auch verwendet
und es war voll cool, aber
ich erinnere mich an große Schmerzen.
Okay, und in
HTTP selbst ist dann sowas eingebaut
wie, gib mir ein,
oder bekommen ein Objekt.
ein, zwei andere, die da wichtig sind. Es gibt noch
Put und Delete, die immer wieder
notwendig sind.
Ja, aber
gerade da fängt es dann schon so an. Was ist eigentlich der Unterschied
zwischen Put, Post und Patch?
Ich weiß es nicht. Ich würde sagen, spontan
wäre es so, Put, da
updatest du ein komplettes Objekt
und Patch nur ein Teil davon. Also wenn du
sozusagen nur ein Attribut an einem Objekt änderst,
dann machst du das per Patch. Wenn du das Objekt
in einer Version
änderst, dann puttest du das komplett.
Und Post?
Post es hinzufügen.
Ja, aber das ist ja auch nicht so.
Das ist ja bei REST auch nochmal anders geregelt.
Das ist ja, wenn du auf eine ID postest,
puttest, dann ist es ein
neues Objekt mit dieser, wenn es die
noch nicht gibt, dann ist es neues und wenn du auf eine
Ja, so ganz klar.
Ja, ehrlich gesagt
weiß ich auch nicht. Also braucht man nur noch zwei.
Get und Post.
Ja, das ist halt das, was viele Leute machen. Mit denen kommt man zurecht.
Mit denen kommt man schon zurecht, aber das ist
natürlich. Delete brauchst du noch, Dominik.
Delete brauchst du für den Körner. Na gut.
Man kann nicht posten und sagen, das Objekt bitte entfernen.
Du kannst, nee, weil du kannst auch, du kannst posten, das kommt jetzt drauf an.
Und da fangen schon so ein bisschen die Probleme bei REST an.
REST besteht ja aus mehreren Teilen und ein Teil ist eben, benutze nur diese HTTP-Werben.
Und da fängt eben das, eins der Probleme schon an.
eine der Konventionen ist, wenn du
auf den Pfad
eines Objektes postest
und nur eine gewisse Menge
von Attributen mitgibst, dann heißt es
ändere bitte diese Attribute
wenn du jetzt sagen würdest, wenn ich
darauf poste, ohne ein Attribut zu geben
dann hat es schon zwei Bedeutungen
hat es entweder die Bedeutung, die du jetzt sagst, nämlich
lösche dieses Objekt, also entferne
alle Attribute, oder es hat die
Bedeutung
ändere kein Attribut.
Und weil das nicht offensichtlich ist, ist es einfacher Delete zu nehmen.
Delete ist eindeutig.
Und Delete ist eine von den Sachen bei REST, die völlig unstrittig sind.
Wenn ich eine URL habe, wenn ich einen Pfad habe, der zu einem Objekt gehört
und ich mache da Delete drauf und ich darf das und da kommt der richtige Status zurück,
dann ist es gelöscht.
Das ist völlig unstrittig und das ist auch eine super Sache,
weil ab jetzt brauchen wir ums Löschen
Das geht immer.
Was dafür sprechen würde, dass man Post nicht löscht?
Nein.
Genau, mit Post löscht du nie.
Post und Put und Patch sind immer nur
Additiv.
Okay, aber den Unterschied da genau zu verwenden
ist wahrscheinlich, wie man gerade schon rausgehört hat,
eher vielleicht gar nicht so.
Ja, man findet auch ganz viel
tatsächlich in freier Wildbahn und halt Leute, die irgendwie das halt anders machen, als man das vielleicht tun sollte.
Ja, und wir werden sicherlich auch hier ganz viele Kommentare kriegen, dass wir alle Idioten sind und dass es nur eine wahre Lösung gibt.
Ja, da kommt dann die Response zurück, 402.
Nee, 201 kommt dann zurück. 201 heißt Objekt erzeugt.
Ja, und ich meine, ich sehe immer, wenn ich irgendwie, also es gibt, wenn ich mit anderen APIs rede, ist es ganz oft, dass ich irgendwie was erzeuge und dann kommt halt 200 zurück zum Beispiel, was halt falsch ist oder
Ja, aber kann auch sein, kann auch sein
Ja, kann auch sein, weil 200 bedeutet ja nur okay, 200 bedeutet ja nur in Ordnung
und Jochen unterhalten sich über die Programmiersprache Python
Ja, das ist so ein Problem.
Auch das ist so ein Problem, wenn man auf 201
wartet und erwartet, dass das Subjekt
zurückgegeben wird,
dann kommt ganz oft
gar nichts zurück und dann schlägt
quasi diese Abfrage fehl, weil
kein Content kommt.
Auch damit habe ich
mich schon abgeplagt.
Ja, ja.
Na gut. Ich verpake mich immer
mit dem 402 ab.
und was war das nochmal?
Payment required.
Payment required, ja.
Reserved for future.
Nee, der wichtigste ist doch 418.
Ja, T-Pod war das, oder?
Armer T-Pod, ja.
Ja, genau.
Also ich meine, tatsächlich in der Praxis
funktioniert es meistens ja eigentlich ganz gut.
Man kann sich da irgendwie durchwurschteln
und dann geht es schon.
Und genau.
Tatsächlich ist aber auch,
dann gibt es ja so,
und
Doktorarbeit. Hat er seine Dissertation drüber geschrieben. Ja, genau. 2005 ist sie, glaube ich, erschienen.
Und da
kann man sich angucken. Gibt es online, auch als Webseite.
Sehr schön.
Oh, auch sehr interessant. Link, please.
Ja, genau. Link kommt nicht schon.
Auch sehr interessant.
Die Dissertation fängt an
und endet jeweils mit einem Zitat von
na, wie heißt er noch?
Der Architekt mit den
Entwurfsmustern.
mit den Entwurfsmustern
mit den Patterns
angefangen hat, genau
Christopher Alexander glaube ich
und genau
naja, also es gibt da interessante Verbindungen
und
der
also in dieser Dissertation beschreibt er halt sozusagen
was so ein bisschen die Idee hinter dem Ganzen ist
und dass eigentlich er sich wünscht
dass halt sozusagen
das hat eine etwas komische Abkürzung
dass sozusagen
Hypermedia as the Engine of
...
Genau.
Moment, wie war das?
HatoS.
HatoS, genau.
ApplicationState, genau.
Hypermedia as the Engine of ApplicationState, genau.
Richtig. Das ist lang und kompliziert
und komisch. Und was heißt das? Was ist das? Was macht das?
Naja.
Das würde ich jetzt auch gerne mal sich nachholen.
Weil das hätte ich genau wissen müssen.
Sollte man sich nochmal diese...
Also tatsächlich finde ich das beste Beispiel dafür, wie das funktionieren kann, ist halt das Web.
Dass man sagt, also da ist das Hypermedia, was man halt sieht, ist das HTML und du kannst da halt dann Links folgen und siehst dann halt neue Sachen, neue Webseiten und so und kannst dann Dinge machen und sozusagen wie deine Applikation, also deine Webseite aussieht, bestimmt das Hypermedia da drin.
Das ist jetzt aber nicht so, wie die meisten Leute
REST-Schnittstellen verwenden, sondern die meisten
verwenden das halt zum Beispiel, jetzt weiß ich nicht,
was halt viele machen, als
Datenlieferant für ihre Single-Page-App
Aber die Single-Page-Apps,
die es so gibt, die sind eigentlich so gar nicht
REST
Und die sind auch, was das Hypermedia-Ding angeht,
eigentlich
ist das auch wieder so ein Ding,
was sich aus einer alten Welt rübergerettet hat
Insofern, ich bin mal gespannt, wie es ausgeht
Es kann ja auch sein, dass sich das dann durchsetzt
aber tatsächlich
also ich finde ein wichtiger Punkt
so bei dem, diese Single-Page-App ist eigentlich
voll cool und so, man kann damit tatsächlich ja
Applikationen bauen, die so ein bisschen wirken, als
wären sie Desktop-Applikationen so wie früher
aber
wenn man sich jetzt vorstellt, man will ein Web
draus bauen und jetzt hinter jedem Link liegt
so eine Single-Page-App, wo erstmal ein paar MB
Zeug kommen
dann ist das ja eigentlich
gar nicht so gut
also
Stau auf der Datenautobahn
Das macht das Web halt irgendwie kaputt
Das macht es halt, es ist halt nicht so
also so eine Single-Page
Single-Page ist eigentlich auch ein falter Name, aber
diese JavaScript-Applikationen
die halt nur RPC quasi
zu einem Server machen
die sind halt eine in sich abgeschlossene Applikation
und wenn man da, wenn alle Webseiten
nur noch so etwas wäre, dann würden Links
Also wenn man nicht sehr viel Arbeit macht, meinst du
Weil gute
SPAs haben natürlich
Ja klar, Server-Side-Rendering
und den internen Zustand,
wo du auch Deep Links machen kannst auf SPAs.
Aber das ist nicht so
gängig, um es mal so zu sagen.
Was ist jetzt ein Deep Link wieder?
Wenn du so eine SPA aufrufst,
dann bist du ja auf
spa.io
und dann gehst du da
in deine Daten rein und
in die Tabelle und dann gehst du da
in Zelle A17.
Und ein Deep Link wäre,
wenn es eine Möglichkeit gäbe,
eine URL anzugeben, die auf diese
und Jochen unterhalten sich über die Programmiersprache Python
das Problem an dieser Stelle ist, du kannst nicht
darauf verlinken, du kannst nicht sagen
das hier und jeder der es abruft
sieht es dann, wenn er es sehen darf
immer Modulo dieser
Berechtigungen
und der Sichtbarkeit und so weiter
und das ist ja aber eigentlich eine Sache, die
in REST APIs schon so
drin sein sollte, dass du zum einen
Links machen kannst auf
Objekte, also
API slash
Spreadsheet
spreadsheetid
table
cell
row17, irgendwie sowas.
Solltest du prinzipiell machen können
und auch innerhalb dieser API
solltest du eigentlich nie
irgendwie nur IDs angeben.
Das ist jetzt dann hier,
da ist der Inhalt 23
drin, sondern eigentlich solltest du
angeben, da ist der Inhalt drin,
der unter folgender URL erreichbar ist.
Und wenn man
Wenn man das sauber macht, dann ist das eine ganz, ganz mächtige Sache. Ich versuche das bei meinen APIs immer zu machen, weil das die Entwicklung mit der API wesentlich vereinfacht, weil ich eben nicht wissen muss, was das bedeutet, wenn da drin steht ID 17, sondern ich muss nur einen Link aufrufen können und einen Link aufrufen, das kann ich.
Das geht, genau. Dann kriegst du das Objekt und weißt, was da drin ist.
Genau. Und dann kannst du auch weitergucken.
Ja, aber tatsächlich eben, genau, und das ist halt so der Unterschied, wenn man jetzt RPC machen würde oder so, wenn du jetzt da irgendein Objekt kriegst mit bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm
hat es einmal geklappt, aber ansonsten
also irgendwelche Applikationen,
die ihr UI dadurch
aufbauen, dass die irgendwie
aus einer API irgendwie
ihre Formulare bekommen und das
Das hört sich ja grauenhaft an.
Genau, das hört sich schon ziemlich grauenhaft
an, ja, das klingt so ein bisschen nach SAP,
irgendwie alle Sachen sehen irgendwie gleich aus
und so.
Alles zur Laufzeit wird das zusammengebaut.
Ja, also ich meine, es wäre natürlich schön,
also der Vorteil, den du halt hast, wenn du das machst,
ist halt, dass auch ältere Browser
funktionieren können. Du musst halt nicht immer
irgendwie den Client austauschen
und gerade wenn du jetzt App-Stores hast oder so,
wäre es natürlich auch nett, wenn du, wenn Leute
mit alten
Client-Anwendungen halt auch deine neue
Geschichten benutzen können und
du sozusagen mal so ein bisschen Progressive Enhancement machst
und die neuen Geräte können
dann halt den neuen Kram machen und die alten sehen aber
immer noch die alte Seite sozusagen.
Tatsächlich glaube ich aber, dass das praktisch
niemand so macht.
Ja.
auch ungeheuer schwierig, das zu machen,
weil die Interna verändern
sich ja auch. Also ich meine,
wir können auch gerne mal noch ein
Stündchen über API-Versionierung sprechen,
weil auch da geht es von uns
eine Meinung dazu.
Und ich weiß auch mindestens drei verschiedene
Wege, wie man das machen kann.
Aber
ja,
ich kenne quasi keinen Fall, wo
es sich lohnen würde, verschiedene API-Versionen
gleichzeitig laufen zu haben, was ja sehr
teuer ist erstmal.
Und deshalb, das mag ein
heroisches Ideal sein, aber es ist vielleicht
schwierig, das in der echten Welt zu machen.
Du müsstest nicht unbedingt
unterschiedliche API-Versionen, sondern du würdest es halt so machen
wie bei HTML auch. Du würdest halt sagen, okay,
hier ist halt ein Attribut und da steht halt
an dem Attribut noch dran, weil wenn du das in JSON
machst, nicht in HTML, so ab hier
nur für Clients mit der Version oder so,
keine Ahnung, die anderen müssen hier gar nicht gucken, die können das
nicht.
Ja, okay, aber dann hast du ja unterschiedliche
API-Versionen, die halt additiv sind.
Ja, aber du würdest auch dem alten Client
das Neue ausliefern und der würde es dann einfach
ignorieren und dann sagt, oh, das ist für mich nicht interessant.
Also wie bei HTML ist es ja auch so,
wenn du ein neues Tag hast, die Browser ignorieren das einfach,
die es nicht können. Ja, oder auch Header
generell. Das ist generell eine gute Idee,
so additive,
nur die Sachen verarbeiten, die man versteht.
Also nicht generell, aber in
vielen Fällen ist das eine gute Idee,
weil man dann eben diese
automatische Backwards-Compatibility
hat oder automatisch Vorwärts-Compatibility,
je nachdem, wie man das sehen möchte.
Ja.
Also irgendwie, also
die Idee ist irgendwie voll cool, aber
ehrlich gesagt, ich weiß nicht so richtig. Ich bin mal
gespannt. Also bei
jetzt HTML und Web hat es ja eigentlich mal
geklappt, aber ob das
wie sich das so in Zukunft entwickelt, keine Ahnung.
Ja, und andere Dinge
sozusagen sind auch nicht mehr
so richtig gut gealtert, fürchte ich. Also so was
wie zum Beispiel, also eigentlich
das sind schon nette Ideen, also das
HTTPS-Dateless ist ja eigentlich cool, das hat
diverse coole Vorteile, dass
GET halt immer nur irgendwas
an Daten liefert und nichts
ändert, ist auch super cool, weil das bedeutet halt, du kannst
super cachen. Ja, und kannst
darauf so oft machen, wie du willst. Kannst du so oft machen, wie du
willst, voll gut. Das Problem ist nur,
so inzwischen ist halt
TLS,
HTTPS ist halt überall.
Sollte man auch nicht mehr ohne
machen. Ja.
und damit wird das mit der Cachebarkeit und so, das ist halt dann alles so ein bisschen für die Tonne, weil, ja gut, der Browser selber kann es noch Cachen, aber so, dass da irgendwo Der Server kann es Cachen.
Der Server kann es Cachen, der Client kann es Cachen, aber dazwischen kann es nicht.
Und ja, damit hat das nicht mehr so eine riesig große Relevanz und das war ja auch in die, ja, das sieht man jetzt auch heute ja, die ganzen, so, ja, Phoenix Live View,
bei Ripple und Melz gibt es das mit Stimulus und
diese ganzen Hotwire-Geschichten. In anderen
Frameworks kommt das jetzt auch, dass man wieder HTML über WebSockers schickt oder so.
Und einer der Gründe, warum man das anfängt zu machen oder so, ist halt auch, dass es einfach,
wenn man sich anguckt, was auf der
Leitung passiert, der totale Wahnsinn ist.
Weil HTTP stateless ist, muss da halt immer
irgendwie alles mitgeschickt werden,
weil, naja, ist ja stateless.
Ja klar, weiß der nicht, was der schon hat oder nicht.
Genau, und das
ist eigentlich total
ineffizient auch, hätte ich gesagt.
Und deswegen gehen halt dann viele Richtung,
ja, nehmen wir doch einfach WebSocket oder so,
da ist es halt dann nicht mehr stateless.
Ja.
Ja, das ist aber auch so eine der,
jetzt sind wir schon so weit,
dass wir über die Nachteile von REST-APIs
sprechen.
dass diese Objekte so ein bisschen in sich geschlossen sind und auch nicht auf den Anwendungsfall eingehen können
das ist ja eine der Vorteile von RPC, dass du halt sagst, ich möchte, dass folgende Operation passiert
und dafür sind die folgenden drei Werte notwendig und dann kriegst du eben die Ergebnisse der Operation
und es sind dann genau sieben Werte oder so etwas, oder genau dieses Objekt und genau dieses Objekt
und das hast du jetzt mit REST ja nicht mehr so einfach, mit REST greifst du ja immer quasi auf ganze Ressourcen zu
oder eben auf Teilressourcen,
die dann vom Server auf eine gewisse Art und Weise zur Verfügung gestellt werden,
die aber eventuell gar nichts mit deinem Use Case zu tun haben.
Also wenn ich jetzt meine gesamte Freundesliste abrufen möchte,
dann müsste ich prinzipiell alle Links zu meinen Freundesobjekten abrufen
und dann allen Links folgen und jedes Freundesobjekt einzeln abrufen,
damit ich meine Freundesliste anzeigen kann.
was ja absurd ist, weil meine Freundesliste
ist ja einfach nur
eine Liste von den Namen der Freunde
und fertig.
Ja, ja.
Ja, ich meine,
man würde sich dann halt vielleicht wünschen,
eben auch gerade, wenn man dann jetzt unterschiedliche Clients hat,
die unterschiedliche Sachen darstellen,
dass man als Client kontrollieren kann, was
dann da kommt und das je nachdem,
was man halt braucht.
Aber dann hat man im Grunde
keine Restschnellschwelle und dann hat man
irgendwie sowas wie eine Datenbank
Schnittstelle. Ja, genau.
Und das ist ja auch der Grund, warum
es diese Weiterentwicklungen gibt,
die du jetzt gleich erklärst.
Genau.
Wo der Client eben
kontrollieren kann, welche Attribute
geschickt werden und welche Objekte geschickt werden.
Weil es eben Use Cases
gibt, in denen nicht
das ganze Objekt interessant ist und
oder sehr viele verschiedene Objekte
interessant sind. Ja, nur
dann würde, also aus der Sicht eines Restpuristen
würde ich jetzt sagen, ja gut, aber
da macht der Client ja schon viel zu viel.
Das hat den Client alles nichts anzugehen,
das muss alles der Server machen.
Da hat der
Client viel zu viel State und
der ist ja, ja,
und das geht ja alles gar nicht.
Ja, aber das ist ja, also ich meine,
das ist ein bisschen unrealistisch.
Gegen Regen argumentieren.
Es ist schlecht, dass es Regen gibt
und der fällt aus dem Himmel runter
und der macht alles nass, aber es ist halt so.
Ja, ja.
Das gibt es halt
Es ist nicht schwer sich vorzustellen, dass es Leute gibt
die ihren Freunden Nachrichten schicken wollen
und schon brauche ich eine Liste der Leute, denen ich Nachrichten schicken kann
Da hilft mir aller Rest Purismus nichts
weil das müsste dann irgendwie abdecken
Es gibt auch Fälle
Sagen wir mal so, um es positiv zu formulieren, für manche Anwendungsfälle braucht es ein bisschen Umdenken von diesem Prozeduraldenken.
Wir als Programmierer haben ja oft so ein prozedurales Denken. Ich möchte, dass jetzt irgendwas passiert und deshalb rufe ich diese Funktion auf.
In Python ist ja im Wesentlichen alles, was man macht, irgendwelche Funktionen aufrufen und innerhalb der Funktionen passiert dann irgendwas anderes.
und das ist jetzt bei REST ganz anders.
Bei REST sage ich einfach nur, es soll dieses Objekt geben.
Mehr kann ich ja nicht sagen.
Und wenn ich jetzt eben möchte, dass was passiert,
zum Beispiel, dass eine Nachricht geschickt wird,
dann sage ich nicht, schicke diese Nachricht an,
sondern es soll eine Nachricht geben,
die an deren Empfänger folgender Empfänger ist
und deren folgender Text ist
und deren Absendedatum
gerade jetzt ist.
das erfordert ein gewisses Umdenken,
wenn es eben was inhärent
Aktives ist, was passiert.
Bei Nachrichten schicken ist es schon,
könnte man schon sagen, okay,
das ist jetzt nicht was, was passiert, sondern es ist halt
ein Eintrag in der Datenbank und ich sage,
füge dieses Nachrichtenobjekt
hinzu. Aber wenn das irgendwas ist,
was steuert, wenn ich
und Jochen unterhalten sich über die Programmiersprache Python
Das ist so ein bisschen, ja...
Es erfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordford
anschalten
Wunschobjekt oder irgendwie sowas.
Dass du sozusagen Funktionen als
Objekte siehst und dann eben ein neues
Funktionsobjekt erzeugst.
Aber das ist ja schon ein bisschen beschummelt, oder Jochen?
Fühlst du dich da gut dabei, wenn du sowas machst?
Nee, auf der anderen
Seite würde ich sagen,
worauf es hinausläuft, die grundsätzlichen
Operationen, die man tun kann, sind halt
das ist mal, ich weiß nicht, das hatten wir bestimmt auch schon mal
ein paar Mal erwähnt oder so, ist halt CRUD.
Create, Read,
Update, Delete.
und ich finde es immer wieder erstaunlich, was sich alles darauf mappen lässt, weil tatsächlich...
Ja, alles, du kannst alles darauf mappen.
Ja, ja, gut, aber...
Alles, was in dem Computer drin ist, kannst du darauf mappen.
Es geht sogar halbwegs elegant, also oft ist es tatsächlich so, dass es auf den tatsächlichen Anwendungsfall eigentlich ganz gut, also oft passt es einfach ganz gut und man ist eigentlich dann zufrieden.
Gut, dann natürlich in manchen Spezialfällen, da muss man halt dann überlegen und tricksen, weil es dann so nicht einfach geht, ja.
aber prinzipiell
ja
das ist auch immer etwas was man
es gibt schon so Sachen
wo ich mir da sehr schwer tue
wo eben was passieren soll
wo mein gedankliches Modell nicht ist
da wird ein Datensatz
erzeugt oder bearbeitet sondern
da soll jetzt etwas passieren
ich schicke ein Bild an eine
Bilderkennungs-API dann ist es für mich nicht
ich möchte dass es
und Jochen unterhalten sich über die Programmiersprache Python
Prozedurale.
Ein Funktionsobjekt
mit folgenden Parametern wurde angelegt.
Ja, das ist natürlich
irgendwie... Also ja, nee,
es gibt Dinge, die da nicht so gut reinpassen.
Ich weiß gerade so was wie,
wenn man jetzt Blobs hat, eben Bilder oder so was.
Da
ist es sowieso schwierig.
Genau.
Ist ja auch dann ganz schwierig.
Das kriegst du ja auch nicht per Get.
Natürlich.
natürlich. Du kriegst es auf jeden Fall nicht mehr bei JSON.
Du musst dann halt, wenn du so ByteRange
verpasst, ob du irgendwelche Blobs machst, dann...
Moment, wenn du über ByteRange denkst,
also ein Blob ist irgendwie eine Art Dateiobjekt
oder sowas. Ja, also zum Beispiel
so was wie eine Podcast-Episode. Ein Binary Large Object.
Ja.
Also eine Podcast-Episode und du willst jetzt
eine Minute drei anfangen zu h weil da beginnt der interessante Teil REST Aber das ist ja tats bei REST nicht
vorgegeben, welche Daten
Strukturen du verwendest, sondern ganz im Gegenteil.
Jeder Request soll ja immer einen
Media Type haben und dann halt
kannst du es in verschiedenen Sachen abrufen.
Also REST ist gar nicht nur JSON.
Nee, nee, kann auch was anderes.
Kann auch XML sein.
Wenn du willst.
Hurra!
Aber das ist ja eine der Eigenschaften vom Web,
dass das Web eben nicht nur
JSON übertragen kann, sondern es kann alles übertragen.
Und das soll hier eben auch mit
reingehen und das ist auch eine der großen
Stärken, die zum Beispiel in Django
hat man ja diese wunderbare
Bibliothek Django REST Framework.
Ich erinnere mich noch, als ich die
zum ersten Mal gefunden habe und es war so
eine Offenbarung, dass
sowas geht und dann so schöne
Schnellstellen macht und die einen ganz
einfachen Trick verwenden, Browser
senden als Media Type
oder als Preferred Media Type
immer Application HTML mit
und
so Schnittstellen haben ja normalerweise
Application JSON
und wenn du
aber Application HTML
abrufst von dieser mit
Django REST Framework erzeugten Schnittstelle, dann
kriegst du das Ergebnis als
Webseite.
Mit allen Bells und Whistles, die es so gibt, also mit
Formularen und mit Login
Anzeige und mit Dokumentation
automatisch angezeigt und das ist eine super Sache.
Du kannst verschiedene
Media Types anfordern.
Und auch Juggeress Framework stellt ja durch diese
Serializer, die man normalerweise hat,
das ist wie das Formular, was man
sonst so kennt. Genau, der stellt
dieses Formular zur Verfügung, der stellt auch
den JSON-Datentyp zur Verfügung,
es gibt auch die Möglichkeit, da XML
einzustellen, dann kriegst du halt XML-Objekte, die
auf irgendeine Art und Weise formatiert
sind. Du kannst auch selber einen schreiben, der
halt irgendwas anderes macht.
und das ist auch eine der Stärken.
Das bedeutet ja aber nicht, dass jede
Antwort auf ein Get immer
ein JSON sein muss. Das bedeutet halt nur,
dass es
Media Types gibt, die von verschiedenen Branches
unterstützt werden und andere werden halt nicht unterstützt.
Und gerade bei so einem Blob-Objekt wäre es
halt dann
Application
Binary, weiß ich nicht.
Octet.
Ja, ja, ja.
Nee, stimmt schon. Also insofern würde das da auch reinpassen.
Ganz kurz nochmal, Octet-Stream,
was ist das denn?
Ja, Octet ist der coolere Name
für Byte. Also es sind einfach
Binärdaten, die übertragen werden.
Also zwei hoch...
Das ist so der Fallback-Type.
Wenn ich nicht weiß,
was es ist, dann sind es halt irgendwie Binärdaten.
Und das heißt, als MIME-Typ oder als
Datentyp heißt es Application
slash OctetStream. Heißt einfach nur
irgendwelche Daten, keine Ahnung.
Okay, OctetStream.
Auch gerade jetzt zum ersten Mal drüber gestolpert, das ist ja Wahnsinn.
Wie lange macht man das eigentlich schon?
Ich weiß es nicht.
zu lange.
Also ja, okay,
dann sind wir ja schon wieder bei Python angekommen.
Wir hatten aber die Methoden
gerade alle so einmal durch.
Hatten wir alle? Also Options gibt es glaube ich noch.
Dann gibt das auch REST, oder?
Options ist WeGet nur ohne Inhalt.
Das ist nur, wenn man sozusagen die Header abrufen möchte,
um zum Beispiel die Datentypen
rauszufinden oder die verfügbaren Datentypen rauszufinden.
Das heißt, man kann quasi nach Options fragen
und dann bekommt man alle Optionen, die
Datentypen bereichern.
Genau, das ist so wie ein Get, das ist genauso wie ein Get, nur dass der den Inhalt nicht mitschickt.
Das wäre zum Beispiel, wenn der Jochen jetzt seine Podcast-Episode abrufen möchte und weiß, dass das eine 2-Stunden-Episode ist, also eine von den kurzen.
Geradezu mickrig, kurzen.
Meine Frau hat sich vorhin darüber lustig gemacht, dass wir so lange eine Episode aufnehmen, aber ich habe ihr gesagt, das ist halt so.
Dann möchte ich eben
nicht sofort die gesamte
möchte ich nicht diese ganze
Episode auf einmal abrufen, sondern ich möchte
erstmal sehen, ob ich die überhaupt verwenden kann
und dann schicke ich da ein Options-Request
hin und dann sagt mir der Server halt, ja, der hat
so und so viel Bytes und
der Content-Type ist so und so
und dann kann ich sozusagen
ausprobieren, ob
diese Anfrage sinnvoll ist
Ja, okay
Interessant
Aber um jetzt wieder zu Arpies
Rest-Arpies zurückzukommen in Python
Also Django Rest Framework haben wir gerade erwähnt
Also da wir alle gerne Django machen
ist das glaube ich einer der Ways to go
Das ist tatsächlich auch ziemlich großartig
Das ist auch so ein Ding
Ich weiß nicht, ich glaube das ist auch so ein
wiederkehrendes Thema, das habe ich jetzt auch
von anderen schon gehört
und das war bei mir so und vielleicht auch bei
anderen noch
Also oft sind so die ersten gut
funktionierenden Projekte irgendwas mit
Jungle REST Framework bei vielen Leuten gewesen.
Ich weiß nicht so genau, woran das liegt,
aber tatsächlich würde ich jetzt mal so,
okay, keine Ahnung, also ich habe ja
Wirtschaft,
mag daran liegen, dass das super ist, aber auch, dass es halt
einfach, dass man da dann
anfängt, in einem etwas interessanteren Markt zu sein,
weil das, was man sonst
so sieht, also
wenn du,
keine Ahnung, also das, was halt so,
gibt es ja viele,
die so WordPress-Seiten machen oder so,
keine Ahnung, Zeugs,
und da bist du halt in einem sehr unglücklichen Quadranten aus meiner Perspektive.
Das ist halt irgendwie Low Budget.
Die Kunden sind üblicherweise nicht bereit, da so wahnsinnig viel Geld auszugeben.
Ja, es war früher ein besserer Markt.
Ja, kann auch sein, dass es mal gut war, aber ich glaube, mittlerweile ist es nicht mehr so richtig toll.
Dann ist es auch Low Value, weil es ist einfach nicht so geil.
Es ist meistens irgendwelche, naja, doch eher so technisch herausgeforderte.
Kommt dann über die Add-ons, glaube ich, wenn du dann noch ein Magento dran machen kannst, dann bist du wieder...
Genau, dann kannst du natürlich so lange Plugins installieren, bis es dann vielleicht doch funktioniert.
Das Problem dabei ist, dann bist du aber auch bei einem anderen unangenehmen Attribut,
nämlich ist es dann kompliziert und schwierig, das irgendwie richtig hinzukriegen.
Das heißt, es ist schlecht bezahlt, du kriegst nicht so viel richtig Wert hin und es ist auch noch schwierig.
Das ist einfach ein unangenehmer Ort, würde ich jetzt mal so sagen.
während wenn du halt
dann sowas machst wie Django REST Framework
oder so, da ist
plötzlich irgendwie, da ist richtig Wert drin
wenn da irgendwie die Apps von Leuten
richtig gut funktionieren
da suchen Leute
händeringend, da sind dann die Preise
irgendwie anders und
es generiert halt auch irgendwie ordentlich
Mehrwert, wenn das halt gut funktioniert
und man ein nettes Interface hat, wo man
die API irgendwie sich angucken kann und so
und ja
Das funktioniert dann plötzlich irgendwie, würde ich mal so
sagen.
Ja, mit Django ist das echt tatsächlich ganz nett.
Ich habe mal so ein bisschen geguckt, was tatsächlich in der Zukunft
noch so geplant ist.
Und da stehen tatsächlich relativ nette Dinge drin.
Zum Beispiel Realtime API Support
using WebSockets.
Ja, dann mit
Django Channels in Zusammenhang.
Better Authentication by Default.
Also die wollen vielleicht sogar Jot
und Core Support in das Core Package
reinbringen, wo wir eben schon kurz
sprachen. Das klingt doch ganz interessant.
Was war das?
Wo wir gerade...
Dominik,
ich habe gleich noch eine
kleine Randnotiz.
Was war das für eine Authentifizierung?
Genau, was war das für eine Authentifizierung?
.JWT.
Ah, echt?
JSON Web Token.
Aber da gibt es ja Bibliotheken.
Also ich meine, das ist ja nur
ein PIP-Install entfernt.
Ja, aber da gibt es halt verschiedene
nicht so gute
Varianten.
Die sind alle so ein bisschen...
Ja, aber das Problem ist halt irgendwie, dass der Standard wohl nicht okay ist
und dann ist es halt schwierig, dass...
Die Frage ist, warum der Standard nicht okay ist, wenn ich es richtig verstanden habe,
weil es verschiedene Möglichkeiten gibt, diese Schlüssel zu erzeugen
oder über diese Token zu erzeugen.
Weil es so viele Konfigurationen gibt.
Weil du sozusagen so
Soundgrade-Angriffe machen kannst. Du kannst dem Server
sagen, ja, schön, dass du
diese ganzen sicheren Methoden hast.
Ich bin ein kleiner, dummer Client. Ich kann das leider alles nicht.
Ich unterstütze die alle nicht.
Ich unterstütze nur etwas, was halt
im Standard definiert ist,
was aber super unsicher ist. Und dann nutze ich aus,
dass es unsicher ist. Und das ist natürlich
kacke, wenn das im Standard steht.
Das kannst du machen.
Du musst dann deinen Server so
konfigurieren, dass der die Sachen nicht annimmt,
aber es ist relativ schwierig herauszufinden,
was jetzt gerade alles schon unsicher ist.
Also das heißt,
es geht darum, welche Algorithmen der nehmen kann,
zum Bereitstellen dieser Token, dass man den nicht zurückrechnen kann?
Ja, zum einen das und zum anderen auch
die Token Art. Es gibt ja signierte Token
und unsignierte Token und wenn der Client halt
sagt, ich kann nur die unsignierten.
Und der Server ist so eingestellt,
dass er auch die unsignierten annimmt, dann nimmt er halt
auch die unsignierten an. Und dann irgendwie so einen kleinen
Verschlüsselungsalgorithmus nimmt, den man irgendwie in der Rainbow Table
nachgucken kann oder sowas, ja okay.
Ja, oder halt auch gar keinen, wenn du sagst, naja,
Verschlüsselung, naja, kann ich nicht.
Das ist eben
wirklich so, die
die Frage, was ist jetzt gerade der aktuelle Zustand der Sicherheit?
Und eigentlich müsste man sich da sehr gut drum kümmern.
Ja, und ich weiß nur mal, so ganz im Detail kann ich es nicht.
Ich weiß nur, dass Leute immer sagen, oh mein Gott, das ist alles schrecklich.
Und JVT, also von ihm, gab es irgendwie einen Post auf der Django-Mailing-Liste von James Bennett, glaube ich,
wo er mehr oder weniger klipp und klar gesagt hat, JVT werden wir in Django niemals machen.
Das ist irgendwie...
Jott?
Hm?
Jott?
Was ist das?
Dominik, du bist der Einzige, der Jot sagt.
Ich habe das im Blogpost gelesen von Toni, der das schrieb.
Ah, okay.
Vielleicht ist das richtig, ich weiß es nicht.
Schöne Grüße.
Ich sage immer Jason Webtoon.
Jason Webtoon.
Ich sage immer Jason Webtoon.
Genau, jedenfalls ist da die Ansage so,
das Protokoll ist scheiße, das machen wir nicht.
Was ist denn die Alternative, Jochen?
Das ist halt die offizielle Alternative,
jedenfalls,
so wie es in dem offiziellen
Django-Podcast, Django-Chat
von Carlton Gibson,
der offiziellen Django-Maintenner,
der übrigens ein total netter Kerl ist.
Der ist total nett, ja.
Sometimes pronounced Jot,
sagt Wikipedia. Sometimes pronounced.
Sometimes.
Ich versuche es dann mal jedes dritte Mal zu machen.
Genau, der sagt halt...
und Jochen unterhalten sich über die Programmiersprache Python
Aber auch nicht so arg, ganz ehrlich.
Ja, aber wenn man doch,
also ja, wenn man
irgendwie kann, das was man in Python
macht, kann die Dot-Bibliothek nicht einfach sagen,
nee, ich bin nicht downgradebar, also ist das
nicht da schon mit drin, also das muss ja dann,
der Standard kann das vielleicht,
aber wenn jetzt meine Bibliothek das verbietet,
dann ist das... Das Problem ist, du weißt ja nicht, mit welchen Clients du redest.
Ja, aber wenn der Client das gar nicht sagen kann,
weil meine Bibliothek das gar nicht zulässt, dann...
Ja, dann bist du inkompatibel.
Dann sagen die Clients, mit der Api
kann ich nicht reden, kaputt.
Ja, gut, kann ja sein.
Aber den kleinen, den kann ich ja quasi selber sagen.
Kannst du machen, Dominik.
Kannst du machen.
Dann kann man dabei bleiben, dann muss man nicht sagen, oh nein.
Ja, aber wenn ich den kleinen selber ausliefer, also das JavaScript beispielsweise, was dann mit meinem Backend reden soll,
und ich selber bestimmen kann, was da drin steht, dann kann doch nicht einfach irgendwer sagen, dass er jetzt einen anderen Standard dafür nehmen will.
Dann kannst du aber auch die Session-Authentifizierung nehmen, weil da hast du ja nicht viel gewonnen.
Außer, dass du jetzt selber immer die Authentifizierung
in jeden Request reintun musst, weil der Browser
das nicht automatisch macht.
Ja, aber bei Session habe ich ja noch andere Probleme, glaube ich.
Ja.
Dann kann ja jemand so tun, dass wer ja meine Session
klauen will oder sowas und dann...
Ja, kann er machen.
Das verhindert der Browser.
Ja, aber egal.
Es ist kompliziert.
Das mit der Authentifizierung ist auch noch nicht so richtig abschließend.
Ich bin überrascht, ich habe mich da schon ein paar Mal Gedanken gemacht und ich war immer überrascht, dass es da keine eigene fertige Antwort gibt.
Die wenig gelöst ist.
Sondern dass man immer denkt, oh, ich habe die Antwort gefunden und dann irgendwie ein paar Monate, Jahre später kommt einer um die Ecke und sagt, was machst du denn da, das ist doch totaler Quatsch.
Und das passt man einem schon seit Jahren nicht mehr, seit Jahren machen wir das nicht mehr.
Genau, und dann denkt man sich immer so, oh, okay, ich glaube, ich brauche Hilfe.
Ja, okay, ja, okay, Authentifizierung
über REST.
Es ist erstaunlich ungelöst.
Ja, REST ist ja erst mal
nur eine ganz normale HTTP-Webseite.
Also du kannst Authentifizierung machen mit allen Mechanismen,
die du da hast.
Ich meine, wir haben auch
früher alle die Webseiten gesehen,
die die PHP-Session-It
als
Get-Parameter drin hatten.
Du durftest mal halt nicht kopieren.
Dann dürfen wir halt die Links nicht verschicken
Ja
Wie macht man denn sonst noch
REST-APIs mit Python?
Genau, also ja
General REST-Fanwork, schöne Sache
Ich glaube in der
Flask, ich weiß gar nicht mehr
wie man das ausspricht, vielleicht spricht man das auch J aus
Nein, Flask
Ich weiß es nicht genau
Flask-K
Jason
Genau, da verwendet man eher Marshmallow, das gibt es auch für Django, aber da verwendet man meistens Django REST Framework
Ist so ähnlich
Was ist das jetzt wieder, Marshmallow?
Das ist auch eine Bibliothek, so ähnlich wie Django REST Framework, aber im Grunde, ja
Endpunkte
Benutzt man ja noch Flask, Jochen
Ja, aber genau, da wäre Hot Take
Ich würde dir sagen
So, jetzt habe ich ja
was ganz gemeines.
Jetzt machst du die Tore
für Flameworks.
Der einzige Grund,
Flask noch zu verwenden, ist ja so im Grunde,
aus meiner Perspektive, ich kenne mich auch nicht wirklich mit Flask aus,
aber wenn man alte Python-Versionen
hat, weil
das geht mit Flask und vielleicht mit anderen Sachen nicht.
Aber wenn man jetzt
größer Python 3.6 unterwegs ist,
warum Flask? Warum nimmt man dann nicht sowas wie Flask-API?
Also
Meinungen.
Wenn ich nicht nur eine API schreiben werde.
Hallo at pythonpodcast.de.
Da könnt ihr gerne Kommentare und
Afterlame an Jochen und
Kommentare jederzeit erwünscht hinterlassen.
Machen wir mal so eine Episode, wo wir die
vorlesen einfach.
Ja, das Problem ist, die ist dann
aber keine zwei Stunden lang.
Ja, außerdem wollen wir ja nicht
ja, es sind ja immer viele
nette Nachrichten da.
Es gibt ein sehr schönes Buch von einem
Science-Fiction-Autor, das heißt
Your Hate Mail Will Be Graded.
wo er einfach
Fanpost
sagen wir es mal in Anführungszeichen
die an ihn geschickt wurde
diskutiert
und
sowas
Jochen du wirst jetzt sicherlich
jetzt wurde es gesagt
das umfasst ja auch alle anderen
alternativen
alle anderen alternativen Systeme
CherryPie
Pyramid
Repose, Soap
Es gab ja eine neue Version
Pyramid 2.0, voll gut
Ich weiß es ehrlich gesagt gar nicht so genau, was
Pyramid, ich weiß, die gibt es alle
und so
Manche davon können bestimmt auch voll coole Sachen
Bei Soap, ja
Ja, das war mal
voll groß und so, aber
ja, vielleicht ist es auch voll cool
Es gibt noch Bottle oder sowas, ist das nicht auch?
Aber das ist super, ja, Bottle gibt es
ist super klein
Ja, das ist kleiner als Flask, deshalb heißt es ja so
Aber ich meine
tatsächlich Fast API würde ich jetzt aus meiner Perspektive
es macht im Grunde, dass es Fast macht, mehr oder weniger
Hat auch im Vergleich zu Flask
mehr Stars bei GitHub, auf jeden Fall als Bottle
Na super
Ja, aber das ist doch
Fast API ist doch wirklich nur für APIs gedacht, oder?
Ne, du kannst
du kannst
ja, ist gedacht, aber
es geht auch anders, du kannst da einfach
Ginger 2 Templates verwenden
und die Dinger ausliefern, gar kein Problem, geht
und
genau, du musst halt alles
Starlet ist halt sozusagen das
Ding da drunter
die Werbung ist on par
with Node.js and Go
ja
das besprechen wir
in der Benchmark
war das für
einen Benchmark der legal war?
ja, okay
Aber du hast halt, also ja, ich meine, ich mache in letzter Zeit schon auch so Dinge mit
FastAPI und ich finde das super. Ich finde gerade
auch die Integration mit Pydentic echt
nett und gut für
Alle Leute, die sich damit nicht abfinden wollen, können auch bitte an
welche E-Mail-Adresse schreiben.
Hallo, at Python Podcast.
Def 0 at Python.
mal.
Aber ich finde die Syntax ist halt
besser. Du hast halt da, das ist halt
nativ Async, direkt alles.
Die ganzen Geschichten
sind halt,
du könntest ja auch quasi in Django
oder halt in den Serializern Sachen mit
Type-Annotationen halt sozusagen da
die Typen festlegen oder so.
Geht nur nicht, weil das ist halt älter als
Type-Annotationen, deswegen musste man sich da schon was anderes überlegen.
In Django mit den Descriptoren.
Aber
in FastAPI ist halt erst ab Python 3.6,
das heißt, da kann man das halt so machen und dann hat man halt
das in relativ
eleganter Syntax ausgedrückt, wo man sonst
eine Menge schreiben muss.
Ob es jetzt so schlimm ist, weiß ich auch nicht,
aber es ist auf jeden Fall irgendwie so ein bisschen erfrischend
und was man halt auch geschenkt kriegt ist,
naja, das sind wir auch schon
eher beim Restthema,
ein Frontend, das aber nicht
so wie bei Django REST Framework so ein eingebautes
gerendertes Ding ist, sondern
das ist halt sozusagen
Swagger oder halt Open API
heißt das jetzt irgendwie,
dass
sich aus dem Schema
quasi das Frontend generiert. Es ist ja quasi
komplett JavaScript, aber dem sagt man
halt hier, so ist das Schema, dann macht es halt
ein Frontend dazu, das tatsächlich auch so ähnlich ist
wie jetzt bei
Jungle REST Framework.
Und das sieht eigentlich sehr gut aus.
Ja, sieht echt gut aus. Und das ist übrigens auch von Sebastian Ramirez,
der auch Typer gemacht hat.
Den hatten wir auch schon mal kurz ein, zwei Mal erwähnt.
Das sind schon interessante Sachen.
Da gab es doch noch was von dem einen, der
Jagerest Framework gemacht hat, wie hieß das denn gleich noch?
Ja, das ist ja
Tom, na,
wie heißt er noch?
Tom Christie, genau
Der hat auch
Starlet gemacht
Ah, ist das Starlet?
Wie hieß dieses, das hieß
Star API oder irgendwie sowas?
Fast API, meinst du?
Nee, dieser Standard, den er da sich ausgedacht hat
Ach, ich weiß es nicht mehr
Ach ja, das gab es auch. Er hat auch ein API-Ding gemacht.
Jaja, aber
ja, ob das...
Das war nur sehr kurzlebig, oder?
Ja, also jedenfalls habe ich davon dann irgendwann nichts mehr gehört.
Es waren auch coole Ideen dabei.
Da war zum Beispiel sowas dabei, wie dass du dann auch gleich
Kommando-Zahlen-Interface kriegst und so.
Aber irgendwie...
Was ist denn jetzt da?
Das wäre auch schon wieder
Superschwung.
Das ist das, was Fast-API drunter
verwendet.
Das ist quasi von einem Delphi-Entwickler, der
Dango S-Film gemacht hat und das hat dann
Fast API-Benutzung.
Cool.
Also Tom Christie macht eine Menge coole Sachen.
Der hat
einen Nachfolger von
Request Bibliothek.
HTTPX.
Genau, hat so ein bisschen ein Problem.
Und zwar einmal ist sie so
slightly unmaintained.
Und
sie ist auch nicht async.
Und zwar auch so gar nicht.
Und das ist ja heutzutage
auch so ein bisschen doof, weil wenn schon
alles an Sync wird, dann will man vielleicht auch so
Async-HTTP-Requests machen.
Das geht halt mit Requests nicht.
Oder es geht schon, aber da muss man halt
irgendwie sehr unheilige
Dinge tun und irgendwie das in Threads
machen und so.
Das geht halt nicht mit Async-Io oder so, so einfach.
Ja, und HTTPS
ist aber dann Async-fähig
und hat halt quasi
fast die gleiche API wie
Requests. Also bemüht sich auch
quasi die gleiche API zu haben.
sodass man das halt einfach quasi
man kann es so verwenden, wie man es gewohnt ist.
Man verwendet einfach
HTTPX anstelle von Requests.
Auch sein Nennt. Aber tatsächlich
irgendwie ein bisschen langsam
manchmal, ich weiß nicht so genau.
Ich verwechsel es immer mit
HTMX.
Das ist eine JavaScript-Bibliothek,
die Elemente
interaktiv macht.
Kann man sich auch mal ansehen.
Aber ich verwechsel es immer.
Ja, genau, also ja
das sind so, ich weiß nicht
ob ihr jetzt noch, also das ist eben Marshmallow,
Django REST Framework,
FastAPI mit
Saga Pydantic, also man kann dieses Saga Interface auch bei
anderen APIs, man kann das auch mit Django REST Framework verwenden
das machen ja auch viele
bei Marshmallow geht das bestimmt auch
ich weiß nicht, gibt es da sonst noch Dinge?
Ja, das ist doch das, was jetzt OpenAI, also dieses OpenAI API
Ja, ja, genau
Ja
Das ist da verlinkt
Ja, aber jetzt um sozusagen
mal noch einen Schritt weiter zu gehen, Jochen, du hast es ja schon
angekündigt oder angedeutet,
wenn ich jetzt eben nicht mehr so ein Interface
habe, was gut auf diese
Einzelobjekte passt
ums jetzt mal sozusagen, sondern wenn ich mehr Kontrolle
darüber brauche,
was ich genau abrufe und welche
Attribute ich abrufe, wie könnte ich das denn
machen? Ja, genau, da
kann man dann natürlich sowas nehmen wie
GraphQL.
Das ist
von Facebook, oder? Das ist Facebook,
entwickelt,
im Wesentlichen, um genau diesen
Use Case
abzudecken, dass man eben Sachen aus
diesem Social Graph abrufen kann,
der sich nicht an die
Standard-Objektkonventionen hält.
Ja, sie haben halt im Grunde genau das Problem, dass sie halt
sehr viele unterschiedliche,
in sehr vielen unterschiedlichen Kontexten halt diese
Daten, so Graph-förmige Daten,
ja auch gerade, ich meine,
da passt halt auch normales SQL, man kann ja sonst
auch normales SQL nehmen,
ist auch
aber da passt das halt gar nicht so super drauf
und dann GraphQL passt da besser
und ja, gut, okay
ist auch wieder
Ja, ist ja immer bei SQL, ist ja immer Sicherheit
Wir haben das gelacht, ihr habt das kurz drüber gesehen
Was war jetzt gerade der Joke dahinter?
Da war ein bisschen tieferer Joke hinter der
Jeder Softwareentwickler
hat sich schon mal gedacht, wisst ihr was
ich mache meine Schnittstelle einfach so, dass ich SQL-Strings
hinschicke und dann das Ergebnis zurückschicke
und das ist super genial, weil das ist für die Entwickler
genau das, was die Entwickler haben wollen
nur hast du damit halt
Sicherheit kannst du vergessen
hast keine Sicherheitsabfragen
mit SQL kannst du alles machen
und
deshalb macht man das
dann doch nicht, sondern denkt sich eben so
Sprachen aus, wie zum Beispiel REST oder GraphQL
Ja genau
ich weiß gar nicht, ob die EdgeDB Leute
noch eine eigene Sprache da haben
oder ob die auch GraphQL
Was ist EdgeDB?
Das sind eigentlich im Grunde
die Leute hinter Python
hinter der ganzen
Python Async-Geschichte
hinter Async.io und so
die machen
ein Ding namens
HDB und
ja, es ist
auch alles Async und so und
eigentlich ziemlich cool, basiert auf Postgres
auch, aber
ich glaube, die hatten auch eine eigene Abfragesprache
also ich dachte nur so, dass
es vielleicht eventuell eine Konkurrenz zu GraphQL
oder so, ich weiß nicht genau
vielleicht auch nicht.
Vielleicht nochmal ganz kurz zu dem Unterschied, also was REST jetzt macht
ist Objekte und damit kann man wunderbar
Quad machen und das eignet sich super für
normales SQL.
Und GraphQL, nein,
falsch. Ne, da gibt es sowas gar nicht.
Du kannst bei
REST kannst du halt nicht sagen, was
du gerne hättest oder du kriegst halt.
Genau, es sind immer einzelne Objekte und
immer ganze Objekte.
Oder Listen von Objekten oder sowas.
Ja gut, du kannst halt unterschiedliche
URLs machen, die dann unterschiedliche Sachen liefern, aber
du kannst halt jetzt nicht
das wäre halt nicht restkomfortabel
eigentlich, genau, hat jedes
Objekt Invest seine eigene URL
und das höchste der Gefühle ist, dass
du halt Listen haben kannst, die bestimmte
Eigenschaften haben, zum Beispiel entweder alle
oder die, die
in X verlinkt sind
dass du so Sublisten hast
dann kannst du natürlich noch Filter machen
aber das geht dann schon raus, weil dann
hast du schon so Listen
abgerufen, die es
eigentlich gar nicht gibt und das ist schon so.
Gar nicht REST.
Eigentlich soll das nicht so sein.
Also ich sollte alle Abfragen einzeln machen, um zu gucken,
ob die hier drin sind und dann alle wieder wegschmeißen,
die es nicht sind.
Nee, das nicht, aber
diese Liste selber ist nicht,
die wird nicht von REST beschrieben,
weil diese Liste selber kein
Objekt ist. Das heißt,
um diese Liste zu finden,
musst du schon wieder mehr wissen, als
in Hatoas drin ist.
Weil die nirgendwo verlinkt sein kann.
Jetzt musst du nochmal kurz erklären, was Hr ist. Das hat nämlich eben niemand verstanden.
Das sind diese Hypertext, also dass alles über einen Hyperlink erreichbar ist.
Deswegen nennt man auch Hyper-Synergizer beim Dango REST Framework.
Hyperlink-Synergizer, genau.
Genau, damit die Links alle korrekt drin sind, damit du draufklicken kannst.
Das ist eigentlich einer der Grundsätze, dass du sozusagen den AP-Root anklickst und da steht dann drin, was es alles gibt und dann klickst du da drauf.
Und da steht dann drin, hier gibt es die Objekte vom Typ so und so und dann klickst du da drauf und dann kommt ein Objekt vom Typ so und so.
dass alles was es gibt
über einen Hyperlink erreichbar ist
und wenn du jetzt so Get-Parameter einführst
die Filter haben oder so
dann sind die nirgendwo verlinkt
die musst du kennen
und das ist schlecht
weil dann ist deine
API nicht mehr durchsichtig
sondern die ist jetzt
undurchsichtig geworden
du findest das nicht in der API
vielleicht über Options
kann man sowas in die Options schreiben
in den
in den Options
kriegst du eigentlich die Header zurück.
Da kriegst du eigentlich die Header zurück und dann müsstest du dir
wieder irgendwelche
Header überlegen, die auch nicht
standardkonform sind,
von denen du auch wissen musst,
dass du quasi die Header gucken musst,
um das zu finden.
Das, was Django Rest Framework da macht,
ist ja schon eine sehr gute Sache,
dass du die Dokumentation mitlieferst, kannst
dir die Dokumentation anschreiben.
In einem Swagger-File
weiß ich gar nicht, wie das abgebildet werden würde.
und Jochen unterhalten sich über die Programmiersprache Python
und Grafiel ist jetzt wieder so ein kleines bisschen ein Schritt in Richtung Remote Procedure Call wo du eben nicht sagst gib mir folgendes Objekt sondern es ist mehr so f bitte folgende Abfrage aus
Du hast halt auch nicht eine URL für die unterstrichen Geschichten, sondern du hast halt eine URL, an die alles geht und es gibt nicht mehr Delete, Pad, Putsch
Push.
Der mächtigste
aller
Aber auch
Satire.
Funktioniert nicht immer.
Genau.
Es gibt
eben diese ganzen Werben nicht. Es gibt nur Post.
Das war's.
Das ist natürlich
Hat andere Vor- und Nachteile.
Es hat halt andere Trade-offs.
Okay.
Ich kann aber dann tiefer reingucken
und bekomme andere
deutlich fokussiertere Daten
schneller oder
worum geht es?
Eventuell schneller.
Insbesondere kannst du es steuern.
Du kannst sagen, ich habe jetzt in diesem Request
brauche ich alle Objekte,
die folgende Eigenschaften haben
und dazu alle, die folgende Eigenschaften haben
und davon aber nur das Attribut
Name.
Anstatt dass du dann halt in deiner Übersichtsliste
so wie es bei REST ist, erstmal alle abrufen musst,
um dir Namen anzuzeigen.
Führst da halt diese eine Abfrage aus
und kriegst die Liste der Namen zurück, die du
dann direkt anzeigen kannst. Also diese
GraphQL-Schnittstelle ist viel
näher an so einem
Datenbankinterface
jetzt ganz spezifisch für
Graph-Datenbanken,
als es REST ist.
REST ist ja wirklich
eigentlich ein Object-Store.
Mehr dann Sinn, wenn man
sowas wie,
die, ich versuche jetzt mal abstrakt zu visualisieren,
wolkige Datenformen hat als tabellenförmige Datenformen?
Ja, wenn du verschachtelte Strukturen hast,
also wenn du zum Beispiel eine Liste von Freunden von Freunden hast
oder Kommentare, die auf Kommentare zeigen,
die irgendwie in so einer Grafenstruktur angeordnet sind,
weil dann wird es halt mit SQL immer so ein bisschen ätzend,
das geht auch, aber da muss man sich
dann was einfallen lassen.
Also wenn ich in SQL jetzt denken würde, wenn ich
zu viele Following Keys hätte in meinen
einzelnen Daten.
Nee, rekursive.
Genau, wenn du einen Baum hast oder
einen Grafen im Allgemeinen.
Also was da schon schwierig ist,
in der Datenbank abzubilden.
Das ist gar nicht so einfach.
Was sind deine Lieblingsgrafenstrukturen
in Datenbanken?
Ich weiß es nicht.
Ich weiß, dass der
Autor von FeinCMS
der
Treebird, ich weiß nicht genau,
was er empfindet,
was ich eine ganze Zeit gemacht habe, ist NesseZ.
Das geht
eigentlich ganz gut,
aber es ist halt schon echt haarig.
Also das ist schon so,
ja.
Bei MatheoLivePaths
sind die Abfragen so bescheuert.
Das ist schon cool, aber die Abfragen sind so blöd.
MatheoLivePaths, Entschuldigung, ihr habt jetzt gerade
wieder irgendwie...
Daten...
Was habt ihr gesagt?
Dominik googelt.
Ja, also
die Frage ist halt, wie
bildet man solche Strukturen eigentlich
in der relationalen Datenbank ab?
Und das ist halt nicht so einfach. Es gibt halt das
grüne Buch von Joey Chalko oder so.
Trees and Hierarchies
in SQL oder so. Das kann man sich
halt durchlesen. Da stehen die ganzen Methoden, die man
da verwenden kann, drin.
Aber tatsächlich,
Die sind alle schlecht.
Und die sind alle schlecht. Die sind alle blöd.
Es ist einfach
schwierig, Graph-Daten, also
Vernetzungsnetzwerke
in eine Tabelle zu schreiben, weil in der Tabelle
hast du einfach inhärent, kannst
du keine Netzwerke reinschreiben und
alles, was man da macht, ist
ein Hack und die haben alle Vor- und Nachteile
und die sind alle schlecht.
Und deshalb gibt es ja auch Graph-Datenbanken
und eben andere
NoSQL-Datenbanken, die dafür besser geeignet sind.
Ja, und ein klassisches
Anwendungsbeispiel für sowas, wo man das dann halt braucht
und wo man Schwierigkeiten mit, ist halt sowas wie,
wenn ich jetzt wissen will, was sind denn jetzt alles meine Freunde
vierten Grades oder so, dann ist halt
auf einer SQL-Datenbank, ist halt kacke. War das nicht irgendwie so eine Theorie,
die sagte, dass man mit allen Freunden oder alle Leute, die
in Facebook gebraucht haben, am spätesten sind? Genau, Small-World-Theorien, ja.
6?
Ja
6 Degrees of Separation
heißt es
6 Degrees of Kevin Bacon heißt es auch
glaube ich, aber das ist noch was anderes
Ja, ja, ja
Ja, aber
also wie gesagt, GraphQL ist quasi
so ein Schritt in Richtung RPC
wieder, wo ich eben einen Endpoint habe, wo ich
alles hinschicke und dann aber dafür eben
vergleichsweise komplexe Abfragen ausführen kann
Ich kann da allerdings auch eben
vergleichsweise komplexe Updates
ausführen, dass ich eben sage, ich möchte gerne
folgende Objekte holen
und dann auch bearbeiten oder folgende Objekte
holen und dann auch irgendeine Operation
aus denen ausführen.
Das ist
sehr, sehr mächtig.
Aber es ist eben nicht mehr so erfahrbar.
Es ist nicht so durchsichtig wie eine REST API,
weil man eben wieder
darauf zurückgeht, dass man die Dokumentation hat,
dass man die Namen von den Funktionen wissen muss,
dass man die Attribute von den Objekten
wissen muss und ich kann nicht DeepLinks drauf machen.
Was bei einer
API nicht ungeheuer schlimm ist, aber
aber
ja, es ist
einfach mehr Wissen außenrum.
Ja, der Client wird halt viel,
ist halt viel, viel, muss halt viel
fetter sein sozusagen. Auch eine
nette Geschichte, kommt darauf an,
welchen Client und welche Server man so
verwendet, aber man kann halt auch sowas machen wie
Subscribe, dass man halt eine
Query, die man eh stellen muss,
also man muss sie eh hinschreiben, weil man ja
irgendwie die Daten holt und dann sagt man halt,
wenn man daran interessiert ist, Updates davon
reaktiv zu bekommen, dann sagt man halt einfach nur
Subscribe und dann kriegt man per WebSocket
halt Änderungen an dem
Query-Set, auf das man subscribed ist.
Und dann kann man tatsächlich, wenn zwei Leute
irgendwie den gleichen Kram
editieren oder so, dann sieht man die Änderungen
von einem anderen halt direkt oder so.
Das geht alles automatisch. Voll gut.
Ja, tolle Sachen.
Ich habe vor einer Weile was gefunden,
das heißt Graffiti mit PH.
Graffiti.dev
Das ist auch ein Link, der da rein muss.
Das mir sehr gut gefallen hat. Ich weiß noch nicht,
wie ich damit zurechtkomme
und ob das... Das ist so ein bisschen
wie Ruby on Rails. Ruby on Rails hat ja
früher die ganzen coolen Sachen gekonnt,
wo Django so ein bisschen
langweilig war. Und hier ist es jetzt
wieder genauso. Das ist so eine Ruby-Bibliothek,
die so ein bisschen die Brücke schlägt
zwischen REST und GraphQL.
Das ist quasi
REST mit ganz vielen Konventionen,
sodass du
daraus so eine Art
GraphQL machst, mit den Vorteilen von beiden Seiten.
Du kannst coole Queries ausführen,
aber hast trotzdem die ganzen
guten Vorteile.
Okay, interessant, mal angucken.
Ja, aber es ist, alle Beispiele sind
in Ruby und
ich habe noch nicht gefunden,
ob das auch in
Python oder gar in Django geht
und das wäre sehr schön.
Diese Konzepte, die da drin sind,
haben mir sehr gut gefallen, weil die halt sehr viel
über Konventionen machen. Das ist quasi eine Restringstelle mit ganz vielen Konventionen.
Und auch mit ganz vielen, wo dann eben
Sachen über Datentypen laufen. Also hier wird dann so eine Ressource
definiert, die ein Attribut hat, was ein Name ist, was ein String ist, der sortable
ist, der filterable ist. Und wenn du diese zwei Attribute hast, dann
weißt du ja schon ganz viel darüber. Dann weißt du schon ganz viele Operationen, die du da machen kannst.
Was dann eben wieder zurückgeht auf das, was der Dominik eben angesprochen hat.
man braucht halt sortieren und filtern
und irgendwie muss man
das abbilden und warum nicht
eine gängige Konvention machen und das
der Ressource mitgeben und sagen, okay, hier
da steht immer
dieses, dass es sortierbar ist, ja oder
nein oder dass es beschreibbar ist, ja oder nein
dann
reicht es doch aus, das zu wissen und das ist
quasi so eine Formalisierung davon
dass du
nur noch diese Attribute hast und dann ganz
viel daraus automatisch rausfällt
und das ist ein sehr schöner Ansatz, der vielleicht meiner Meinung nach auch sehr zukunftsweisend ist
und auch noch nicht weit genug überall verfügbar ist.
Das heißt, du fragst einfach die API und weißt direkt, wie man die benutzen kann, ohne dass du weiter...
Du fragst quasi die API nach den Datentypen und aus den Datentypen ergeben sich dann Sachen.
Die API gibt dir auch zu den Datentypen die Operationen zurück,
und Jochen unterhalten sich über die Programmiersprache Python
aus beiden fehlt. Das ist eigentlich
die Vorteile von REST und die Vorteile
von GraphQL zusammen.
Leider habe ich es noch nicht
realisieren können, weil es eben wie gesagt
so, naja,
Installation, da steht dann, wie man es
bei Ruby installiert und dann,
gut, schade.
In meine Rails-Applikationen
könnte ich das jetzt sehr leicht reintun.
Leider
habe ich davon keine.
Ciao, ciao.
Ja.
Schade.
Hätte jemand Lust,
ein Open-Source-Projekt anzufangen?
Lust schon.
Falls sich Sponsoren für dieses Unternehmen
finden, die melden sich bitte bei
hallo.pythonpodcast.de
Ich wäre sehr daran interessiert,
da einen Sponsor zu finden. Ich würde auch
meinen üblichen Stundensatz reduzieren,
selbstverständlich für Open-Source-Work.
und
bisher habe ich keinen
Sponsoren gefunden, der das bezahlen könnte.
Meine Firma ist leider nicht reich genug,
um so etwas
Großes anzugehen. Aber jemand
sollte das machen, absolut.
Dankeschön.
Ja,
ansonsten, genau, ich weiß nicht,
auch interessant,
diese Formate, die man da übertragen kann,
dazu
fällt mir gerade noch eine
Geschichte ein,
es gibt da so ein
Podcast, den ich auch immer höre, weil mich
dieses, im Prinzip dieses ganze, weil ich
die, die, die, die,
oh Gott, Hölzchen, Stöckchen,
ich fange noch weiter vorne an.
Wir kennen das von Jochen.
Ja, ja.
Python Podcast
ist ja sozusagen in Python
Genro selber gehostet und
ja, ich bin nicht
so richtig super zufrieden damit, also es funktioniert schon
so, aber so, eigentlich würde mich natürlich nicht interessieren,
wenn man das richtig macht. Und da gibt es einen anderen Podcast,
nämlich den Podlovers
Podcast.
Und genau, den höre ich
dann, weil da reden Leute darüber, wie sie das halt
also, Paddler ist halt das
WordPress-Plugin. Das ist quasi ein
Meta-Podcast.
Ein Podcast-Podcast, ja.
Ja, oder über Podcasts, genau.
Und da dachte ich, ja, vielleicht dann, wenn ich das
an, wenn ich da mal, also ich finde es auch tatsächlich
ein super Ding und ich höre das
und versuche mir dann die ganzen guten Ideen alle
zu stehlen und dann selber zu verwenden.
Und letztens
gab es dazu eine interessante
Episode zu den, auch zu
Podcast Clients und
zu Feedpassing
und sowas und also
ich weiß jetzt gar nicht, ich möchte gar nicht
es gab dann einige Episoden schon, ich weiß jetzt nicht mehr genau welche
wo es darum ging, wie sollen denn die Formate
und jetzt gibt es auch inzwischen
Podcasts sind ja so relativ
gehypte Geschichte auch
und jetzt kommen Leute
wieder auf die Idee, nachdem da seit
zig Jahren
über 10 Jahre lange nichts an den Standards
passiert ist. Oh, vielleicht können wir doch mal
was an den Standards machen, weil
vielleicht will man ja auch dann
so ein paar Features ändern oder sich irgendwie
abgrenzen oder, keine Ahnung, cooler sein als die anderen.
Und es gibt jetzt podcastindex.org
und so, wo halt
das sind auch Leute, die das schon ganz lange machen,
sich halt wieder so überlegen, ob man da nicht noch
irgendwelche neuen, interessanten Dinge statisieren kann und so.
Und da
ging es dann halt auch immer darum,
okay, die ursprünglichen Standards
zu Podcasts oder zu Blogs.
Das ist halt alles XML, RSS.
RSS ist XML?
Ja.
Genau.
Und
die Frage wäre halt,
okay, und dann gab es irgendwie
die Idee, oh, man könnte ja
vielleicht auch JSON-Feeds nehmen.
So heute macht man ja eigentlich kein
XML mehr so richtig.
Und
wäre das nicht
wäre das nicht irgendwie besser.
Und dann hatte ich so den Eindruck,
da waren Leute doch, fanden XML eigentlich ganz cool
und dachten so, ne, Jason,
warum denn? Und lieber XML.
Und zum Rest hat man dieses Problem ja auch,
dass man die Daten irgendwie übertragen muss.
Und da habe ich auch so das Gefühl,
XML spielt im Grunde keine Rolle mehr so richtig.
Und alle machen halt irgendwie JSON.
Ich weiß nicht, man könnte es auch als CSV machen.
Hat das jemand schon mal gemacht?
Hm.
Also ich müsste mal kurz gründen, warum es überhaupt XML gut sein könnte. Ich habe das nämlich letztens irgendwann mal gehört, dass irgendwer meinte, oh, XML wird doch eigentlich total unterschätzt.
Ja, also
weiß ich, also ich kann mir
vorstellen, wie man auf die Idee kommt.
Ich würde das wahrscheinlich nicht sagen, also ich hatte
eigentlich nie eine besonders hohe Meinung von XML
und
aber ich kann in gewisser Weise verstehen, wie man
aus einer theoretischen Perspektive sozusagen
darauf kommt, dass das eine gute Idee wäre, weil
viele der Probleme, die man sonst hat, wenn man das nicht
macht, man ja
vielleicht damit lösen könnte. Also
zum Beispiel eben, wenn man jetzt sich vergleicht
mit sowas wie CSV, was früher
Also, wenn man
CSV-Probleme hat, dann könnte man
denken, dass XML vielleicht eine
Ja, also man könnte sich vorstellen, dass
XML vielleicht eine gute Idee ist, wenn man jetzt
Schon mal vorher
Immer eine gute Idee. Kann man alles
machen. Ja, kann man.
Tatsächlich.
Aber
Ja, also wenn man jetzt
sowas wie CSV hat und man hat jetzt
Probleme, weil irgendwie Leute
schreiben da komische
Sachen rein und Dinge gehen kaputt,
und man sich denkt so, mir reicht's.
Diese Barbaren, immer was sie da für komische Sachen, also tatsächlich, ich habe auch
einige Zeit im Import-Export-Geschäft sozusagen von solchen
Daten verbracht und da passieren halt die komischsten Sachen,
dass halt irgendwie das Encoding wechselt von Zeile zu Zeile,
dass IDs halt keine IDs sind, dass irgendwie
das Escaping sehr kreativ anders ist und das hat halt damit zu tun,
dass halt da Daten aggregiert werden
aus unterschiedlichen Datenquellen
dass die dann irgendwie nochmal als
Excel irgendjemandem auf dem Tisch landen und der
editiert dann fröhlich drin rum, speichert es wieder als was anderes
und schickt es dann nochmal raus oder so
also da passieren dann wilde Sachen und da
könnte man sich jetzt denken, oh super, nehme ich
doch XML, habe ich dieses Problem gelöst
weil, da sind alle Probleme gelöst
weil, da habe ich ein Schema, da steht
drin was das ist und wenn
da jemand dann Mist macht, dann geht das einfach
gar nicht. Da steht Spezifikation quasi mit
in der Datei. Ja und
in einer anderen Teil-DKD.
Ah ja, genau.
Und
ja,
tatsächlich ist es aber so, also
ich würde sagen, eben, es klingt danach, als wäre
das eine Lösung, praktisch,
so aus diesem
Tages-Import-Export-
Geschäft mit vielen
Dateien, die da reinkommen
und rausgehen und
unterschiedlichen Anforderungen und
komplizierten und komischen Systemen dahinter
und seltsamen Leuten und so.
Muss ich sagen, wir haben
dann irgendwie, also
XML und CSV gehabt
und wir haben immer CSV empfohlen.
Und XML hat
zu vielen fiesen Problemen geführt,
die ehrlich gesagt schlimmer waren als
das, was wir mit CSV...
Aber nicht die Encodings.
Encodings sind gut
bei XML.
Ja. Naja, gut.
Manchmal kriegt man auch so komische Byte-Order-Marker
vorne dran, die dann irgendwie auch Sachen kaputt machen.
Aber
ja, tatsächlich
aber das Problem
ist halt, wenn du den Leuten
halt sozusagen
das wäre sozusagen
das Ding, was ich dazu
ja
mitgeben wollen würde und die Anekdote dazu
wäre halt, wenn man
es unmöglich macht, dass solche Fehler
passieren, dass halt zum Beispiel das Encoding
pro Zeile sich ändert oder so.
dann kann es sein, dass das dazu führt, dass die Fehler schlimmer werden und nicht besser.
Nämlich, was dann halt tatsächlich passiert, was man dann beobachtet,
was ist die Konsequenz, wenn man das unmöglich macht, dass solche Fehler passieren?
Naja, dann kriegt man halt Dateien, die zwar syntaktisch okay sind,
aber die semantisch halt irgendwie nicht mehr funktionieren.
Wo dann zum Beispiel Teile einfach fehlen oder die leer sind.
Die sind dann ein gültiges XML-Dokument, aber es ist halt irgendwie leer.
Und dann ist halt die Frage, okay, was macht man denn jetzt?
Oder du hast dann die Fehler in den Daten drin.
Ich meine, wir haben ja alle schon mal diese UTF-8-Steuerzeichen
überall
in Latin-One-Dingern drin gesehen
und wenn das jemand reinkopiert,
dann ist halt so. Und dann kannst du auch
nicht mehr viel machen.
Genau, und das ist nämlich der Punkt,
wo es dann eben, wenn dann Fehler
passieren auf einer anderen Ebene oder halt
so, dass der XML-Parser sagt, alles okay,
aber es ist eigentlich gar nicht okay,
dann kannst du nicht
mehr viel tun. Bei einem CSV, wo das,
da kann man immer noch was tun. Wenn da irgendwie eine Exception
kriegt, da kann man die immer noch fangen und kann sagen,
okay, den Kunden kenne ich, der
kann sich nicht einigen, ob er da jetzt
Latin One oder UTM8
oder CP51
weiß ich nicht, das Windows-Dings da verwendet oder so,
ja, ja, ist schon okay, dann probieren
wir die mal der Reihe nach durch und einer von den Codecs
wird schon funktionieren. Meistens
funktioniert das auch. Und selbst wenn es nicht funktioniert,
dann ist halt eine Zeile kaputt
oder so, was oft nicht so schlimm
ist. Wenn eine von 10.000
Zeilen kaputt ist, na gut.
Das ist sozusagen
das
degraded gracefully sozusagen.
Das ist okay.
Naja, das ist eine sehr interessante Beschreibung
von graceful degradation.
Es kommt vielleicht auch noch an, welche Zeile das war.
Aber im Endeffekt
da werden
Leute nicht wütend oder rufen an,
wenn da eine Zeile nicht okay war.
Wenn das XML leer war und man jetzt
raten muss, was passiert ist, möchte
der Kunde zum Beispiel alle seine Angebote löschen.
Weil wenn man definiert hat, wenn das ein leeres
Ding ist, dann
oder offline schalten, dann
kann man das tun.
Das könnte Ärger geben. Oder man macht es nicht.
Das könnte auch Ärger geben, weil vielleicht
wollte er es ja tatsächlich machen. Also man muss halt
irgendwie dann raten und das ist halt
doof, weil jede dieser
Entscheidungen, die man trifft, kann halt potenziell
entweder bei einem selber zu
irgendwie
größeren Problemen und Geldverlust oder beim Kunden
zu größeren Problemen und Geldverlust führen.
Und das ist halt schlecht, weil das ist halt nicht so
richtig gracefully.
und
ja.
Das ist so ein bisschen wie diese
statistische interessante Anormalität,
als man
die Helmpflicht für Motorräder eingeführt hat,
ist die Zahl
der Kopfverletzungen gestiegen.
Und der
Grund ist halt einfach, dass die Leute, die vorher gestorben
sind, jetzt Kopfverletzungen haben.
Ah, okay.
Und so ein bisschen ist es da
halt auch. Du schließt die
einfachen Fehler aus
und deshalb kommen jetzt halt die schlimmen Fehler.
Ja, eine andere Möglichkeit wäre auch noch, dass die Leute, die vorher
Fahrrad gefahren sind, jetzt dann halt irgendwie Auto fahren und dann die
Wahrscheinlichkeit für Kopfverletzungen im Auto steigt oder sowas.
Ja, genau. Viele unabsehbare Konsequenzen.
Unintended Konsequenzen.
Externe Effekte.
Ja, insofern.
Jetzt haben wir zu viel über XML geredet in der Restfolge, ehrlich gesagt.
Ja, das ist ja ausgeschlossen.
Du kannst ja, auch Jungle Rest Framework
bietet ja den XML
Ja, mäh
Nein, wer will das denn lesen, wer will das denn parsen
Wer will das denn weiterverarbeiten
Das ist doch alles total hässlich
Ja, kann doch sein, dass du irgendeinen Client hast, der das halt
gerne haben will
Für Entity and Attributes of Attributes of Attributes of Entities
Mäh
XML hat ja auch Vorteile
Aha
Zähle uns die doch bitte auf, Jonas
Nein
Ich weiß, dass es welche hat, aber ich will es jetzt nicht sagen, weil ich will niemanden dazu verführen
Na gut
Ja, anderes Format, auf dem man auch noch gut rumhalten könnte, wäre JSON
Ich meine tatsächlich, ehrlich gesagt, es hat auch so diverse Hässlichkeiten und so
Aber JSON funktioniert eigentlich schon
Also das kann man eigentlich auch, man kann das schon nehmen, es ist nicht so schlimm
nicht, was es ist. Das ist auch in Postgres drin.
Das ist, glaube ich, die ältere
Variante, aber ja. Ja, kann sein.
Ja,
MessagePack ist quasi ein Drop-In-Replacement
für JSON, nur schneller und
kleiner.
Das kann man, glaube ich, bei Django REST-Framework
kann man das auch irgendwie mit dazu
konfigurieren. Ja, klar.
Das ist halt auch so ein Standard.
Ah, die heißen nicht Serializer, sondern heißen irgendwie anders.
Das muss man halt in der Konfiguration angeben,
als Klasse und
die haben ja ihre Abfolge und wenn der
Client nichts sagt, dann kriegt das halt in der richtigen...
Ich glaube, die heißen irgendwie Renderer
oder sowas. Ja, das kann sein.
Früher war das tatsächlich,
konnte man tatsächlich sehr schöne
Dinge machen, weil halt
Messagepack-Nachrichten kleiner sind als JSON-Nachrichten
und in einem Mobile-Umfeld
war das früher ein sehr
wichtiger Aspekt,
dass man unter 65 Kilobyte bleibt,
weil das eben ein
Datenpaket war, früher,
damals, als es
noch 3G gab oder 2G oder was auch immer.
und die Antenne nicht so, das ist ja auch sowas,
Stromverbrauch,
wenn man die Antenne
anschaltet.
Ja, macht man auch nicht mehr so häufig.
Ja, eigentlich ist es so.
Ja, jetzt haben wir noch, ich meine, jetzt haben wir sehr viel
über REST gesprochen und über Alternativen.
Im Grunde ist REST ja was
ganz Simples. Es ist einfach nur
die HTTP und HTML
angewendet, äh, nicht HTML,
HTTP angewendet auf APIs.
und
ja, so sollte man es machen.
So wäre es gut, wenn man das macht.
Und
das ist ja schon
ein...
Eine Sache, die ich
ganz interessant finde, die eventuell nochmal
dazu führen könnte, dass es halt so ein bisschen
Renaissance in die Richtung gibt,
weil man, vielleicht kann man Teile von dem, was man
jetzt mit GraphQL macht, auch dadurch erreichen, dass man
Endpunkte miteinander kombiniert
oder irgendwelche Aggregationsendpunkte macht
und
die dann halt per Async, also normalerweise würde man sagen, viele Requests machen nicht so cool, weil blockiert halt immer alle, immer einen Worker im Applikationsserver, aber wenn man jetzt Async hat, dann ist es vielleicht auch egal und dann kann man sich sozusagen seine Ergebnissets auch so ein bisschen darüber zusammenbasteln und diese Dinge halt Endpunkte vielleicht so on the fly generieren oder weiß ich nicht.
naja.
Da gibt es übrigens einen Artikel zu,
wenn ich jetzt mal da Werbung machen darf,
auf deinem Blog, Jochen,
über diese Async-Aggregations-API.
Hast du da einen kleinen Beitrag
zu geschrieben?
Achso, ja,
das ist aber sozusagen nur quasi,
wenn man andere APIs abfragt,
das ist natürlich auch ein Anwendungsfall für Async,
weil eben man dann halt nur auf den,
die Zeit, die Latenz ist nur die
Zeit, die der längst laufende Request braucht
und nicht mehr, wenn man das synchron abfragt.
halt alle aufsummiert.
Und genau, aber es wäre ja auch
sozusagen, wenn diese Dinge,
die man fragt, interne andere
API-Endpoints sind und man dann irgendwie noch eine Transformation
drauf macht und das dann raus schickt.
Microservices.
Ja.
Buzzword Bingo.
Ich glaube, wir haben
das voll.
Meine Consulting-Kosten
haben sich eben verdoppelt.
Ja, wobei
Microservice-Integration würde ich ehrlich gesagt auch nicht unbedingt über REST oder HTTP machen.
Ich weiß nicht, wie der das so macht.
Über was?
Wahrscheinlich über eine Message-Queue.
Okay.
Einfach deswegen, weil du dann zum Beispiel bei HTTP hast du halt diesen Overhead immer der Verbindung, die du aufmachen musst.
Ja gut, der geht ja mit Technik weg.
Ja, und intern musst du dann vielleicht auch nicht immer authentifizieren und sowas, aber
ja
Ja, okay, wie auch immer
Darauf müssen wir auch nochmal sprechen
Genau, also das wäre halt vielleicht ein
ein Ding, wie man sozusagen damit umgehen könnte
dass man ansonsten eine Explosion von Endpunkten hat
und ganz viele Abfragen machen muss, wenn man bei REST
im Vergleich zu Udaf.tl.
Aber ja.
Okay.
Keine Ahnung.
Ich würde sagen, wir haben ziemlich
bei Resten heute gesprochen.
Habt ihr noch irgendwas auf eurer Liste, was ihr noch loswerden wollt heute?
Weil sonst würde ich nämlich sagen,
packen wir es.
Nö, ich habe sonst auch nichts mehr.
Ich fand es schön,
viel wieder gelernt.
Ich hoffe, ihr bleibt uns weiter gewogen,
hört uns weiter und schreibt uns
in euren Fag, euren Lob, Hass, Kommentare,
alles, was ihr loswerden wollt, an
hallo.pythonpodcast.de
Schön, dass ihr wieder eingeschaltet habt.
Vielen Dank, dass ihr wieder alle dabei wart.
Vielen Dank, Johannes.
Und ja,
hört uns das nächste Mal wieder.
Alles klar. Bis dann.
Bis zum nächsten Mal. Tschüss.
Wir haben die Pics vergessen.
Machen wir dann heute nicht.
Tschö, tschö.