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, Zeigen.
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.
Ja, wen frage ich denn zuerst?
Was ist denn das?
Ich dachte, wir wollen nicht vielleicht zuerst die 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.
Kommen wir nicht mehr zu den News?
Doch, die kommen noch zu den News.
Na gut, okay.
Erklär mal ganz kurz, was REST ist.
Aber nur ganz kurz.
Ja, das ist Elevator-Picture.
Also, man stelle sich vor, man hätte da so eine Dampfmaschine.
Na ja, 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.
Kurz vorm der Anleitung.
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.
das ist für mich so der
Knackpunkt, was REST zu REST
macht. Dass man nicht Funktionen
aufruft, sondern Objekte
abruft und verändert.
Okay, jetzt suchen wir jetzt Objekt News ab.
Jetzt machen wir News?
Ja, jetzt machen wir News. Gut, okay, machen wir
News.
Pattern Matching!
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 habe sogar, 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 Switch Case?
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 das 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 3, dann ist es ein Stereo.
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 zu kompliziert wird
und ich meine, da gab es ja auch diese große
Kontroverse irgendwie beim
Walrus Operator.
Ja.
Auch bei den Typen, bei dem
Type Automation.
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 hinterschreiben 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.
Und dann kann man da zwei verschiedene Typen haben.
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,
diese Type Annotations, die
sind halt an manchen Stellen total nett.
Ob ich das jetzt an allen Stellen
im Kult gerne hätte, weiß ich jetzt auch nicht.
Du kannst ja einfach weglassen, das wäre das Schöne. Genau, genau.
Ja, man kann es dann, genau.
Und da, wo es halt Sinn macht, irgendwie,
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 auch häufiger, irgendwie
entweder Dataclasses
Adress oder
Pidentic verwenden
und tatsächlich Klassen so
hinzuschreiben, ist deutlich angenehmer
als das irgendwie...
Hatten wir Pydentik schon mal?
Ich weiß nicht genau, ob ich es mal
gepickt hatte oder so, kann sein.
Was macht Pydentik?
Du hast es auf jeden Fall mal erwähnt, glaube ich.
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 ein paar Identity in der Doku mal rumgewühlt.
Also eigentlich wollte ich wissen, was das ist, aber
Ja, das ist so
eine Art Mischung aus
MyPi und Data Classes, oder
Jochen? Man kann leicht
Datentypen definieren mit bestimmten Typen und
der prüft die dann auch noch. Genau,
also es prüft das 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-Geschichten? Was ist
das denn, Jochen? Ja, Moment.
Erstmal die Reste der News, bitte.
Genau.
Was haben wir denn
da noch? Ja, so
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
Aber Async-PG ist auch so ein Ding, was man sich unbedingt mal angucken kann.
Ja, ich wollte gerade sagen, wovon hast du gerade gesprochen?
Ja, UV-Loop ist halt so eine schnelle, also ist die Python-Version oder Abstraktion ein Wrapper um LibUV und das ist eine super schnelle Abstraktion über die ganzen Betriebssystem-spezifischen Schnittstellen, sowas wie EPOL oder KQ oder was weiß ich nicht, was da sonst so.
TCP-Completion-Ports oder
IO-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 IO machen
und das Ganze halt in der
Event-Loop und das ist auch das, was unter Node.js
zum Beispiel drunter 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.
Ich denke, auf Datenbank stelle ich mich 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.
Ja, aber das ist ja okay. Du hast 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 ein...
an die Datenbank und dann blockierst du halt
einen Code.
Das ändert nicht
die Datenbank, Dominik, sondern es ändert nur,
wie du die Verbindung der Datenbank hältst.
Aber
wo wir gerade bei PsychoPG sind,
PsychoPG3 ist angekündigt.
Die koordinieren sich gerade
mit den Django-Leuten,
dass die Datenbank-Verbindungen 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
klar, oder ich dachte, das passiert irgendwie magisch automatisch
und das passierte nicht, wenn man ein Thread aufmacht,
dann
macht das eine zweite Connection auf.
Und wenn man sich dann nicht weiter
um den Thread kümmert oder wenn der weggeht,
dann geht der Thread
weg, aber die Connection nicht. Und wenn
man das häufig macht, dann ruft
irgendwann, dann kriegt man Ärger
von dem Datenbank-Admin, weil
der sagt, meine ganzen Connections
dazu, was zur Hölle macht ihr denn da?
Ja.
Ups. Ups, genau.
Ja.
Ja, ja, aber Pooling wäre auf jeden Fall
eine schöne Geschichte, weil manchmal ist ja auch
eine Verbindung nicht genug und
ja. 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.
Es gab einen Artikel zu...
Es gab da schon ein paar Artikel zu, das stimmt.
Ja, und das...
Dependency-Conclusion. Ja, sehr deprimierendes
Problem, ehrlich gesagt. Das musst du gerade erklären.
Was ist Dependency Confusion?
Ja, da gab es doch so ein, da hat auch 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. Oder wenn sie sich vertippen, genau.
Dann kann man das sozusagen
hijacken und dann kann man den Software
installieren, die auch im
großen Grenzen das tut, was
die 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 macht
halt gleichzeitig, was weiß ich, 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 dreieinhalbtausend
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.
Also, und hat da auch
überall irgendwie quasi das... Ja, okay, das
habe ich auch gehört. Diese Preisgelder
dafür gekriegt, die man halt für...
Millionenweise. Ja.
Also das war, das hat sich gelohnt.
Ja, auf jeden Fall.
Und das ist auch wirklich ein fieses Problem
und es gibt eigentlich nicht so, es ist
so ein bisschen doof. Also Poetry
könnte doch da helfen, oder? Wenn ich jetzt irgendwie die Hashes
von den Dependencies da mit... Nee, leider nicht.
Nee, nein? Nee, hilft nix, weil
du ja immer noch den Namen eingeben musst
irgendwann. Ja, aber wenn
das bei einer Pi-Project-Humil schon gepinnt ist,
richtig, dann
hoffe ich mal, dass du die richtige
gepinnt hast. Beim ersten Mal muss ich
auch, wenn ich das eintrage.
Ja, 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,
siehst du es nie wieder.
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
Toastcode denn da drin steckt oder jedes Mal nachzugucken,
ob denn da in der neuen Version
vielleicht was Falsches drin ist,
dann, ja. Ja, das Problem
haben wir an vielen Stellen, das haben wir natürlich auch bei
Docker zum Beispiel, wenn man sich da irgendwelche Images zieht, wo man
nicht weiß, was da drin ist. Das Problem haben wir auch bei Distributionen,
aber jetzt, wenn man jetzt eine Distribution
nimmt und man installiert per
App 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.
Die können 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 du 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 echt das Problem. Ja, dann haben die doch
keine Software mehr. Viele, viele Sachen.
Ja, bist halt bei Django 2.
irgendwas. Eins. 2.0.
Ja, aber das ist doch Quatsch.
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.
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 Cores ist.
C-O-R-S? 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.
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-Origin Resource Sharing.
Okay.
Das gibt es nicht für WebSockets.
WebSockets haben keinen Kurs.
wenn ich einen Websocket irgendwo hin aufmache,
dann kann ich da drüber alles abrufen.
Oh.
Und das ist, ja,
genau so habe ich auch reagiert.
Das war mir jetzt nicht klar. Oh, shit.
Aha.
Oh.
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.
Prinzipiell kannst du eine Verbindung irgendwo hin aufmachen
und sagen, ja, 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,
wie nennt man das? 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
irgendwie wie nein.
Das ist, wenn
es so ganz überraschend und komisch ist
und man es nicht, dann ist es kein gutes
Zeichen, nein. 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 zu 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ückbringen konnte, wenn ihr denn
mit den News schon soweit seid. Ja, das ist nicht mehr viel.
Es ist noch ein,
tatsächlich jetzt, das 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 irgendwann vorletzte Woche oder so was.
Letzte? Ich weiß nicht mehr genau.
Also tatsächlich. Da müssen wir 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.
Mit 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, so eine Tarnung.
Ja, wenn man letzten Montag in einem Schaltjahr geboren worden wäre, dann hätte man tatsächlich das Problem gehabt, dass man wahrscheinlich in seiner, zumindest der Zahl seiner Geburtstage, die man bisher gehabt hätte, deutlich unter diesen Tagen gewesen wäre.
Das ist gut, dass du das so formuliert hast, weil sonst hätte ich jetzt direkt meinen Mathematiker auspacken müssen.
Mit welcher Formierung habe ich mich gerettet?
Die Zahl der gefeierten Geburtstage,
das ist leider,
ist meine Goldwaage, sagt ja.
Ja.
Tja, ja. Ja, gut.
Genau, aber dann, ach so, doch, eine Geschichte
habe ich noch. Genau, du hattest mir,
Johannes, du hattest mir, glaube 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 der 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 hatte etwas
gebenchmarked. Jemand hat irgendwas gebenchmarked, genau.
Und das Einzige, was ich dazu im Grunde
nur anmerken wollte, also
also
mit so einem
Körnchen Salz
sollte man da vielleicht schon
mit dazu tun, sonst
Also du sagst,
man müsste das mal selber machen.
Das ist das, was ich da raushöre.
Genau, also ich meine, ich könnte das ja auch
ich könnte das bestimmt fortsetzen, ne? Lügen,
dreiste Lügen
haben kurz, ne halt, warte
Benchmark. Ne, aber ich glaube, das ist
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, ja.
Der noch keine eindeutigen Ergebnisse gibt. Du meinst, wir wollen
beweisen, dass Peißen die schnellste Sprache ist unter der Sonne?
Ne, aber vielleicht schnell genug.
Wir wollen beweisen, wie die schnellste,
wie man damit schnell sein kann.
Das ist ein Thema für eine eigene...
Ich glaube, da brauchen wir wirklich...
Da machen wir eine eigene Geschichte zu.
Okay, ich wollte nur sagen, wenn man sich diesen Artikel
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 man sich es dann so anguckt,
wie wenn da so
HTTP-Doodles oder
bei Scenic ist das dann installiert, bei dem anderen nicht
und HTTP-Parsing kann ja dann das Nadelöhr...
Also ich will gar nicht
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, ist klar. Gut, dann
Geschichte einander mal.
Jetzt lacht ihr, Entschuldigung, jetzt müsst ihr mir das erzählen.
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 man mehr
Bandbreite, also dass wir
ein Netzwerk
sinnvoll benutzen hätten können.
Das war das mit dem Gigabit, was du nicht kriegst
ausgelastet.
Was war die erste Zahl,
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...
Nee, also das Ziel dabei ist
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, dass
das macht man halt so. Die Frage ist,
gibt es dafür eigentlich jetzt noch so einen Grund,
weil tatsächlich kann man ja mit Async
und der ganzen Syntax 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? Ja, also wenn ich
jetzt 100 Gigabit saturieren möchte,
hm, okay, dann
nehme ich vielleicht doch was anderes,
aber wenn
ich jetzt sowieso eine relativ, wenn ich jetzt
sagen wir mal so, nur so ein Gigabit habe oder so an einem Server,
dann kann es ja sein, dass es völlig
egal ist, ob ich Nginx 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
angeteasert, aber genau. In der Benchmark-Episode.
Ja.
Genau. Wir wollten übrigens noch so eine
Datentypen-Folge machen. Die haben wir auch noch aufgeschoben.
Nur für alle, die sich darüber freuen. Ja, eine Datentypen-Folge.
Ja.
Ja, okay.
Ja, ist eine spannende Sache.
Gibt's viele schöne Dinge.
Ich hab noch was zum Thema Web-Server.
Hab 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 die dann laufen, wo man sie haben
möchte. Und 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,
es auszuprobieren, aber ich werde, habe mir
vorgenommen, es auszuprobieren.
Ah, sehr cool, weil da gab es nämlich, 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. Auch so, 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, ja,
es ist doch eher so Ruby-and-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 dann halt jetzt auch sowas gebaut, nämlich
das nennt sich Up-Pack-IO
und ist halt auch im Grunde sowas wie
Heroku. Also sozusagen, du kannst dein 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.
Es ist spannend, dass es so viele Firmen
im indischen Ozean gibt. Das ist schon sehr cool.
IO ist indischer Ozean.
Achso.
Ja, hat der
indische Ozean ausnahmsweise
mal was richtig gemacht mit der Wahl
des Top-Level-Winners.
Ja, Glück gehabt.
Glück gehabt.
Pack IO, sagst du.
Jochen, du abtustenst den Link ja sicherlich.
Genau, Up-Pack mit 3P.
Das ist ein bisschen schlecht vielleicht,
ich weiß nicht genau.
Naja, aber genau, ich tue den Link in die Shownotes,
kann man sich das angucken.
Ja. Jetzt haben wir nur noch
Reste übrig, oder? Ja, jetzt haben wir nur noch Reste übrig.
Das ist nur noch der Rest. Da müssen wir jetzt über die Reste
reden. Ja.
Also, wo waren wir eben stehen geblieben,
Johannes?
Ja, als im Vergleich zu
Remote Procedure Call.
Weil, also ich meine, Remote Procedure
Magical, 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 einen Endpoint, wie auch immer der geartet ist, ja, mit dem Java-XML-RPC, 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. 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üher 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 über gar nichts. Und diese Interfaces bauen war auch ganz schrecklich. Da musste man dann so eine Webservice.xml haben und die hat auch nur die Hälfte der Zeit funktioniert.
und dann gab es Versionierung,
wenn dann nicht die richtige Version
von dieser API lief.
Also es gibt ganz viele Stellen,
an denen das einfach zerbricht.
Soap ist prinzipiell eine sehr coole Idee,
aber praktisch habe ich nie erlebt,
dass es angenehm gewesen wäre
oder zuverlässig.
Und ich denke,
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
ist oder eine 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 REST-Seite, den man
an so Sachen wie Soap oder auch
Sachen, wo dann andere Leute versucht haben, Korba
irgendwie zu retten in die neue
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 ihr das Web
dazu zu degradieren, dass das nur ein Transport
Layer ist für eure Idee, die
auch schon vorher eigentlich nicht funktioniert
hat. Also was heißt Korba
in die Webwelt?
Da gibt es eine schöne Organisation
mit dem Kürzel OMG.
Oh mein Gott.
Common Object Request Broker
Architecture. Ja, genau.
Und die hat das standardisiert.
Das ist die Object Management Group.
Und genau.
Ich hatte viel Spaß mit Cobra.
Schon.
Und ja,
das war
auch alles nicht schön.
Das klang
alles nach einer guten Idee.
Und da 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.
Ja, okay. Und in
HTTP selbst ist dann sowas eingebaut
wie, gib mir ein Objekt
oder bekomme ein Objekt.
Genau, HTTP selbst
hat ja erstmal
nicht so viele verschiedene Dinge, die es
garantiert, aber es garantiert
im Wesentlichen einen Pfad
und ein Verb. Und diese Verben
sind sehr
streng limitiert. Also prinzipiell kann man da jedes
Verb mitschicken, aber der Standard hat nur
so eine Handvoll. Und da gibt es insbesondere
Get und Post und Get heißt halt
gib mir und Post heißt
nimm das.
Es gibt noch
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 das Objekt
eine Version
änderst, dann puttest du das komplett.
Und Post? Post ist 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
ein neues und wenn du auf eine
Ja, so ganz klar ist es.
Okay, ja, ehrlich
gesagt, weiß ich auch nicht genau. 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 auf jeden Fall. 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 ist, 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 kann das, hat es schon zwei
Bedeutung. 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 auch, 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 brauche ich mir ums Löschen
von Adre, von Adrecken keine
Sorgen mehr machen. Das ist
jetzt geregelt. Das geht immer.
Was dafür sprechen würde, dass man Post
nicht löscht? Nein, eigentlich
nicht. Genau, mit Post löscht du nie. Post ist
immer nur, Post und Put und Patch
sind immer nur Additiv.
Okay, also, aber okay, 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 dann 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
ein Response zurück, 4.02.
Nee, 2.01 kommt dann zurück.
2.01 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
es kann ja tatsächlich sein, und ich halte das
tatsächlich für sinnvoll, 200 zurückzugeben
in vielen Fällen und nicht 201,
Weil das Objekt, was erzeugt wurde, ja erstens andere Attribute haben kann, die du nicht mit erzeugt hast, zum Beispiel seine eigene Identität oder Verweise auf irgendwas oder Counts von irgendwas.
Und zum anderen kann es ja auch sein, dass nicht alle Attribute angenommen wurden, die du geschickt hast, weil sie halt falsch waren oder weil sie, keine Ahnung, weil du nicht die Berechtigung hast oder sowas.
Ja, aber nicht Berechtigung, sondern wieder was anderes.
Ah gut.
Ja, okay, weil sie halt verworfen wurden. Und dann ist es absolut richtig, meiner Meinung nach, mit 200 das erzeugte Objekt zurückzugeben.
Tja, das kommt ja normalerweise auch beim 201, kommt ja auch das erzeugte Objekt zurück.
Nee, 201 hat keinen Inhalt.
Nein?
Nee, 201 hat normalerweise, sollte keinen Inhalt haben.
Okay, okay, okay, gut, ja, also es ist, okay, ja.
ja. Auch 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 diese,
schlägt quasi diese Abfrage fehl, weil du, weil
kein Content kommt.
Ach je. Auch das, auch damit
habe ich mich schon abgeplagt.
Ja, ja.
Na gut. Ich verplage mich immer mit dem 402
ab.
Was war das nochmal? Kein Geld bezahlt?
Payment required.
Payment required, ja.
Reserved for future use.
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,
da gibt es ja so,
und dann, wie nennt sich das dann immer,
Maturity-Level
irgendwie, Rest, also
hinter diesem ganzen Kram ist ja
so ein Konzept, irgendwie
einer der Leute, die halt
ja auch so
eine der Hauptverantwortlichen
hinter dem Web hat,
steckt halt auch hinter dieser Rest-
Idee, ne, Roy Fielding,
hat da seine Dissertation drüber geschrieben,
ja genau, 2005 ist sie glaube ich erschienen,
und da
genau, kann man
sich angucken, gibt es online, auch als Webseite.
Sehr schön.
Oh, auch sehr interessant.
Link, please. Ja, genau, Link kommt in die
Show Notes. 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.
Der mit diesen 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 is the engine of, genau, Moment, wie war das?
Hey to us. Hey to us, genau. Application state, genau. Hypermedia is the engine of application state, 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 wissen.
Wenn man das wirklich genau wissen will, 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 einen wichtigen 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, Stau, Stau
auf der Datenautobahn. Das macht das
Web halt irgendwie kaputt. Das macht es halt
nicht so, also so eine
Single-Page, ja ich meine Single-Page ist eigentlich
auch ein falter Name, aber so 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 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.
Ja, aber was ist jetzt ein Deep Link wieder?
Ja, wenn du so eine SPA aufrufst,
dann bist du ja jetzt nochmal auf, keine Ahnung,
spa.io, ja?
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
Zelle verweist, damit du deinem Kollegen
sagen kannst, hier, schau dir mal diese Zelle
an. Und
ganz viele SPAs machen das aber nicht. Du kannst
nicht sozusagen
dahin navigieren und dann aus
der Adresszeile den Link rauskopieren.
Weil die eben,
weil du immer noch bei spa.io bist
und sonst nirgends, weil der Zustand, den du
erreicht hast, nur innerhalb der
Anwendung ist und nicht in eben
diesem Hypertext. Das heißt,
du kannst da nicht drauf verlinken. Und das ist
genau das, was sozusagen
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
Slash
Spreadsheet ID Slash Table
Slash
Slash Row 17
Irgendwie sowas, ja?
Solltest du prinzipiell machen können und auch
innerhalb dieser API solltest du eigentlich
nie
irgendwie nur IDs angeben, ja?
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 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 geht. 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 bestimmten Parametern
oder so, kannst du halt auch nicht drauf verlinken.
Das ist schon, genau,
das ist halt irgendwie so eine der wesentlichen Geschichten,
wobei man halt auch sagen muss, also die Idee ist
nett und das Web
funktioniert ja auch so, aber tatsächlich
alle anderen Beispiele, die ich
gehört habe oder die versuchen Leute dann zu konstruieren
für, wo das noch eine gute Idee wäre,
die sind alle ziemlich konstruiert.
Also in diesem Webfall hat es einmal
geklappt, aber ansonsten
also irgendwelche Applikationen,
die ihr UI dadurch aufbauen,
dass sie irgendwie
aus einer API irgendwie ihre Formulare
bekommen und das, wo sie, wo sie
Ja, 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.
Ja. Also.
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 so 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 Leute mit alten
Client-Anwendungen
halt auch deine neue
Geschichten benutzen können und du sozusagen
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.
Das ist 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 hat nämlich jeder von uns
eine Meinung dazu.
Und ich weiß auch mindestens drei
verschiedene Wege, wie man das machen kann.
Aber
ja, das
ich kenne quasi keinen Fall, wo
es sich lohnen würde, verschiedene API-Versionen
gleichzeitig laufen zu haben, was
ja sehr teuer ist erst mal.
Ja.
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 wird das dann einfach ignorieren
und er sagt, oh, das ist für mich nicht interessant.
Also wie bei HTML ist es ja auch so, genau, 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 automatische Forwards-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 sowas wie zum Beispiel, also eigentlich, das sind schon nette Ideen.
Also das HTTP-Stateless ist ja eigentlich cool,
es 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 cashen.
Und kannst du auch 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 zu Recht auch.
Ja, genau. 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. Ja, alles dazwischen 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 & Wells gibt es das,
mit Stimulus und
diese ganzen Hotwire-Geschichten
in anderen Frameworks
kommt das jetzt auch irgendwie, dass man wieder HTML
über WebSockets 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 dem
auf der
Leitung passiert,
der totale Wahnsinn ist.
Weil es eben, weil HTTP stateless ist,
muss da halt immer irgendwie
alles mitgeschickt werden, weil
naja, ist ja stateless. Ja klar, weißt ja nicht,
weißt ja nicht, was der schon hat oder nicht. Genau.
Und das
das ist eigentlich total ineffizient
auch, ehrlich gesagt. Und
deswegen gehen halt dann viele Richtung, ja,
nehmen wir doch einfach WebSocket oder so, da haben wir
dann, das ist halt dann nicht mehr Sadness.
Ja.
Ja, das ist aber auch so eine der,
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 irgendwie sowas. Oder genau diese
Subjekte und genau diese Subjekte.
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 Teil
Ressourcen, 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
ja 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 denn dann da kommt
und das je nachdem, was man halt braucht.
Ja, aber dann hat man im Grunde eben keine Restschnittstelle
und dann hält 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, GraphQL.
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 das ist ja, da macht der Client ja schon viel zu viel.
Das hat dem Client alles nichts anzugehen,
das muss alles der Server machen.
Das ist ja nicht,
da hat der Client viel zu viel State
Und das geht ja alles gar nicht.
Ja, aber das ist ein bisschen unrealistisch.
Gegen Regen argumentieren.
Es ist schlecht, dass es den gibt.
Und der fällt aus dem Himmel runter und der macht alles nass.
Aber es ist halt so.
Ja, ja.
Es ist nicht schwer, sich vorzustellen,
dass es Leute gibt, die ihren Freunden Nachrichten schicken wollen.
Sondern schon brauche ich eine Liste der Leute,
denen ich Nachrichten schicken kann.
Und 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, ja, ich möchte, dass jetzt irgendwas
passiert und deshalb schreibe ich
diese, rufe ich diese Funktion auf, ja.
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, ja, 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, ja, dann sage ich nicht, schicke diese Nachricht an, ja, sondern es, sage ich, 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.
Und 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 eine
Schnittstelle habe für irgendwelche Geräte
oder für irgendwelche
Prozesse,
dann finde ich das schon schwieriger
zu sagen, es soll jetzt dieses
Objekt geben.
Ja, ja.
Wenn ich ein Licht anmache über eine REST-Schnittstelle,
dann heißt das, ich
bearbeite das Lichtaktivierungsobjekt
und setze das Attribut an
auf, ja, anstatt dass ich sage,
mach das Licht an.
Ja, das ist so ein bisschen, ja.
Es erfordert ein gewisses Umdenken.
Ja.
Ja, ja, ja, ja.
Ja, ich überlege gerade, ob man sagen könnte,
man erzeugt einfach ein Event oder so, dann, aber.
Ja, das ist ja dann auch das, was man sich dann.
Ein Kontrollvorgang, dem steht Licht an oder Licht aus.
Ja, genau, wo du dann eben sagst,
wo man sich so ein bisschen behilft, ja,
wo man sich sagt, ich erzeuge jetzt nicht,
ich verändere jetzt nicht das Lichtzustandobjekt,
sondern ich erzeuge ein Lichtanschalten-Wunschobjekt
oder irgendwie sowas, ja.
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,
ich meine, 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 ein paar Mal erwähnt oder so,
ist halt CRUD.
So, 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.
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 da auch ...
Es gibt schon so Sachen, Jochen,
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,
da soll jetzt ein ...
Ich schicke ein Bild an eine Bilderkennungs-API,
dann ist es für mich nicht ...
Ich möchte, dass es dieses Bilderkennungsobjekt gibt, sondern dann sage ich im Wesentlichen, ich möchte, dass jetzt dieses Bild ausgeführt wird.
Ich möchte, dass jetzt mit diesem Bild irgendwas ausgeführt wird.
Und trotz allem, es gibt ja die vorgenannten Puristen, die sagen, alles muss eine REST-Schnittstelle sein und du musst alles 100% RESTful machen,
die dann auch so eine Schnittstelle eben als REST-Schnittstelle machen würden, die mir auch meine Schnittstellen oftmals um die Ohren hauen würden,
weil ich eben so prozedurale Endpunkte
habe, so prozedurale.
Ein
Funktionsobjekt mit folgenden
Parametern wurde angelegt.
Ja, das ist natürlich irgendwie,
also ja, nee, ich meine, es gibt Dinge, die
da nicht so gut reinpassen, wo man dann auch nicht,
gerade bei sowas wie, wenn man jetzt Blobs hat, eben
Bilder oder sowas,
da ist sowieso
schwierig da irgendwie, genau.
Ist ja auch
dann ganz schwierig, das kriegst du ja auch nicht
per Get, so, also das
natürlich, du kriegst
auf jeden Fall nicht mehr bei JSON. Du musst dann halt, wenn du
ByteRange pressst, ob du irgendwelche Blobs machst, dann
da gibt's... Moment, wenn du über ByteRange
denkst, dann irgendwelche Blobs. Also ein Blob ist irgendwie eine Art
Datei-Objekt 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 an Minute 30
weil, anfangen
zu hören, weil da beginnt
der interessante Teil über REST.
Aber das ist ja tatsächlich
bei REST nicht vorgegeben,
welche Datenstrukturen 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.
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 das war so eine Offenbarung,
dass so was geht
und dann so schön die Schnellen 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, ja?
Genau, der stellt dieses Formular
zur Verfügung, der stellt auch den JSON-Datentyp
zur Verfügung, also 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
ja, Application
irgendwie ein binäres Name. Binary.
Weiß ich nicht. Octet. Octet-Stream.
Ja.
Ja, ja, ja. Nee, stimmt schon. Also insofern
würde das da auch reinpassen. Ja.
Ganz kurz nochmal. Octet-Stream. Was ist das denn?
Ja, Octet ist ein cooler,
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 halt als Mime-Typ oder als Datentyp
heißt es Application-slash-Octet-Stream.
Heißt einfach nur
irgendwelche Daten, keine Ahnung.
Okay, Octet-Stream.
Auch gerade, wie er zum ersten Mal drüber gestolpert hat, das ist ja Wahnsinn.
Wie lange macht er das eigentlich schon? Ich weiß es nicht.
Zu lange.
Also ja, okay, dein REST-Framework haben wir jetzt gerade, 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, was ist das denn? Geht das auch REST oder?
Options ist wie Get 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.
Ja, 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 Zwei-Stunden-Episode ist, also eine von den kurzen, dann …
Geradezu mickrig, kurzen.
Meine Frau hat sich vorhin drüber lustig gemacht,
dass wir immer so lange eine Episode aufnehmen.
Aber ich habe gesagt, das ist halt so.
Dann möchte ich eben nicht
die gesamte,
möchte ich nicht diese ganze
Episode auf einmal abrufen, sondern ich möchte erst mal
sehen, ob ich die überhaupt verwenden kann.
Und dann schicke ich da einen 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 die
ob diese Anfrage sinnvoll ist.
Ja, okay.
Interessant.
Aber um jetzt wieder zu
REST-APIs 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, da habe ich auch viel.
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 es 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
naja, wenn du
irgendwie, keine Ahnung, also das, was halt so
gibt es ja viele, viele, die
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 für
auszugeben, weil es gibt so wahnsinnig...
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 irgendwie es ist
einfach nicht so geil. Es ist meistens
irgendwelche, naja,
doch eher so technisch herausgeforderte
Hoster. Das 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 irgendwie 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ährend,
würde ich jetzt mal so sagen,
wenn du halt
dann sowas machst wie die Django REST Framework oder so,
da ist plötzlich
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 mehr Wert,
wenn das halt gut funktioniert und man ein
nettes Interface hat, wo man die API
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. Also 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 ja eben schon kurz sprachen.
Das klingt doch ganz interessant.
Was war das?
Django REST Framework.
Dominik, erzähl mal,
ich habe gleich noch eine
kleine Randnotiz.
Was war das für eine Authentifizierung?
Jot JWT.
Ah, echt?
Ja, das ist Java JSON Web Tokens.
JSON Web Tokens?
Aber da gibt es ja Bibliotheken.
Also ich meine, das ist ja nur ein PIP-Installed entfernt.
Ja, aber da gibt es ja 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 ...
Ja, aber die Frage ist, warum der Standard nicht okay ist.
Wenn ich das richtig verstanden habe,
weil es verschiedene Möglichkeiten gibt,
diese Schlüssel zu erzeugen oder überhaupt diese Token zu erzeugen.
Weil es so viele Konfigurationen gibt.
Weil du sozusagen so Downgrade-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.
Ja, also das ist halt ...
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 Kleinteil 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 in der Rainbow Table nachgucken kann oder sowas.
Ja, oder halt auch gar keinen.
Wenn du sagst, naja, Verschlüsselung, naja, kann ich nicht.
Das ist eben wirklich so
die Frage,
was ist jetzt gerade der aktuelle
Zustand der Sicherheit? Und eigentlich müsste man sich da
sehr gut drum kümmern.
Und also 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 der mehr oder
weniger klipp und klar gesagt hat, JVT werden wir
in Django niemals machen. Das ist irgendwie...
Jott?
Was ist das?
Ich glaube, man sagt Jot.
Dominik, du bist der Einzige, der Jot sagt.
Ich habe das im Blogpost gelesen von
Toni, der das schrieb.
Vielleicht ist das richtig, ich weiß es nicht.
Schöne Grüße.
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. Genau, das ist halt die
offizielle Alternative, sozusagen
jedenfalls, so wie es
in dem offiziellen Django
Podcast, Django Chat von
Carlton Gibson, einem der offiziellen
Django-Maintenner.
Der übrigens ein total netter Kerl ist.
Der ist total nett, ja.
Sometimes pronounced Jot, sagt Wikipedia.
Sometimes pronounced.
Sometimes pronounced. Ich versuche es dann mal
jedes dritte Mal zu machen.
Genau, der sagt halt.
hier im Rheinland sagt man doch JWT.
JWT, JWT.
Egal, ja.
Es ist noch immer
Jotje-Jange oder so, ne?
Es gibt doch so andere Token-Typen auch noch,
oder? Ich vergesse nicht, wie die heißen.
Paseto zum Beispiel. Paseto,
genau, danke. Aber das ist ja genau das Gleiche.
Aber du wolltest gerade irgendwas aus dem Django-Tet-Talk erzählen.
Genau, genau. Also da
war halt sozusagen die Ansage, na,
nimm doch einfach die normale Session-Authentication.
Die ist halt so ein bisschen
unkomfortabel und so, aber
auch nicht so arg, ganz ehrlich.
Ja, so arg unkomfortabel.
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,
ja doch, kannst du schon,
aber 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 es mit Job machen.
Dann kann man dabei bleiben, da 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 meine Session
klauen will oder sowas und dann
Ja, kann er machen, aber
das verhindert der Browser.
Ja, aber ja, egal.
Es ist kompliziert.
Das mit der Authentifizierung ist auch noch nicht so richtig abschließend.
Ich bin überrascht
immer, ich habe mich da schon ein paar Mal Gedanken
gemacht und ich war immer überrascht,
dass es da keine einfache fertige Antwort gibt.
Wie wenig gelöst es ist.
Sondern, dass man immer denkt so,
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.
Das machen wir 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.
Okay, Authentifizierung über REST.
Es ist erstaunlich ungelöst.
Ja, REST ist ja erst mal
keine, ist ja erst mal nur eine ganz normale
HTTP-Webseite. Also du kannst Authentifizierung
machen mit allen Mechanismen, die du da
oder halt auch nicht. Ich meine,
wir haben auch, wir haben früher alle die Webseiten
gesehen, die die PHP-Session-It
die die PHP-Session-It
als Get-Parameter drin hatten und
ja, durfte man halt nicht
kopieren.
Dann durfte man halt die Links nicht verschicken, ne?
Ja.
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ß jetzt wahnsinnig
gar nicht mehr, wie man das ausspricht, vielleicht spricht man das auch J aus.
Nein, Flask.
Ich weiß es nicht genau.
Ich spreche alle Sachen immer falsch aus.
Flaske, Jochen.
Flaske.
Jaisson.
Jaisson, ja, oui.
Genau, da verwendet man eher Marshmallow,
Das gibt es auch für Django,
aber da verwenden wir es
in 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 denn noch Flask, Jochen?
Ja, aber genau, da wäre Hot Take.
Ich würde ja sagen,
so,
jetzt habe ich ja etwas ganz Gemeines.
Oh, oh, Jochen,
jetzt machst du die Tore
für Flameworks auf.
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, ja, 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 FastAPI?
Also, Meinung
Weil ich dir so eine API schreiben will.
Hallo at PythonPodcast.de, da könnt ihr gerne
eure Kommentare oder ein paar Aspray
an uns kommentieren,
jederzeit erwünscht hinterlassen. Machen wir
mal so eine Episode, wo wir die vorlesen einfach.
Die Mail? 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 freuen wir uns immer. Es gibt ein sehr
schönes Buch von einem Science-Fiction-
Autoren, das heißt Your Hate Mail Will Be
Graded, wo er
einfach Post,
Fanpost, sagen wir es mal in Anführungszeichen,
die an ihn geschickt
würde, diskutiert.
Hm, ja.
Und sowas,
Jochen, du wirst jetzt sicherlich,
ihr werdet jetzt, jetzt wo du das gesagt hast,
das Flask, das umfasst
ja auch alle anderen alternativen
APIs, alle
anderen alternativen Systeme.
CherryPi, Pyramid,
Ripos, Soap.
Gab ja eine neue
Version, Pyramid 2.0, voll gut.
Nee, ich weiß es ehrlich gesagt gar nicht so
genau, was FastPyramid, 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?
Das ist super. Ja, Bottle, ja. Bottle gibt's.
Es ist super klein.
Ja, das ist kleiner
als Flask, deshalb heißt es ja so.
Ja.
Aber ich meine,
tatsächlich FastAPI würde ich jetzt aus meiner
Perspektive, es macht im Grunde das, was Fast macht.
Mehr oder weniger. Hat auch, also ich weiß
jetzt nicht im Vergleich zu Fast, aber hat mehr Stars bei GitHub.
Auf jeden Fall als Bottle. Na, super.
Ja, aber das ist doch,
also Fast-API ist doch wirklich nur
für APIs gedacht, oder? Nee,
du kannst, also ich hab damit auch schon Webseiten, du kannst,
das Problem, also 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?
Genau, Starlet ist halt sozusagen das
Ding da drunter.
Die Werbung ist on par
mit Node.js and Go.
Ja.
Ja, das besprechen wir
in der Benchmark.
War das wieder ein
Benchmark, der legal war?
Aber du hast halt, aber 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 Daten.
Alle Leute, die sich damit nicht abfinden wollen, können auch
bitte an
welche Willadresse schreiben.
Hallo, at pythonpodcast.de
Def0, at fein.
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, ja, in Django mit den Descriptoren.
Aber
in FastAPI ist er 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
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
OpenAPI heißt das jetzt irgendwie,
dass
sich aus dem Schema
quasi das Frontend generiert.
Es ist halt 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 funktioniert eigentlich sehr gut.
Sieht echt gut aus und 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 Jungle-Rest-Framework
gemacht hat. Wie hieß es denn gleich noch?
Ja, das ist ja
Tom, na, wer heißt
er noch? Christy.
Tom Christy, genau.
Der hat auch
Starlet gemacht.
Ah, ist das Starlet?
Ja, ja. Und wie hieß, wie hieß
dieses, das hieß Star API oder irgendwie sowas?
Fast API, meinst du, oder?
Nee, dieser Standard,
den er da sich ausgedacht hat. Ach, ich weiß es nicht mehr.
Ach ja, das gab's auch. Er hat
auch ein API-Ding gemacht.
Ja, ja, aber, ja, ob das...
Das war nur sehr kurzlebig, oder?
Ja, also jedenfalls habe ich davon dann irgendwann
nichts mehr gehört. Es war auch eine coole, da waren auch coole Ideen dabei.
Da war zum Beispiel sowas dabei, wie, dass du dann halt auch
gleich Kommando-Zeilen-Interface kriegst und so.
Aber irgendwie...
Was ist denn jetzt da?
Das wäre auch schon wieder
ein super Schwung.
Das ist das, was FastAPI darunter
verwendet.
Das ist quasi von einem Blame-Entwickler, der
Dango Resprimer gemacht hat und das hat dann
FastAPI-Benutzung.
Verstehe.
Top Christy macht eine Menge coole Sachen.
Der hat auch
einen Nachfolger von Requests.
Die Requests-Bibliothek hat so ein
HTTPX. Genau.
Hat so ein bisschen ein Problem. Und zwar
einmal ist sie so
slightly unmaintained
so ein bisschen 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 async wird, dann will man
auch so async HTTP-Requests machen
und 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.
Aber es geht halt nicht mit async.io oder so
einfach.
Ja, und HTTPX 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.
Genau, man kann es so verwenden, wie man es gewohnt ist.
Man verwendet einfach HTTPX anstelle von Requests.
Ja, auch sehr nett.
Aber tatsächlich irgendwie ein bisschen langsam manchmal.
Ich weiß nicht so genau.
Naja. Ich verwechsel es immer
mit HTMX.
Das ist eine
JavaScript-Bibliothek, die
Elemente interaktiv macht.
Ja, das ist auch interessant.
Aber ich
verwechsel es immer.
Ja.
Genau, also ja.
Das sind so, ich weiß nicht, ob ihr jetzt noch,
also Marshmallow, Django REST Framework,
FastAPI mit
Swagger Pidentic. Man kann
dieses Swagger-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 OpenA, also
dieses OpenA-API-Share, was
dann zu einem Swagger-File.
Das ist da auch 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, um es jetzt mal so zu sagen,
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.
Ja, das ist von
Facebook, oder? Das ist Facebook, das
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-
Konventionen 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 grafförmige Daten,
ich meine, da passt halt
auch normales SQL, man kann ja sonst auch
normales SQL nehmen,
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, da hast du immer Sicherheit.
Ihr habt das kurz übersehen, was war jetzt gerade
der Joke dahinter?
Da war ein bisschen tieferer Druck 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.
Du hast keine Sicherheitsabfragen.
Mit SQL kannst du alles machen.
Ja, ja.
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 dieser ganzen Python
Async-Geschichte,
hinter Async.io und so.
Die machen
ein Ding namens EdgeDB
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,
das ist vielleicht eventuell eine Konkurrenz zu GraphQL
oder so, ich weiß nicht genau.
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 Sequel.
Und GraphQL,
nein, falsch.
Nee, da gibt es sowas gar nicht.
Du kannst bei
bei REST kannst du halt nicht
sagen, was du gerne hättest oder du kriegst es halt.
Genau, es sind immer einzelne Objekte
und immer ganze Objekte.
Oder Listen von Objekten oder sowas.
Ja gut, du kannst halt natürlich
unterschiedliche URLs machen, die dann unterschiedliche
Sachen liefern, aber du kannst halt
jetzt nicht, das wäre halt
nicht REST-komfort. Eigentlich,
genau, hat jedes Objekt
in REST 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 da 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 Hateras drin ist, weil die nirgendwo verlinkt sein kann.
Jetzt musst du nochmal kurz erklären, was Hateras 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-Serializer beim Dango REST-Framework.
Hyperlinks, Serializer, genau, ja, das ist ...
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 Options
kriegst du eigentlich die Header zurück.
Da kriegst du eigentlich die Header zurück
und dann müsstest du dir wieder irgendwelche
X-Header überlegen,
die auch nicht standardkonform sind,
die du auch, 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. Ich glaube, da gibt es auch eine Möglichkeit,
Parameter zu definieren.
Aber es ist eben nicht mehr
in der API selber drin, sondern es geht
über die API hinaus. Und das ist
eigentlich nicht was, was man möchte. Es ist nicht
erfahrbar. Gut, aber das ist ja schon wieder
jetzt sowas, wo es halt regnet und
du willst halt, jeder möchte irgendwelche
Dinge filtern. Ja klar und
deshalb hat da jede REST
API auch sowas. Aber es ist eben
nicht offensichtlich. Wenn du die zum ersten Mal benutzt, dann
weißt du nicht, dass es da ist.
Du findest es eventuell erst, wenn du sie
fünf Jahre lang benutzt hast. Und das
ist eigentlich nicht gut.
Und GraphQL ist jetzt wieder so ein kleines bisschen
einen Schritt in Richtung Remote Procedure Call,
wo du eben nicht sagst,
gib mir folgendes Objekt, sondern
es ist mehr so, führe bitte folgende Abfrage
aus.
Du hast halt eine Schritte von Objekten, die in
einer Kette liegen. Du hast halt
auch nicht eine URL für die unterschiedlichen Geschichten,
sondern du hast halt eine URL,
an die alles geht. Und
es gibt nicht mehr Delete,
Pad, Putsch,
Putsch, der
mächtigste aller
Aber auch
sehr teuer.
Funktioniert nicht immer.
Genau.
Es gibt
eben diese ganzen Werben nicht. Es gibt nur
Post. Das war's.
Und ja, das ist natürlich
Ja. Hat andere Vor- und Nachteile.
Ja, es hat halt andere Trade-Offs
irgendwie. Okay, also
ich kann aber dann tiefer reingucken
und bekomme
andere, deutlich fokussiertere
Daten schneller
oder, worum geht es bei der Grafik?
Ja, 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. Und
anstatt, dass du dann halt in deiner Übersichtsliste,
so wie es bei REST ist, erstmal
alle abrufen musst, um den Namen anzuzeigen,
führst du halt
Designer-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 Datenbank-Interface
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
ich versuche
jetzt mal abstrakt zu
visualisieren, wolkige
Datenformen hat als tabellenförmige
Datenform? 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
halt irgendwie angeordnet
sind, weil dann wird es halt mit SQL immer so ein bisschen
ätzend, das geht auch, aber es ist halt dann,
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.
Was ja schon schwierig ist,
in der Datenbank abzubilden.
Das ist gar nicht so einfach, das abzubilden.
Was sind deine Lieblingsgrafenstrukturen
in Datenbanken?
Ich weiß es nicht.
Ich weiß, dass der
Auto von FeinCMS
der Treebird
ich weiß nicht genau, was...
Was ich eine ganze Zeit
gemacht habe, ist Nesse Z.
Das geht eigentlich ganz gut.
Aber es ist halt schon
echt haarig. Also
das ist schon so...
Ja, bei
Matthias Pass sind die
Abfragen so bescheuert. Das ist schon
cool, aber die Abfragen sind so blöd.
Matthias Pass, Entschuldigung, ihr habt jetzt gerade wieder irgendwie...
Ähm...
Was habt ihr gesagt?
Dominik googelt.
Ja, also die Frage
ist halt, wie
bildet man solche Strukturen eigentlich
in relationalen Datenbanken 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, also das, was
viele Leute... Und die sind alle schlecht.
Und die sind alle schlecht. Die sind alle blöd.
Ganz ehrlich, es ist einfach schwierig, Graph-Daten, also Vernetzungsnetzwerke in eine Tabelle zu schreiben, weil in der Tabelle kannst du einfach inhärent keine Netzwerke reinschreiben und alles, was man da macht, ist ein Hack und die haben alle Vor- und Nachteile und die sind alle schlecht so.
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, ja, wenn ich
jetzt wissen will, was sind denn jetzt alles
meine Freunde vierten Grades
oder so, dann wird halt, ist halt
auf einer Eskalierdatenbank, ist halt kacke.
War das nicht irgendwie so eine Theorie, die sagte, dass man mit
allen Freunden oder alle Leute, die in
Facebook im Moment am spätesten sind?
Genau, Small World Theorien, ja.
Sechs?
Ja.
Ja, six degrees of separation heißt das.
Okay.
Six 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 und 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 Deep Links drauf machen, was bei einer API nicht ungeheuer schlimm ist, aber ja, es ist einfach mehr Wissen außenrum.
Ja, der Client
ist 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
einfach nur Subscribe und dann
kriegt man per WebSocket halt Änderungen
an dem Query-Set, auf das man
unsubscribed ist. Und dann kann man
tatsächlich, wenn zwei Leute irgendwie den gleichen Kram
editieren oder so,
dann sieht man die Änderung von einem anderen halt direkt oder so.
Und das ist halt, geht alles automatisch, voll gut.
Ja, einfach cool.
Tolle Sachen, ja.
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, die Django, 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 Restriktionstelle 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, aber
wenn da eben zu einem Feld Sortable
drin steht, dann brauchst
du ja gar nichts mehr dazu sagen, weil das ist
eine Standardsache, die jeder braucht und dann kannst
du einfach sagen, okay, ich weiß jetzt, wie Sortable,
dass es auf diesem Feld Sortable ist und
ich weiß, wie Sortable auf diesem, auf
Feldern generell funktioniert.
oder auf Feldern vom Typ String funktioniert,
dann kann ich da einfach diese Sortable-Operation,
diese Sortier-Operation machen.
Und das ist so ein bisschen das,
als ich das zum ersten Mal gelesen habe,
war das auch so ein Moment, wo ich mir dachte,
ah, das ist genau das, was 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.
Also in meine Rails-Applikationen
könnte ich das jetzt sehr leicht reintun.
Leider habe ich davon keine.
Tja, tja.
Ja, schade.
Hätte jemand Lust,
ein Open-Source-Projekt anzufangen?
Oh.
Ja.
Lust schon.
Falls sich Sponsoren für dieses Unternehmen finden,
Die melden sich bitte bei hallo-at-podcast.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.
Bisher habe ich keinen Sponsoren gefunden,
der das bezahlen könnte.
Meine Firma ist leider nicht reich genug,
um sowas Großes anzugehen.
Aber jemand sollte das machen, absolut.
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 einen Podcast,
den ich auch immer höre, weil mich dieses,
im Prinzip dieses Ganze, weil ich
diese,
oh Gott, Hölzchen, Stöckchen,
ich fange mal noch weiter vorne an.
Wir kennen das von Jochen wieder.
Python Podcast ist ja sozusagen
in dem Python-Genre selber gehostet
und
ich bin nicht so richtig super zufrieden damit.
Es funktioniert schon so, aber eigentlich würde mich
natürlich nicht interessieren, wie 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
Podlove ist halt das WordPress-Plugin.
Das ist quasi ein Meta-Podcast.
Ein Podcast aus Podcasten, ja.
Ja, oder über Podcasts heftig, genau. Und da dachte ich, ja, vielleicht dann bin 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, versuche ich da zu stehlen und dann selber zu verwenden.
Und letztens gab es dazu eine interessante Episode zu den Podcast-Clients und zu Feed-Parsing und sowas. Es gab da 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, die sind ja so relativ gehypte Geschichte auch.
und jetzt kommen
Leute wieder auf die Idee, nachdem da
seit zig Jahren,
über zehn Jahren, 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 war so
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?
Also ich müsste mal kurz Gründe nennen, warum es
überhaupt XML gut sein könnte, dass
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 drauf 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
das vergleicht mit sowas wie CSV,
was früher, also
wenn man mit 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 so
Es ist immer eine gute Idee.
Kann man alles machen. Ja, kann man.
Tatsächlich,
aber
ja, also wenn man jetzt
vorher, wenn man jetzt irgendwie sowas wie CSV hat und man
hat jetzt da Probleme, weil irgendwie
Leute machen komische,
schreiben da komische Sachen rein und Dinge gehen kaputt,
dann kann man sich denken so,
mir reicht's.
Diese Barbaren, immer was sie da
für komische Sachen, also tatsächlich, ich habe auch
ja einige Zeit im
Import-Export-Geschäft sozusagen von solchen
Daten verbracht und
da passieren halt die komischsten Sachen,
dass halt irgendwie das
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 standen
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.
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, ein Schema. In einer anderen Datei.
Ah ja, genau.
Und ja,
tatsächlich ist es aber so,
ich würde sagen, eben, das klingt
danach, als wäre das eine Lösung, praktisch.
Jetzt 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.
Nicht die Encodings. Das Encoding war okay, ja.
Encodings sind gut bei
XMR. 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 ein, oder
das wäre sozusagen
das Ding, was ich
dazu
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 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 dann
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, ja, 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 fliegt, da kann man die immer noch fangen
und kann sagen, okay, den Kunden kenne ich.
Der kann sich nicht einigen,
ob er da jetzt
Beton-1 oder UTF-8 oder
CP-51, weiß ich nicht, dieses 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.
Und 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 degraded gracefully sozusagen irgendwie. Das ist okay.
Naja, das ist eine sehr interessante Beschreibung
von Christful Degradation.
Es kommt vielleicht auch drauf an, welche Zeile
das war, aber
im Endeffekt, da
werden Leute nicht wütend oder rufen an,
deswegen oder so, 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 man definiert hat,
wenn das ein leeres Ding ist,
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 Autofahren
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 nicht ausgeschlossen. Du kannst ja
wie auch Jungle Rest Framework bietet ja
den XML
Sequencer.
Wer will das denn lesen? Wer will das denn parsen?
Wer will das denn weiterverarbeiten? Das ist doch alles
total hässlich und dann... Ja, kann doch sein,
dass du irgendeinen Client hast, der das halt
kann er haben. Für Entity and Attributes
of Attributes of Entities.
XML hat ja auch Vorteile.
Zähle uns die doch
bitte auf, Johannes. Nein.
Ich weiß,
dass es welche hat, aber ich will sie 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 Jason.
Das ist,
ich meine tatsächlich, ehrlich gesagt, es hat
auch so diverse Hässlichkeiten
und so, aber Jason
funktioniert eigentlich schon. Also,
das kann man eigentlich auch, also man kann das schon
nehmen. Es ist nicht so schlimm.
Ja. Was war denn diese Datumangaben?
Ich bin ja ein großer Freund von Messagepack.
Ja, ja. Was ist Messagepack?
Messagepack ist quasi binäres
und gepacktes Jason. B-Jason.
Sagt man das so?
Ja, bjson ist noch mal was anderes.
Und es gibt auch bson, also B-S-O-N.
Das ist Binary Serialized Object Notation oder sowas.
Ist auch was anderes.
Das ist das, was in Postgres drin ist.
Und dann gibt es noch hason.
Das weiß ich 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 Message-Pack-Nachrichten
kleiner sind als JSON-Nachrichten
und in einem Mobile-Umfeld war das früher
ein sehr, 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 da war Message-Pack richtig, war ein richtiger,
cooler Vorteil, weil du
halt nichts machen musstest und trotzdem
unter den 65K geblieben bist
normalerweise.
Und das war damals
wichtiger. Heutzutage ist es wichtiger, dass es
lesbar ist, deshalb nimmt man lieber JSON.
Ja.
Ja, oder
andere Leute, die haben direkt komplett
alle Daten, wenn man nicht viele Daten hat, was man auch
ganz gut machen kann, dass man zieht einfach alle
Daten komplett.
Weil man dann halt auch 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 er dran.
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. Das wäre, so wäre es gut, wenn man das
macht.
Und das ist ja schon
Oh, 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 Aggregations-Endpunkte macht
und die dann halt
per Async, also normalerweise würde man sagen
so, ja, viele Requests machen
nicht so cool, weil blockiert halt
immer einen Worker im
Applikations-Server, 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 so geschrieben.
Achso,
Ja, das ist aber
sozusagen nur quasi, wenn man
andere APIs abfragt, das ist natürlich auch
ein Anwendungsfall für iSync, genau, 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 rausschickt, dann...
Microservices.
Ja.
Buzzword.
Bingo.
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 zum Neuesten macht.
Sondern über was? Wahrscheinlich über eine
Message-Queue.
einfach deswegen, weil du dann zum Beispiel
weil du eben, ja und
weil du bei HTTP hast du halt diesen Overhead
immer der Verbindung, die du aufmachen musst und
den
Ja gut, dann kriegst du ja mit Techniken 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 was anderes sagen.
Du wolltest noch was anderes sagen?
Genau, also das wäre halt vielleicht
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 UDFDL. Aber
ja.
Okay. Keine Ahnung.
Ja, okay.
Ich würde sagen, wir haben ziemlich viel bei REST heute gesprochen.
Habt ihr noch irgendwas auf eurer Liste,
was ihr noch losen werden wollt heute? Weil sonst würde ich
nämlich sagen,
Nee, ich hab sonst auch nichts mehr.
Ich fand's schön, viel wieder gelernt.
Ich hoffe, ihr bleibt uns
weiter gewogen, hört uns weiter und
schreibt uns eure Fake, eure Lobhass-Kommentare,
alles, was ihr loswerden
wollt an hallo.peisenpodcast.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ächstes Mal wieder. Alles klar.
Bis dann. Bis zum nächsten Mal. Jo, tschüss.
Wir haben die Pics vergessen. Na, machen wir dann
heute nicht.
Tschö, tschö.