WEBVTT

00:00:00.000 --> 00:00:04.360
Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, heute in der 29. Episode.

00:00:05.240 --> 00:00:09.940
Wir machen heute REST, Representational State Transfer.

00:00:11.380 --> 00:00:16.400
Was ist das eigentlich? Und hier ist der Dominik und ich bin da mit dem Jochen und heute wieder mit dem Johannes.

00:00:16.580 --> 00:00:18.740
Hallo, Glück. Hallo, Johannes. Hallo, Zeigen.

00:00:19.040 --> 00:00:22.380
Ihr kennt uns ja vielleicht schon, wenn ihr gehört habt, wir waren öfter schon mal in dieser Konstellation.

00:00:23.020 --> 00:00:26.600
Das heißt, wir stellen uns heute nicht vor. Aber wie gesagt, wir machen REST, Representational State Transfer.

00:00:28.580 --> 00:00:30.020
Ja, wen frage ich denn zuerst?

00:00:30.100 --> 00:00:30.740
Was ist denn das?

00:00:31.200 --> 00:00:33.420
Ich dachte, wir wollen nicht vielleicht zuerst die News machen,

00:00:33.500 --> 00:00:34.280
weil ich habe da auch noch so ein paar Sachen.

00:00:34.280 --> 00:00:35.800
Nein, nein, wir wollen erst mal kurz das Topic erklären

00:00:35.800 --> 00:00:36.480
und dann machen wir News.

00:00:37.580 --> 00:00:38.700
Kommen wir nicht mehr zu den News?

00:00:39.060 --> 00:00:40.440
Doch, die kommen noch zu den News.

00:00:40.460 --> 00:00:41.440
Na gut, okay.

00:00:41.740 --> 00:00:43.340
Erklär mal ganz kurz, was REST ist.

00:00:43.600 --> 00:00:44.440
Aber nur ganz kurz.

00:00:44.700 --> 00:00:47.180
Ja, das ist Elevator-Picture.

00:00:49.600 --> 00:00:52.460
Also, man stelle sich vor, man hätte da so eine Dampfmaschine.

00:00:52.460 --> 00:00:53.140
Na ja, warte mal.

00:00:53.800 --> 00:01:03.160
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.

00:01:04.220 --> 00:01:07.100
Das ist ja mal krass.

00:01:07.640 --> 00:01:08.660
Genau, das ist das Web.

00:01:08.960 --> 00:01:09.840
Kurz vorm der Anleitung.

00:01:09.960 --> 00:01:15.420
Dann hat man dann so einen Browser und das ist eigentlich REST. Also das Web ist schon REST.

00:01:16.140 --> 00:01:17.400
Okay. Okay, News.

00:01:19.480 --> 00:01:38.460
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.

00:01:39.600 --> 00:01:41.360
das ist für mich so der

00:01:41.360 --> 00:01:43.620
Knackpunkt, was REST zu REST

00:01:43.620 --> 00:01:45.720
macht. Dass man nicht Funktionen

00:01:45.720 --> 00:01:47.100
aufruft, sondern Objekte

00:01:47.100 --> 00:01:49.640
abruft und verändert.

00:01:50.160 --> 00:01:51.660
Okay, jetzt suchen wir jetzt Objekt News ab.

00:01:52.500 --> 00:01:53.640
Jetzt machen wir News?

00:01:53.820 --> 00:01:55.500
Ja, jetzt machen wir News. Gut, okay, machen wir

00:01:55.500 --> 00:01:55.700
News.

00:01:58.040 --> 00:01:58.800
Pattern Matching!

00:01:59.700 --> 00:02:01.460
Pattern Matching ist auch tatsächlich der erste Punkt,

00:02:01.500 --> 00:02:02.820
den ich auf der Liste habe.

00:02:03.220 --> 00:02:05.320
Alle anderen Punkte sind unwichtig. Pattern Matching.

00:02:06.240 --> 00:02:07.320
Case, Switch, Case.

00:02:07.400 --> 00:02:09.480
Hast du da eigentlich dir schon mal Gedanken gemacht

00:02:09.480 --> 00:02:11.440
über Pattern Matching? Nur ganz

00:02:11.440 --> 00:02:13.480
am Rande. Ich habe sogar, ich fand das so gut,

00:02:13.520 --> 00:02:15.420
dass ich direkt einen Blogartikel auf meinen

00:02:15.420 --> 00:02:17.320
selten benutztes Blog

00:02:17.320 --> 00:02:19.380
geschrieben habe, weil das so wichtig ist und so toll,

00:02:20.140 --> 00:02:21.440
dass ich, ja klar, kriegt ihr natürlich

00:02:21.440 --> 00:02:21.980
einen Link dazu,

00:02:22.460 --> 00:02:25.520
dass ich das sofort schreiben

00:02:25.520 --> 00:02:27.000
musste. Und

00:02:27.000 --> 00:02:29.540
Pattern Matching

00:02:29.540 --> 00:02:31.280
ist so ein Feature, was es in anderen

00:02:31.280 --> 00:02:33.440
Sprachen, in vielen funktionalen Sprachen

00:02:33.440 --> 00:02:35.560
gibt, was man auch da kennt.

00:02:36.280 --> 00:02:37.360
Und wenn man das einmal gesehen hat,

00:02:37.480 --> 00:02:38.400
dann kann man nicht mehr ohne.

00:02:39.360 --> 00:02:47.380
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.

00:02:48.200 --> 00:02:50.640
Und habe es aber irgendwann vergessen, dass es das in Python nicht gibt.

00:02:51.260 --> 00:02:53.340
Und jetzt gibt es es irgendwann endlich wieder.

00:02:54.320 --> 00:02:57.100
Ja, aber es gibt doch If-Else. Warum brauche ich denn dann ein Switch Case?

00:02:57.640 --> 00:03:00.600
Ja, das ist prinzipiell richtig. Man kann das alles mit If-Else machen.

00:03:01.240 --> 00:03:03.780
Man kann auch prinzipiell jede Schleife aus While-Loops machen.

00:03:03.880 --> 00:03:06.060
Man kann prinzipiell auch alles aus Goto zusammenbauen.

00:03:07.160 --> 00:03:08.960
Man macht es nicht, weil das nicht gut ist.

00:03:09.360 --> 00:03:32.640
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.

00:03:32.640 --> 00:03:34.120
Was ist ein Variable Capture?

00:03:36.220 --> 00:03:53.340
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.

00:03:55.180 --> 00:04:16.120
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.

00:04:16.120 --> 00:04:39.680
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.

00:04:40.080 --> 00:05:06.220
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.

00:05:06.220 --> 00:05:13.300
Also es ist schon gecastet. Und das heißt Variable Capture, weil eben diese Variable sozusagen aus diesem Muster raus eingefangen wird.

00:05:14.060 --> 00:05:17.020
Das klingt sehr nützlich. Und wenn man das auch mit Typen und so machen kann.

00:05:17.880 --> 00:05:22.740
Das klingt, das ist super nützlich. Gerade das erste Beispiel, was man da sieht, ist eben diese Typen.

00:05:23.300 --> 00:05:33.320
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.

00:05:33.320 --> 00:05:34.680
oder Case 3, dann ist es ein Stereo.

00:05:35.940 --> 00:05:37.500
Das ist so viel

00:05:37.500 --> 00:05:39.300
einfacher, als das mit

00:05:39.300 --> 00:05:41.260
Ifs zu machen. Das ist sehr, sehr schön.

00:05:41.320 --> 00:05:43.140
Ja, fand ich auch. Es gab aber viel Gegenstimmen,

00:05:43.260 --> 00:05:44.740
muss ich sagen. Ja, es gab

00:05:44.740 --> 00:05:47.180
ganz schön Gegenwind. Es gibt ja schon seit einiger Zeit

00:05:47.180 --> 00:05:49.280
irgendwie Leute, denen das alles zu kompliziert wird

00:05:49.280 --> 00:05:51.000
und ich meine, da gab es ja auch diese große

00:05:51.000 --> 00:05:52.340
Kontroverse irgendwie beim

00:05:52.340 --> 00:05:54.920
Walrus Operator.

00:05:55.620 --> 00:05:55.740
Ja.

00:05:56.760 --> 00:05:58.820
Auch bei den Typen, bei dem

00:05:58.820 --> 00:06:00.060
Type Automation.

00:06:01.100 --> 00:06:03.200
3.10 ist doch irgendwie so eine Muss-Version, oder?

00:06:03.320 --> 00:06:05.080
Das ist nicht so eine Kann-Version, was da alles kommt.

00:06:05.180 --> 00:06:06.860
Also die Type-Annotations, die dabei sind,

00:06:07.280 --> 00:06:08.700
dass man einfach hinterschreiben kann,

00:06:09.000 --> 00:06:11.180
die Klasse beispielsweise, die das sein soll

00:06:11.180 --> 00:06:12.680
oder deren Instanz das sein soll,

00:06:13.180 --> 00:06:15.740
ohne dass man da groß Typer importiert.

00:06:15.820 --> 00:06:17.800
Und dann kann man so einen Union-Operator dahinter setzen.

00:06:19.540 --> 00:06:22.220
Und dann kann man da zwei verschiedene Typen haben.

00:06:22.400 --> 00:06:24.360
Das sieht alles total schick aus.

00:06:24.500 --> 00:06:26.180
Also ich finde, so wollte ich das schon immer lesen.

00:06:27.840 --> 00:06:29.760
Ja, also ich weiß nicht so genau.

00:06:29.760 --> 00:06:30.900
ich meine, bei denen, ich finde,

00:06:31.060 --> 00:06:33.520
diese Type Annotations, die

00:06:33.520 --> 00:06:35.420
sind halt an manchen Stellen total nett.

00:06:38.200 --> 00:06:39.520
Ob ich das jetzt an allen Stellen

00:06:39.520 --> 00:06:41.340
im Kult gerne hätte, weiß ich jetzt auch nicht.

00:06:41.440 --> 00:06:43.120
Du kannst ja einfach weglassen, das wäre das Schöne. Genau, genau.

00:06:43.220 --> 00:06:44.580
Ja, man kann es dann, genau.

00:06:45.200 --> 00:06:47.380
Und da, wo es halt Sinn macht, irgendwie,

00:06:47.600 --> 00:06:49.620
da kann man es dann halt dazu tun und dann ist es auch nett.

00:06:49.960 --> 00:06:51.520
Ich finde auch tatsächlich, das mache ich

00:06:51.520 --> 00:06:53.140
in letzter Zeit auch häufiger, irgendwie

00:06:53.140 --> 00:06:55.120
entweder Dataclasses

00:06:55.120 --> 00:06:57.460
Adress oder

00:06:57.460 --> 00:06:58.840
Pidentic verwenden

00:06:58.840 --> 00:07:01.100
und tatsächlich Klassen so

00:07:01.100 --> 00:07:03.280
hinzuschreiben, ist deutlich angenehmer

00:07:03.280 --> 00:07:04.780
als das irgendwie...

00:07:04.780 --> 00:07:05.780
Hatten wir Pydentik schon mal?

00:07:05.860 --> 00:07:08.300
Ich weiß nicht genau, ob ich es mal

00:07:08.300 --> 00:07:11.160
gepickt hatte oder so, kann sein.

00:07:11.580 --> 00:07:12.340
Was macht Pydentik?

00:07:12.460 --> 00:07:14.400
Du hast es auf jeden Fall mal erwähnt, glaube ich.

00:07:15.240 --> 00:07:17.020
Ich verlinke es auf jeden Fall nochmal, das ist ziemlich cool.

00:07:17.180 --> 00:07:18.940
Ja, genau.

00:07:20.280 --> 00:07:21.000
Ja, und also

00:07:21.000 --> 00:07:21.620
ich finde die

00:07:21.620 --> 00:07:24.260
diese Art

00:07:24.260 --> 00:07:27.060
sozusagen das Klassen hinzuschreiben

00:07:27.060 --> 00:07:28.720
sowieso irgendwie, macht irgendwie

00:07:28.720 --> 00:07:31.140
nett. Ich sehe, ich habe auch schon

00:07:31.140 --> 00:07:33.320
irgendwie hier ein paar Identity in der Doku mal rumgewühlt.

00:07:33.540 --> 00:07:34.840
Also eigentlich wollte ich wissen, was das ist, aber

00:07:34.840 --> 00:07:37.140
Ja, das ist so

00:07:37.140 --> 00:07:39.020
eine Art Mischung aus

00:07:39.020 --> 00:07:41.120
MyPi und Data Classes, oder

00:07:41.120 --> 00:07:42.980
Jochen? Man kann leicht

00:07:42.980 --> 00:07:45.040
Datentypen definieren mit bestimmten Typen und

00:07:45.040 --> 00:07:47.040
der prüft die dann auch noch. Genau,

00:07:47.280 --> 00:07:49.400
also es prüft das halt auch zur Laufzeit

00:07:49.400 --> 00:07:51.180
und es ist

00:07:51.180 --> 00:07:52.880
halt auch so, dass man dann halt so eine eingebaute

00:07:52.880 --> 00:07:55.120
Serialisierung nach JSON oder so auch mitkriegt,

00:07:55.680 --> 00:07:57.460
weswegen man es eigentlich auch super für so

00:07:57.460 --> 00:07:59.400
REST-Geschichten verwenden kann.

00:08:00.260 --> 00:08:01.520
REST-Geschichten? Was ist

00:08:01.520 --> 00:08:03.300
das denn, Jochen? Ja, Moment.

00:08:03.820 --> 00:08:05.240
Erstmal die Reste der News, bitte.

00:08:05.720 --> 00:08:06.000
Genau.

00:08:08.920 --> 00:08:09.640
Was haben wir denn

00:08:09.640 --> 00:08:11.380
da noch? Ja, so

00:08:11.380 --> 00:08:13.560
Pattern-Matching, ja, coole Sachen,

00:08:13.660 --> 00:08:15.160
da sind wir uns alle einig, irgendwie komisch.

00:08:15.540 --> 00:08:15.660
Naja.

00:08:17.460 --> 00:08:19.560
Es gibt neue Releases von UV-Loop und

00:08:19.560 --> 00:08:21.000
Async-PG und so,

00:08:22.240 --> 00:08:23.500
aber da war jetzt auch nichts

00:08:23.500 --> 00:08:25.180
weltbewegendes dabei, aber

00:08:25.180 --> 00:08:28.060
Aber Async-PG ist auch so ein Ding, was man sich unbedingt mal angucken kann.

00:08:28.080 --> 00:08:29.720
Ja, ich wollte gerade sagen, wovon hast du gerade gesprochen?

00:08:29.720 --> 00:08:51.660
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.

00:08:52.540 --> 00:08:54.100
TCP-Completion-Ports oder

00:08:54.100 --> 00:08:56.340
IO-Completion-Ports.

00:08:56.400 --> 00:08:58.240
Ich glaube, das ist mehr

00:08:58.240 --> 00:09:00.140
Stuff für die Web-Server-Folge, die wir immer machen.

00:09:00.160 --> 00:09:02.400
Ja, genau, aber auf jeden Fall

00:09:02.400 --> 00:09:04.260
man kann damit schnell IO machen

00:09:04.260 --> 00:09:06.380
und das Ganze halt in der

00:09:06.380 --> 00:09:08.300
Event-Loop und das ist auch das, was unter Node.js

00:09:08.300 --> 00:09:10.000
zum Beispiel drunter liegt und

00:09:10.000 --> 00:09:12.440
genau davon gab es jetzt gerade eine neue Version und

00:09:12.440 --> 00:09:14.380
Async-PG

00:09:14.380 --> 00:09:16.200
ist halt ein Async

00:09:16.200 --> 00:09:18.360
Library,

00:09:18.360 --> 00:09:20.240
um halt auf Postgres zuzugreifen und das

00:09:20.240 --> 00:09:21.440
ist halt auch sehr praktisch, weil also

00:09:21.440 --> 00:09:23.420
das normale

00:09:23.420 --> 00:09:25.620
Psycho-PG, das man so verwendet, kann das

00:09:25.620 --> 00:09:27.600
halt nicht. Und eigentlich wäre das ja auch

00:09:27.600 --> 00:09:29.200
saukool, wenn man das Async machen könnte. Und

00:09:29.200 --> 00:09:30.900
Async-PG ist auch richtig schnell.

00:09:31.540 --> 00:09:33.740
Ich denke, auf Datenbank stelle ich mich schwierig vor mit Transaktionen

00:09:33.740 --> 00:09:35.680
und so, weil... Nö, das ist alles...

00:09:35.680 --> 00:09:37.160
Eigentlich ist das überhaupt kein Problem.

00:09:38.700 --> 00:09:39.480
Also... Es gibt halt nur

00:09:39.480 --> 00:09:41.140
einen Warenzustand dann immer und das ist egal.

00:09:41.140 --> 00:09:43.080
Ja, aber das ist ja okay. Du hast ja auch sonst

00:09:43.080 --> 00:09:45.180
auch... Du kannst ja schon

00:09:45.180 --> 00:09:47.140
mehrere Sachen gleichzeitig machen. Nur ist es halt so, dass du

00:09:47.140 --> 00:09:49.260
normalerweise dann halt warten musst.

00:09:49.340 --> 00:09:50.840
Du schickst halt irgendwie ein...

00:09:50.840 --> 00:09:53.800
an die Datenbank und dann blockierst du halt

00:09:53.800 --> 00:09:54.280
einen Code.

00:09:55.340 --> 00:09:56.780
Das ändert nicht

00:09:56.780 --> 00:09:59.500
die Datenbank, Dominik, sondern es ändert nur,

00:09:59.700 --> 00:10:01.300
wie du die Verbindung der Datenbank hältst.

00:10:03.340 --> 00:10:03.600
Aber

00:10:03.600 --> 00:10:05.480
wo wir gerade bei PsychoPG sind,

00:10:05.560 --> 00:10:07.280
PsychoPG3 ist angekündigt.

00:10:08.280 --> 00:10:11.580
Die koordinieren sich gerade

00:10:11.580 --> 00:10:13.340
mit den Django-Leuten,

00:10:13.340 --> 00:10:15.040
dass die Datenbank-Verbindungen da

00:10:15.040 --> 00:10:16.700
cooler sind. Die haben zum Beispiel

00:10:16.700 --> 00:10:18.900
Connection-Pooling im Adapter drin.

00:10:19.140 --> 00:10:21.040
Das ist auch eine sehr schöne, da hatte ich jetzt letztens

00:10:21.040 --> 00:10:22.960
so ein Problem tatsächlich auch,

00:10:23.100 --> 00:10:25.180
dass irgendwie die Connections rausgelegt

00:10:25.180 --> 00:10:27.240
sind. Bei Django gibt es, glaube ich,

00:10:27.280 --> 00:10:29.040
im Grunde zwei Arten. Entweder

00:10:29.040 --> 00:10:31.000
man macht halt eine Verbindung pro Request oder man

00:10:31.000 --> 00:10:32.860
setzt halt das auf irgendeine Zeit oder so

00:10:32.860 --> 00:10:34.580
und dann wird die Connection so lange aufgehalten.

00:10:35.880 --> 00:10:37.120
Aber, und das war mir halt nicht so

00:10:37.120 --> 00:10:39.160
klar, oder ich dachte, das passiert irgendwie magisch automatisch

00:10:39.160 --> 00:10:40.740
und das passierte nicht, wenn man ein Thread aufmacht,

00:10:41.920 --> 00:10:42.120
dann

00:10:42.120 --> 00:10:44.980
macht das eine zweite Connection auf.

00:10:45.660 --> 00:10:46.880
Und wenn man sich dann nicht weiter

00:10:46.880 --> 00:10:48.960
um den Thread kümmert oder wenn der weggeht,

00:10:48.960 --> 00:10:51.160
dann geht der Thread

00:10:51.160 --> 00:10:52.980
weg, aber die Connection nicht. Und wenn

00:10:52.980 --> 00:10:54.980
man das häufig macht, dann ruft

00:10:54.980 --> 00:10:56.940
irgendwann, dann kriegt man Ärger

00:10:56.940 --> 00:10:58.880
von dem Datenbank-Admin, weil

00:10:58.880 --> 00:11:00.800
der sagt, meine ganzen Connections

00:11:00.800 --> 00:11:02.600
dazu, was zur Hölle macht ihr denn da?

00:11:03.400 --> 00:11:03.560
Ja.

00:11:05.300 --> 00:11:06.720
Ups. Ups, genau.

00:11:08.220 --> 00:11:08.340
Ja.

00:11:10.600 --> 00:11:13.000
Ja, ja, aber Pooling wäre auf jeden Fall

00:11:13.000 --> 00:11:14.960
eine schöne Geschichte, weil manchmal ist ja auch

00:11:14.960 --> 00:11:16.660
eine Verbindung nicht genug und

00:11:16.660 --> 00:11:19.080
ja. Ja, und generell

00:11:19.080 --> 00:11:21.000
ist es ja gut, wenn da ein paar Verbindungen

00:11:21.000 --> 00:11:22.520
offen sind, weil man braucht die halt doch

00:11:22.520 --> 00:11:24.140
häufig.

00:11:26.780 --> 00:11:29.100
Ja, ansonsten, was hatte ich noch gelesen?

00:11:29.260 --> 00:11:30.980
Es gab irgendwie einen Artikel

00:11:30.980 --> 00:11:32.300
zu Security-Geschichten.

00:11:34.080 --> 00:11:35.060
Dependency-Conclusion.

00:11:35.260 --> 00:11:36.020
Ich weiß nicht, ob ihr den auch gelesen habt.

00:11:36.020 --> 00:11:37.740
Es gab einen Artikel zu...

00:11:37.740 --> 00:11:39.500
Es gab da schon ein paar Artikel zu, das stimmt.

00:11:41.200 --> 00:11:41.920
Ja, und das...

00:11:41.920 --> 00:11:43.940
Dependency-Conclusion. Ja, sehr deprimierendes

00:11:43.940 --> 00:11:46.080
Problem, ehrlich gesagt. Das musst du gerade erklären.

00:11:46.180 --> 00:11:47.200
Was ist Dependency Confusion?

00:11:48.500 --> 00:11:50.060
Ja, da gab es doch so ein, da hat auch eine

00:11:50.060 --> 00:11:51.960
dreieinhalbtausend Sachen bei PyPy hochgeladen, oder?

00:11:52.160 --> 00:11:52.420
Ja.

00:11:54.600 --> 00:11:56.520
Und genau, das ist halt

00:11:56.520 --> 00:11:58.420
so, oft, wenn da Leute die

00:11:58.420 --> 00:12:00.640
Version, die sie haben wollen, nicht explizit

00:12:00.640 --> 00:12:02.500
festlegen, dann

00:12:02.500 --> 00:12:04.120
muss man halt nur eine Version haben, die ein bisschen

00:12:04.120 --> 00:12:06.440
höher ist. Oder wenn sie sich

00:12:06.440 --> 00:12:07.740
vertippen. Oder wenn sie sich vertippen, genau.

00:12:09.540 --> 00:12:10.680
Dann kann man das sozusagen

00:12:10.680 --> 00:12:12.420
hijacken und dann kann man den Software

00:12:12.420 --> 00:12:14.220
installieren, die auch im

00:12:14.220 --> 00:12:16.080
großen Grenzen das tut, was

00:12:16.080 --> 00:12:18.220
die erwartet haben, was sie sich installieren

00:12:18.220 --> 00:12:20.080
wollten, aber halt auch vielleicht ein bisschen mehr oder so.

00:12:21.860 --> 00:12:22.260
Also

00:12:22.260 --> 00:12:24.080
ein Beispiel wäre, wenn zum Beispiel jemand eine

00:12:24.080 --> 00:12:26.220
Bibliothek hochlädt, die Django heißt, nur ohne

00:12:26.220 --> 00:12:27.020
D vorne dran.

00:12:28.340 --> 00:12:30.180
Und wenn jemand halt dann Django

00:12:30.180 --> 00:12:32.200
installiert, das geht auch, hat auch

00:12:32.200 --> 00:12:34.160
die gleichen Versionen, aber macht

00:12:34.160 --> 00:12:36.220
halt gleichzeitig, was weiß ich, Bitcoin-Mining oder sonst

00:12:36.220 --> 00:12:38.160
irgendwas oder Backdoors auf oder

00:12:38.160 --> 00:12:40.020
sonst irgendwas. Man weiß es nicht genau. Und da gab es eben so

00:12:40.020 --> 00:12:42.220
einen Vorfall, dass jemand dreieinhalbtausend

00:12:42.220 --> 00:12:44.320
solche Bibliotheken auf PyPI hochgeladen

00:12:44.320 --> 00:12:44.600
hat,

00:12:45.340 --> 00:12:48.240
die sehr suspicious waren und die

00:12:48.240 --> 00:12:49.180
dann auch wieder gelöscht wurden.

00:12:50.200 --> 00:12:52.340
Ja, also der Artikel, den ich da gelesen hatte,

00:12:52.460 --> 00:12:54.200
derjenige, der das gemacht hat, der hat das

00:12:54.200 --> 00:12:56.120
tatsächlich quasi auch im Auftrag von

00:12:56.120 --> 00:12:58.140
größeren Firmen gemacht und

00:12:58.140 --> 00:13:00.220
der hat damit quasi alle großen Firmen aufgemacht.

00:13:00.760 --> 00:13:02.000
Also, und hat da auch

00:13:02.000 --> 00:13:04.080
überall irgendwie quasi das... Ja, okay, das

00:13:04.080 --> 00:13:06.180
habe ich auch gehört. Diese Preisgelder

00:13:06.180 --> 00:13:08.560
dafür gekriegt, die man halt für...

00:13:08.560 --> 00:13:09.660
Millionenweise. Ja.

00:13:10.380 --> 00:13:11.780
Also das war, das hat sich gelohnt.

00:13:12.220 --> 00:13:14.040
Ja, auf jeden Fall.

00:13:15.000 --> 00:13:16.620
Und das ist auch wirklich ein fieses Problem

00:13:16.620 --> 00:13:18.500
und es gibt eigentlich nicht so, es ist

00:13:18.500 --> 00:13:20.420
so ein bisschen doof. Also Poetry

00:13:20.420 --> 00:13:22.420
könnte doch da helfen, oder? Wenn ich jetzt irgendwie die Hashes

00:13:22.420 --> 00:13:24.320
von den Dependencies da mit... Nee, leider nicht.

00:13:24.540 --> 00:13:25.900
Nee, nein? Nee, hilft nix, weil

00:13:25.900 --> 00:13:28.460
du ja immer noch den Namen eingeben musst

00:13:28.460 --> 00:13:30.480
irgendwann. Ja, aber wenn

00:13:30.480 --> 00:13:32.620
das bei einer Pi-Project-Humil schon gepinnt ist,

00:13:33.020 --> 00:13:34.300
richtig, dann

00:13:34.300 --> 00:13:36.100
hoffe ich mal, dass du die richtige

00:13:36.100 --> 00:13:38.580
gepinnt hast. Beim ersten Mal muss ich

00:13:38.580 --> 00:13:40.140
auch, wenn ich das eintrage.

00:13:40.900 --> 00:13:42.980
Ja, und jemand muss aufpassen.

00:13:45.020 --> 00:13:45.800
Was meinst du mit jemand?

00:13:46.620 --> 00:13:48.060
Ja, du siehst es ja nicht, du merkst es ja nicht.

00:13:48.120 --> 00:13:48.560
Das geht ja.

00:13:50.020 --> 00:13:51.920
Das funktioniert ja, das macht ja genau das, was es soll.

00:13:52.480 --> 00:13:54.580
Nur halt irgendwann auch noch was anderes.

00:13:55.280 --> 00:13:57.680
Und wenn du nicht gerade dann drauf guckst,

00:13:58.040 --> 00:13:58.700
siehst du es nie wieder.

00:13:58.760 --> 00:14:00.560
Das ist ja immer das Problem mit irgendwelchen Dependencies.

00:14:00.760 --> 00:14:03.660
Also wenn man irgendwie sich sowas wie PyPy auf den Rechner holt

00:14:03.660 --> 00:14:06.180
oder Node.js oder was auch immer

00:14:06.180 --> 00:14:08.320
und irgendwelche Pakete von irgendwo installiert,

00:14:08.320 --> 00:14:10.180
ohne genau zu wissen, was für ein

00:14:10.180 --> 00:14:12.280
Toastcode denn da drin steckt oder jedes Mal nachzugucken,

00:14:12.400 --> 00:14:14.140
ob denn da in der neuen Version

00:14:14.140 --> 00:14:16.160
vielleicht was Falsches drin ist,

00:14:16.220 --> 00:14:18.280
dann, ja. Ja, das Problem

00:14:18.280 --> 00:14:20.220
haben wir an vielen Stellen, das haben wir natürlich auch bei

00:14:20.220 --> 00:14:22.160
Docker zum Beispiel, wenn man sich da irgendwelche Images zieht, wo man

00:14:22.160 --> 00:14:24.480
nicht weiß, was da drin ist. Das Problem haben wir auch bei Distributionen,

00:14:24.520 --> 00:14:26.240
aber jetzt, wenn man jetzt eine Distribution

00:14:26.240 --> 00:14:27.980
nimmt und man installiert per

00:14:27.980 --> 00:14:29.260
App irgendwas bei Debian oder so,

00:14:30.000 --> 00:14:32.200
dann kann man ja davon

00:14:32.200 --> 00:14:34.280
ausgehen, wenn man jetzt nicht, was natürlich auch viele Leute

00:14:34.280 --> 00:14:36.080
machen, was natürlich auch wieder so ein Ding ist, wo man sich

00:14:36.080 --> 00:14:38.240
sagen kann, aus Sicherheitsperspektive

00:14:38.240 --> 00:14:39.960
ist das ganz übel, wenn man da halt

00:14:39.960 --> 00:14:41.940
irgendwelche Dritt-Repositories

00:14:41.940 --> 00:14:44.440
sich reinholt.

00:14:44.500 --> 00:14:45.740
Die können auch alles installieren.

00:14:45.900 --> 00:14:47.760
Das ist den meisten Leuten vielleicht auch nicht so ganz klar.

00:14:49.000 --> 00:14:50.240
Aber wenn man jetzt nur die

00:14:50.240 --> 00:14:52.320
Debian-Repositories

00:14:52.320 --> 00:14:53.960
drin hat, dann kann man ja davon ausgehen,

00:14:54.060 --> 00:14:56.000
okay, das hat irgendeiner, der das maintained,

00:14:56.060 --> 00:14:58.200
hat sich das angeguckt, hat geguckt, ob das die richtige Software

00:14:58.200 --> 00:14:59.420
ist, hat daraus ein Paket gebaut,

00:15:00.020 --> 00:15:02.040
hat das Ganze signiert und so. Und dann kann man sich schon

00:15:02.040 --> 00:15:04.020
relativ sicher sein, okay, das, was da landet,

00:15:04.460 --> 00:15:06.380
ist tatsächlich nicht irgendeine Malware

00:15:06.380 --> 00:15:08.220
oder so. Aber welche Python

00:15:08.220 --> 00:15:08.980
Version haben die gerade?

00:15:09.800 --> 00:15:12.220
Genau, das ist

00:15:12.220 --> 00:15:12.800
das Problem.

00:15:13.800 --> 00:15:16.120
Und diese ganzen Bibliotheken musst du ja dann

00:15:16.120 --> 00:15:17.900
auch, du kannst ja dann nicht mit PIP irgendwas installieren,

00:15:18.000 --> 00:15:19.900
sondern musst ja dann eigentlich. Und ich

00:15:19.900 --> 00:15:21.900
kenne solche Firmen, ich habe Kunden

00:15:21.900 --> 00:15:23.820
gehabt, die das gesagt haben, wir wollen

00:15:23.820 --> 00:15:25.760
keine Dependencies reinholen von

00:15:25.760 --> 00:15:28.060
irgendwoher, sondern wir wollen die Betriebssystempakete

00:15:28.060 --> 00:15:29.880
haben und dann hast du echt das Problem. Ja, dann haben die doch

00:15:29.880 --> 00:15:31.540
keine Software mehr. Viele, viele Sachen.

00:15:32.580 --> 00:15:33.820
Ja, bist halt bei Django 2.

00:15:34.260 --> 00:15:35.780
irgendwas. Eins. 2.0.

00:15:37.120 --> 00:15:38.040
Ja, aber das ist doch Quatsch.

00:15:38.220 --> 00:15:40.160
dann mache ich doch lieber irgendeinen Server auf, der vielleicht kompromittiert

00:15:40.160 --> 00:15:42.260
werden kann und mache dann andere Sachen

00:15:42.260 --> 00:15:44.240
sicher. Mache dann Singles, Point of

00:15:44.240 --> 00:15:46.360
Truth oder sowas und dann habe ich halt die Daten

00:15:46.360 --> 00:15:47.680
abgesichert über eine Authentifizierung.

00:15:49.620 --> 00:15:50.200
Weiß nicht.

00:15:50.640 --> 00:15:52.240
An irgendeiner Stelle musst du irgendjemandem

00:15:52.240 --> 00:15:54.000
vertrauen und das ist ein Problem.

00:15:54.740 --> 00:15:56.000
Und selbst wenn es nur derselbe ist.

00:15:56.400 --> 00:15:57.800
Und das ist meistens der größte Fehler.

00:16:00.620 --> 00:16:02.120
Ja, aber zum Thema Sicherheit

00:16:02.120 --> 00:16:03.600
habe ich auch noch was sehr Interessantes gelernt.

00:16:04.960 --> 00:16:06.300
Ihr wisst ja sicherlich, alle

00:16:06.300 --> 00:16:08.160
die zuhören, wissen sicherlich, was Cores ist.

00:16:08.220 --> 00:16:10.380
C-O-R-S? Cross-Origin

00:16:10.380 --> 00:16:11.000
Requests

00:16:11.000 --> 00:16:13.440
Safety? Security?

00:16:17.080 --> 00:16:18.140
Oh, das ist eine gute Frage.

00:16:18.240 --> 00:16:18.740
Weiß ich jetzt gar nicht.

00:16:20.340 --> 00:16:22.120
Ich weiß es auch nicht, aber ich weiß, dass es das gibt.

00:16:22.380 --> 00:16:24.120
Ich weiß, dass es das gibt und ich weiß, dass

00:16:24.120 --> 00:16:26.180
das sehr gut ist, weil das bedeutet, dass man nicht einfach

00:16:26.180 --> 00:16:28.060
irgendwoher Ressourcen abrufen kann.

00:16:28.920 --> 00:16:29.580
Resource Sharing?

00:16:30.100 --> 00:16:32.160
Ah, okay. Cross-Origin Resource Sharing.

00:16:32.160 --> 00:16:32.440
Okay.

00:16:34.060 --> 00:16:35.980
Das gibt es nicht für WebSockets.

00:16:36.360 --> 00:16:37.340
WebSockets haben keinen Kurs.

00:16:37.940 --> 00:16:39.740
wenn ich einen Websocket irgendwo hin aufmache,

00:16:39.880 --> 00:16:41.320
dann kann ich da drüber alles abrufen.

00:16:43.060 --> 00:16:43.320
Oh.

00:16:44.160 --> 00:16:45.600
Und das ist, ja,

00:16:45.800 --> 00:16:47.400
genau so habe ich auch reagiert.

00:16:47.800 --> 00:16:49.820
Das war mir jetzt nicht klar. Oh, shit.

00:16:50.020 --> 00:16:50.260
Aha.

00:16:54.260 --> 00:16:54.660
Oh.

00:16:56.820 --> 00:16:57.220
Genau.

00:16:57.700 --> 00:16:59.320
Also die Annahme ist, dass der

00:16:59.320 --> 00:17:01.940
Server das macht, dass der den Origin-Header überprüft

00:17:01.940 --> 00:17:02.820
und das dann halt ablehnt.

00:17:04.740 --> 00:17:05.180
Aber

00:17:05.180 --> 00:17:06.100
prinzipiell muss er das nicht.

00:17:06.300 --> 00:17:08.400
Prinzipiell kannst du eine Verbindung irgendwo hin aufmachen

00:17:08.400 --> 00:17:10.220
und sagen, ja, ich bin der Websocket

00:17:10.220 --> 00:17:11.040
von so und so.

00:17:12.220 --> 00:17:14.300
Und ja. Also das ist doch so

00:17:14.300 --> 00:17:15.460
eine Sache, wenn das im Header drinstehen müsste,

00:17:16.200 --> 00:17:18.360
macht dann nicht sowas wie Django Channels

00:17:18.360 --> 00:17:20.000
sowas in den Headers mit,

00:17:20.700 --> 00:17:21.820
wie nennt man das? Das weiß ich nicht.

00:17:22.080 --> 00:17:24.240
Und das ist genau das Problem. Und es ist auch,

00:17:24.320 --> 00:17:25.960
glaube ich, nicht die Aufgabe von Channels, sondern es

00:17:25.960 --> 00:17:28.260
wäre eigentlich die Aufgabe von dem

00:17:28.260 --> 00:17:30.140
terminierenden Webserver. Und auch da

00:17:30.140 --> 00:17:31.960
weiß ich es nicht.

00:17:32.080 --> 00:17:34.080
Und weiß ich nicht, ist in der Sicherheitswelt

00:17:34.080 --> 00:17:34.820
irgendwie wie nein.

00:17:34.820 --> 00:17:35.960
Das ist, wenn

00:17:35.960 --> 00:17:38.840
es so ganz überraschend und komisch ist

00:17:38.840 --> 00:17:40.720
und man es nicht, dann ist es kein gutes

00:17:40.720 --> 00:17:42.780
Zeichen, nein. Auch da habe ich

00:17:42.780 --> 00:17:44.300
einen Link gefunden, der

00:17:44.300 --> 00:17:46.500
das alles erklärt und wie man damit umgeht und so weiter.

00:17:46.640 --> 00:17:48.140
Damit verlinken wir einfach.

00:17:48.720 --> 00:17:50.660
Aber ich habe zu Kurs was gelesen in

00:17:50.660 --> 00:17:52.760
Django REST Framework, weil

00:17:52.760 --> 00:17:54.900
die nämlich inklusive Sockets das integrieren wollen mit Kurs.

00:17:56.200 --> 00:17:56.840
Steht zumindest

00:17:56.840 --> 00:17:57.440
in dem Feature.

00:17:58.840 --> 00:18:00.800
Ja gut, dann überprüfen die das halt. Das ist ja

00:18:00.800 --> 00:18:01.100
sehr gut.

00:18:02.240 --> 00:18:03.040
Was uns

00:18:03.040 --> 00:18:05.220
zu unserem Topic drückbringen konnte, wenn ihr denn

00:18:05.220 --> 00:18:07.220
mit den News schon soweit seid. Ja, das ist nicht mehr viel.

00:18:08.300 --> 00:18:08.940
Es ist noch ein,

00:18:09.320 --> 00:18:11.380
tatsächlich jetzt, das hatten wir auch schon mal,

00:18:11.500 --> 00:18:13.160
da waren wir ein bisschen voreilig, irgendwie

00:18:13.160 --> 00:18:15.100
hatten wir ja schon 30 Jahre Python gefeiert,

00:18:15.200 --> 00:18:17.060
so der offizielle 30 Jahre

00:18:17.060 --> 00:18:19.460
Dings, das war irgendwann vorletzte Woche oder so was.

00:18:19.920 --> 00:18:21.000
Letzte? Ich weiß nicht mehr genau.

00:18:21.480 --> 00:18:22.840
Also tatsächlich. Da müssen wir jetzt ein Glas Sekt aufmachen.

00:18:22.920 --> 00:18:24.980
Ja, müsste man jetzt eigentlich. Ja, ist jetzt

00:18:24.980 --> 00:18:26.980
Python offiziell 30 Jahre draußen.

00:18:28.300 --> 00:18:28.620
Hurra.

00:18:29.420 --> 00:18:31.240
Dann ist es ja älter als ich.

00:18:31.460 --> 00:18:32.460
Ich wollte sagen, genau.

00:18:33.040 --> 00:18:36.640
Ich hatte mir mein Geld geklaut.

00:18:37.520 --> 00:18:38.420
Entschuldigung, Dominik.

00:18:39.080 --> 00:18:40.760
Dann ist es ja älter als Dominik und ich.

00:18:42.000 --> 00:18:43.480
Ja, es gibt noch ein zweites.

00:18:43.620 --> 00:18:45.060
Ich habe noch einen Versuch für den Witz.

00:18:45.440 --> 00:18:47.360
Es gibt ja noch ein zweites Jubiläum.

00:18:47.500 --> 00:18:49.580
Die Python Software Foundation ist 20 Jahre alt geworden.

00:18:50.720 --> 00:18:53.300
Und die ist dann ja älter als ich.

00:18:54.620 --> 00:18:55.500
Okay, verdammt.

00:18:55.960 --> 00:18:58.020
Das funktioniert nicht beliebig nach unten.

00:18:58.900 --> 00:19:01.240
Wir nehmen dir alle ab, dass du erst 19 bist, Jochen.

00:19:01.240 --> 00:19:08.080
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.

00:19:08.880 --> 00:19:11.500
Genau, so eine Tarnung.

00:19:12.300 --> 00:19:22.100
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.

00:19:22.160 --> 00:19:25.980
Das ist gut, dass du das so formuliert hast, weil sonst hätte ich jetzt direkt meinen Mathematiker auspacken müssen.

00:19:27.780 --> 00:19:29.440
Mit welcher Formierung habe ich mich gerettet?

00:19:30.580 --> 00:19:32.480
Die Zahl der gefeierten Geburtstage,

00:19:32.760 --> 00:19:34.380
das ist leider,

00:19:34.840 --> 00:19:36.620
ist meine Goldwaage, sagt ja.

00:19:40.380 --> 00:19:40.680
Ja.

00:19:40.840 --> 00:19:41.600
Tja, ja. Ja, gut.

00:19:42.160 --> 00:19:44.420
Genau, aber dann, ach so, doch, eine Geschichte

00:19:44.420 --> 00:19:46.400
habe ich noch. Genau, du hattest mir,

00:19:46.600 --> 00:19:47.880
Johannes, du hattest mir, glaube ich, mal

00:19:47.880 --> 00:19:49.600
so einen Link geschickt auf so einen Benchmark.

00:19:50.620 --> 00:19:51.100
Ja, oh.

00:19:52.860 --> 00:19:54.500
Da arbeiten wir jetzt auch schon eine Weile dran,

00:19:54.600 --> 00:19:55.320
Jochen. Ja.

00:19:56.420 --> 00:19:58.320
Und genau, da ging auch über

00:19:58.320 --> 00:20:00.420
Hacker-News und dann war es

00:20:00.420 --> 00:20:02.320
irgendwie, war der auch bei Python Bytes drin und so

00:20:02.320 --> 00:20:04.380
und da ging es darum, da hatte ja

00:20:04.380 --> 00:20:06.380
jemand irgendwie, weiß nicht genau, was da

00:20:06.380 --> 00:20:08.020
also da ging es halt um. Jemand hatte etwas

00:20:08.020 --> 00:20:09.860
gebenchmarked. Jemand hat irgendwas gebenchmarked, genau.

00:20:10.360 --> 00:20:11.980
Und das Einzige, was ich dazu im Grunde

00:20:11.980 --> 00:20:13.880
nur anmerken wollte, also

00:20:13.880 --> 00:20:15.840
also

00:20:15.840 --> 00:20:17.780
mit so einem

00:20:17.780 --> 00:20:19.140
Körnchen Salz

00:20:19.140 --> 00:20:21.940
sollte man da vielleicht schon

00:20:21.940 --> 00:20:23.380
mit dazu tun, sonst

00:20:23.380 --> 00:20:26.300
Also du sagst,

00:20:26.360 --> 00:20:27.500
man müsste das mal selber machen.

00:20:27.640 --> 00:20:30.000
Das ist das, was ich da raushöre.

00:20:30.000 --> 00:20:31.700
Genau, also ich meine, ich könnte das ja auch

00:20:31.700 --> 00:20:33.940
ich könnte das bestimmt fortsetzen, ne? Lügen,

00:20:34.060 --> 00:20:34.720
dreiste Lügen

00:20:34.720 --> 00:20:38.040
haben kurz, ne halt, warte

00:20:38.040 --> 00:20:42.240
Benchmark. Ne, aber ich glaube, das ist

00:20:42.240 --> 00:20:44.080
das ist mal eine eigene

00:20:44.080 --> 00:20:46.140
Episode, oder? Wenn wir mal über diesen Benchmark

00:20:46.140 --> 00:20:48.080
sprechen, den wir jetzt schon seit drei Monaten in der

00:20:48.080 --> 00:20:49.900
Mache haben. Achso, ja, ja.

00:20:49.920 --> 00:20:51.880
Der noch keine eindeutigen Ergebnisse gibt. Du meinst, wir wollen

00:20:51.880 --> 00:20:54.080
beweisen, dass Peißen die schnellste Sprache ist unter der Sonne?

00:20:55.040 --> 00:20:56.020
Ne, aber vielleicht schnell genug.

00:20:56.120 --> 00:20:57.580
Wir wollen beweisen, wie die schnellste,

00:20:57.760 --> 00:20:59.220
wie man damit schnell sein kann.

00:21:00.000 --> 00:21:03.900
Das ist ein Thema für eine eigene...

00:21:03.900 --> 00:21:04.840
Ich glaube, da brauchen wir wirklich...

00:21:04.840 --> 00:21:06.600
Da machen wir eine eigene Geschichte zu.

00:21:07.140 --> 00:21:09.460
Okay, ich wollte nur sagen, wenn man sich diesen Artikel

00:21:09.460 --> 00:21:11.800
anguckt, vielleicht nochmal...

00:21:11.800 --> 00:21:13.440
Also wenn man es wirklich wissen will, muss man es selber messen.

00:21:13.740 --> 00:21:15.720
Und ja, also es ist nicht

00:21:15.720 --> 00:21:17.720
so ganz einfach. Also zum Beispiel eben bei dem

00:21:17.720 --> 00:21:19.540
Artikel, dass man sich es dann so anguckt,

00:21:19.980 --> 00:21:20.760
wie wenn da so

00:21:20.760 --> 00:21:22.980
HTTP-Doodles oder

00:21:22.980 --> 00:21:25.680
bei Scenic ist das dann installiert, bei dem anderen nicht

00:21:25.680 --> 00:21:27.840
und HTTP-Parsing kann ja dann das Nadelöhr...

00:21:27.840 --> 00:21:28.860
Also ich will gar nicht

00:21:28.860 --> 00:21:30.800
gar nicht anfangen davon. Stimmt,

00:21:31.300 --> 00:21:33.040
da machen wir mal irgendwann, wenn wir Ergebnisse haben.

00:21:33.760 --> 00:21:35.040
Aber ja,

00:21:35.580 --> 00:21:36.680
Benchmark ist alles nicht so einfach.

00:21:37.200 --> 00:21:39.020
Man kann nur so viel verraten. Wir haben extra

00:21:39.020 --> 00:21:41.400
VMs bei einem Hoster gekauft,

00:21:41.800 --> 00:21:43.200
um genügend Bandbreite und alles

00:21:43.200 --> 00:21:45.140
zu haben und wir haben sie bisher nicht gebraucht.

00:21:47.960 --> 00:21:48.360
Ja.

00:21:52.560 --> 00:21:52.960
Gut.

00:21:52.960 --> 00:21:54.280
Ja, ist klar. Gut, dann

00:21:54.280 --> 00:21:55.640
Geschichte einander mal.

00:21:56.680 --> 00:21:58.660
Jetzt lacht ihr, Entschuldigung, jetzt müsst ihr mir das erzählen.

00:21:58.740 --> 00:22:00.520
bin ich sonst die ganze Zeit neugierig.

00:22:02.220 --> 00:22:02.740
Jochen hat

00:22:02.740 --> 00:22:04.700
einfach schon sehr viele Dinge ausprobiert und wir haben es

00:22:04.700 --> 00:22:06.920
bisher nicht geschafft, so viel

00:22:06.920 --> 00:22:08.680
Bandbreite zu verbrauchen, dass man mehr

00:22:08.680 --> 00:22:10.420
Bandbreite, also dass wir

00:22:10.420 --> 00:22:11.920
ein Netzwerk

00:22:11.920 --> 00:22:14.060
sinnvoll benutzen hätten können.

00:22:14.120 --> 00:22:16.660
Das war das mit dem Gigabit, was du nicht kriegst

00:22:16.660 --> 00:22:18.660
ausgelastet.

00:22:18.980 --> 00:22:20.620
Was war die erste Zahl,

00:22:20.700 --> 00:22:22.300
Jochen, die du hattest? Was war dein erstes Ergebnis?

00:22:22.540 --> 00:22:24.040
Wie viele Kilobit hast du?

00:22:24.620 --> 00:22:25.980
Schon ein paar

00:22:25.980 --> 00:22:27.780
Megabyte pro Sekunde, aber

00:22:27.780 --> 00:22:29.840
halt noch... Weit

00:22:29.840 --> 00:22:31.820
entfernt. Ja, ist noch nicht da, wo es hin

00:22:31.820 --> 00:22:33.620
muss. Ja, also es geht darum, dass

00:22:33.620 --> 00:22:35.840
halt die Konkurrenz von Python-Web

00:22:35.840 --> 00:22:37.680
Applikationen...

00:22:37.680 --> 00:22:39.840
Nee, also das Ziel dabei ist

00:22:39.840 --> 00:22:41.640
eigentlich rauszukriegen, braucht man sowas wie

00:22:41.640 --> 00:22:43.580
ein Nginx eigentlich noch davor oder kann man das nicht einfach

00:22:43.580 --> 00:22:45.860
alles jetzt wo in der schönen neuen Async-Welt

00:22:45.860 --> 00:22:47.460
so alle gut... Ich meine, das ist halt irgendwie so eine

00:22:47.460 --> 00:22:49.720
Tradition geworden, dass man da halt irgendwie

00:22:49.720 --> 00:22:51.700
fürs File-Serving irgendwie ein Nginx davor hat

00:22:51.700 --> 00:22:53.320
oder das halt über einen CDN macht.

00:22:54.260 --> 00:22:55.520
Ja, oder das halt irgendwie von

00:22:55.520 --> 00:22:57.560
Amazon machen lässt oder so. Das ist halt irgendwie so, dass

00:22:57.560 --> 00:22:59.700
das macht man halt so. Die Frage ist,

00:22:59.760 --> 00:23:01.380
gibt es dafür eigentlich jetzt noch so einen Grund,

00:23:01.560 --> 00:23:03.580
weil tatsächlich kann man ja mit Async

00:23:03.580 --> 00:23:05.500
und der ganzen Syntax und den ganzen schönen Dingen, die es jetzt

00:23:05.500 --> 00:23:07.440
alles gibt, also man könnte das ja eigentlich auch selber

00:23:07.440 --> 00:23:09.440
machen. Die Frage ist halt nur, ist das schnell genug? Ja, also wenn ich

00:23:09.440 --> 00:23:11.240
jetzt 100 Gigabit saturieren möchte,

00:23:11.540 --> 00:23:13.100
hm, okay, dann

00:23:13.100 --> 00:23:15.500
nehme ich vielleicht doch was anderes,

00:23:15.720 --> 00:23:17.280
aber wenn

00:23:17.280 --> 00:23:19.420
ich jetzt sowieso eine relativ, wenn ich jetzt

00:23:19.420 --> 00:23:21.400
sagen wir mal so, nur so ein Gigabit habe oder so an einem Server,

00:23:22.280 --> 00:23:23.500
dann kann es ja sein, dass es völlig

00:23:23.500 --> 00:23:25.480
egal ist, ob ich Nginx nehme oder irgendwie

00:23:25.480 --> 00:23:27.480
Python, weil es ist schnell genug und

00:23:27.480 --> 00:23:29.460
Gigabit ist ja heutzutage eigentlich gar nicht mehr so wahnsinnig

00:23:29.460 --> 00:23:30.740
viel. Vielleicht reicht es ja.

00:23:31.420 --> 00:23:33.280
Und das hört ihr weiter in unserer Webseite.

00:23:33.380 --> 00:23:35.360
Genau, dann haben wir das ein bisschen

00:23:35.360 --> 00:23:37.360
angeteasert, aber genau. In der Benchmark-Episode.

00:23:37.580 --> 00:23:37.660
Ja.

00:23:39.700 --> 00:23:41.020
Genau. Wir wollten übrigens noch so eine

00:23:41.020 --> 00:23:43.220
Datentypen-Folge machen. Die haben wir auch noch aufgeschoben.

00:23:43.340 --> 00:23:45.260
Nur für alle, die sich darüber freuen. Ja, eine Datentypen-Folge.

00:23:45.940 --> 00:23:46.120
Ja.

00:23:46.780 --> 00:23:47.300
Ja, okay.

00:23:48.880 --> 00:23:50.740
Ja, ist eine spannende Sache.

00:23:51.040 --> 00:23:51.900
Gibt's viele schöne Dinge.

00:23:52.680 --> 00:23:54.680
Ich hab noch was zum Thema Web-Server.

00:23:55.100 --> 00:23:57.120
Hab ich kürzlich gefunden. Fly.io.

00:23:57.480 --> 00:24:00.060
Habe es noch nicht selber ausprobiert, aber

00:24:00.060 --> 00:24:01.760
das scheint so ein bisschen wie das

00:24:01.760 --> 00:24:03.560
developerfreundliche

00:24:03.560 --> 00:24:05.480
Heroku zu sein.

00:24:06.760 --> 00:24:08.480
Mit einfachem

00:24:08.480 --> 00:24:09.260
Deployment überall.

00:24:11.520 --> 00:24:12.320
Wo man

00:24:12.320 --> 00:24:14.060
quasi einfach Docker-Container hinschickt

00:24:14.060 --> 00:24:16.300
und die lassen die dann laufen, wo man sie haben

00:24:16.300 --> 00:24:18.180
möchte. Und das sah sehr gut aus auf

00:24:18.180 --> 00:24:19.840
den ersten Blick und der hat auch sehr

00:24:19.840 --> 00:24:21.200
viele schöne technische Artikel

00:24:21.200 --> 00:24:24.160
geschrieben. Also es hat mir gut

00:24:24.160 --> 00:24:25.960
gefallen. Ich habe noch keine Gelegenheit gehabt,

00:24:26.020 --> 00:24:27.800
es auszuprobieren, aber ich werde, habe mir

00:24:27.800 --> 00:24:28.980
vorgenommen, es auszuprobieren.

00:24:29.980 --> 00:24:31.740
Ah, sehr cool, weil da gab es nämlich, das habe ich heute

00:24:31.740 --> 00:24:32.780
irgendwann gehört, glaube ich,

00:24:33.260 --> 00:24:35.880
auch eine neue Episode vom

00:24:35.880 --> 00:24:38.240
Django Chat Podcast, wo

00:24:38.240 --> 00:24:39.900
Peter Baumgartner von

00:24:39.900 --> 00:24:41.880
Lincoln Group, der auch dieses

00:24:41.880 --> 00:24:43.740
High-Performance-Django-Buch,

00:24:44.220 --> 00:24:45.480
der hat das, glaube ich, geschrieben

00:24:45.480 --> 00:24:47.840
und der hat auch so ein Ding

00:24:47.840 --> 00:24:49.840
gebaut. Auch so, ich meine, Heroku ist

00:24:49.840 --> 00:24:51.680
ja auch immer so die Empfehlung für, wenn man sich keine Gedanken

00:24:51.680 --> 00:24:53.820
machen möchte, aber Heroku ist

00:24:53.820 --> 00:24:55.760
halt auch... Und viel Geld hat. Und viel Geld hat, ist halt

00:24:55.760 --> 00:24:57.820
recht teuer. Und es ist halt auch so,

00:24:57.940 --> 00:24:59.560
dass deren, ja,

00:24:59.700 --> 00:25:01.660
es ist doch eher so Ruby-and-Rails-Ding und deren

00:25:01.660 --> 00:25:03.820
Django-Support erfährt jetzt nicht immer

00:25:03.820 --> 00:25:05.060
unbedingt die Liebe, die man jetzt

00:25:05.060 --> 00:25:07.480
sich erhoffen würde, vielleicht, von so einem Hoster.

00:25:08.500 --> 00:25:09.280
Um es mal so

00:25:09.280 --> 00:25:11.500
vorsichtig zu formulieren. Und

00:25:11.500 --> 00:25:13.600
der hat dann halt jetzt auch sowas gebaut, nämlich

00:25:13.600 --> 00:25:15.600
das nennt sich Up-Pack-IO

00:25:15.600 --> 00:25:17.440
und ist halt auch im Grunde sowas wie

00:25:17.440 --> 00:25:19.500
Heroku. Also sozusagen, du kannst dein Kram auf

00:25:19.500 --> 00:25:21.560
AWS hosten, nur halt

00:25:21.560 --> 00:25:23.500
mehr so auf Django optimiert und so.

00:25:24.080 --> 00:25:25.700
Aber cool, ja, ist schön zu sehen,

00:25:25.760 --> 00:25:26.520
dass es da mehr Optionen gibt.

00:25:26.760 --> 00:25:29.100
Es ist spannend, dass es so viele Firmen

00:25:29.100 --> 00:25:31.740
im indischen Ozean gibt. Das ist schon sehr cool.

00:25:33.980 --> 00:25:35.340
IO ist indischer Ozean.

00:25:35.680 --> 00:25:35.920
Achso.

00:25:39.580 --> 00:25:42.020
Ja, hat der

00:25:42.020 --> 00:25:43.860
indische Ozean ausnahmsweise

00:25:43.860 --> 00:25:45.480
mal was richtig gemacht mit der Wahl

00:25:45.480 --> 00:25:46.540
des Top-Level-Winners.

00:25:47.140 --> 00:25:48.060
Ja, Glück gehabt.

00:25:48.060 --> 00:25:48.880
Glück gehabt.

00:25:52.820 --> 00:25:54.080
Pack IO, sagst du.

00:25:54.140 --> 00:25:56.020
Jochen, du abtustenst den Link ja sicherlich.

00:25:56.140 --> 00:25:58.120
Genau, Up-Pack mit 3P.

00:25:59.000 --> 00:26:00.000
Das ist ein bisschen schlecht vielleicht,

00:26:00.080 --> 00:26:00.580
ich weiß nicht genau.

00:26:01.700 --> 00:26:03.740
Naja, aber genau, ich tue den Link in die Shownotes,

00:26:03.980 --> 00:26:04.720
kann man sich das angucken.

00:26:06.260 --> 00:26:08.020
Ja. Jetzt haben wir nur noch

00:26:08.020 --> 00:26:09.940
Reste übrig, oder? Ja, jetzt haben wir nur noch Reste übrig.

00:26:10.040 --> 00:26:12.080
Das ist nur noch der Rest. Da müssen wir jetzt über die Reste

00:26:12.080 --> 00:26:12.620
reden. Ja.

00:26:14.280 --> 00:26:16.280
Also, wo waren wir eben stehen geblieben,

00:26:16.400 --> 00:26:16.600
Johannes?

00:26:17.600 --> 00:26:20.180
Ja, als im Vergleich zu

00:26:20.180 --> 00:26:21.980
Remote Procedure Call.

00:26:22.780 --> 00:26:24.120
Weil, also ich meine, Remote Procedure

00:26:24.120 --> 00:26:35.980
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.

00:26:37.260 --> 00:26:48.420
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.

00:26:48.560 --> 00:26:54.120
Ja, das hatten wir auch. Sprich es ruhig aus, so wie es früher war. Soap zum Beispiel.

00:26:54.400 --> 00:27:07.800
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.

00:27:08.380 --> 00:27:33.480
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.

00:27:34.100 --> 00:27:50.520
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.

00:27:50.980 --> 00:28:10.500
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.

00:28:10.500 --> 00:28:11.780
und dann gab es Versionierung,

00:28:11.940 --> 00:28:14.020
wenn dann nicht die richtige Version

00:28:14.020 --> 00:28:14.960
von dieser API lief.

00:28:17.140 --> 00:28:18.920
Also es gibt ganz viele Stellen,

00:28:19.040 --> 00:28:20.060
an denen das einfach zerbricht.

00:28:20.480 --> 00:28:22.080
Soap ist prinzipiell eine sehr coole Idee,

00:28:22.540 --> 00:28:25.920
aber praktisch habe ich nie erlebt,

00:28:26.140 --> 00:28:28.660
dass es angenehm gewesen wäre

00:28:28.660 --> 00:28:29.560
oder zuverlässig.

00:28:32.380 --> 00:28:33.180
Und ich denke,

00:28:33.460 --> 00:28:34.800
also ich weiß es natürlich nicht,

00:28:34.920 --> 00:28:35.400
ich war nicht dabei,

00:28:35.520 --> 00:28:35.840
aber ich denke,

00:28:35.940 --> 00:28:36.960
dass das eben der Grund war,

00:28:36.960 --> 00:28:39.780
warum man zu REST-APIs

00:28:39.780 --> 00:28:41.460
ist oder eine der Gründe, warum man zu REST-APIs

00:28:41.460 --> 00:28:43.100
gegangen ist, wo es eben nicht darum geht,

00:28:44.060 --> 00:28:45.820
Prozeduren aufzurufen,

00:28:46.280 --> 00:28:47.360
also wo man nicht sagt, mach

00:28:47.360 --> 00:28:49.660
irgendwas, sondern wo man

00:28:49.660 --> 00:28:51.420
im Endeffekt nur sagt, entweder

00:28:51.420 --> 00:28:53.540
gib mir ein Objekt oder nimm dieses

00:28:53.540 --> 00:28:53.880
Objekt.

00:28:55.900 --> 00:28:57.660
Könnte man ja vielleicht auch so formulieren,

00:28:57.760 --> 00:28:59.080
dass man sagt, man versucht einfach die

00:28:59.080 --> 00:29:01.380
Dinge, die im HTTP-Protokoll eingebaut sind,

00:29:01.480 --> 00:29:03.220
auch tatsächlich zu benutzen, so wie sie halt

00:29:03.220 --> 00:29:05.520
schon da sind und nicht,

00:29:05.880 --> 00:29:07.500
weil das ist halt eigentlich, glaube ich, auch der

00:29:07.500 --> 00:29:09.480
Vorwurf sozusagen von REST-Seite, den man

00:29:09.480 --> 00:29:12.020
an so Sachen wie Soap oder auch

00:29:12.020 --> 00:29:14.100
Sachen, wo dann andere Leute versucht haben, Korba

00:29:14.100 --> 00:29:16.080
irgendwie zu retten in die neue

00:29:16.080 --> 00:29:17.920
Webwelt, macht, dass man sagt, ja,

00:29:17.980 --> 00:29:19.660
ihr habt hier so ein altes, überholtes

00:29:19.660 --> 00:29:22.020
Architekturmodell, von dem wie eure

00:29:22.020 --> 00:29:23.280
verteilte Anwendung funktionieren soll

00:29:23.280 --> 00:29:25.900
und jetzt versucht ihr das Web

00:29:25.900 --> 00:29:28.000
dazu zu degradieren, dass das nur ein Transport

00:29:28.000 --> 00:29:30.160
Layer ist für eure Idee, die

00:29:30.160 --> 00:29:32.060
auch schon vorher eigentlich nicht funktioniert

00:29:32.060 --> 00:29:33.760
hat. Also was heißt Korba

00:29:33.760 --> 00:29:34.620
in die Webwelt?

00:29:36.620 --> 00:29:38.120
Da gibt es eine schöne Organisation

00:29:38.120 --> 00:29:39.960
mit dem Kürzel OMG.

00:29:41.340 --> 00:29:42.000
Oh mein Gott.

00:29:42.360 --> 00:29:44.860
Common Object Request Broker

00:29:44.860 --> 00:29:46.400
Architecture. Ja, genau.

00:29:46.540 --> 00:29:47.960
Und die hat das standardisiert.

00:29:48.480 --> 00:29:49.840
Das ist die Object Management Group.

00:29:51.360 --> 00:29:52.500
Und genau.

00:29:52.680 --> 00:29:54.300
Ich hatte viel Spaß mit Cobra.

00:29:56.520 --> 00:29:57.080
Schon.

00:29:57.640 --> 00:29:58.560
Und ja,

00:29:58.560 --> 00:29:59.100
das war

00:29:59.100 --> 00:30:01.960
auch alles nicht schön.

00:30:03.320 --> 00:30:04.380
Das klang

00:30:04.380 --> 00:30:05.320
alles nach einer guten Idee.

00:30:06.220 --> 00:30:06.840
Und da hat man es versucht,

00:30:07.420 --> 00:30:09.340
zu verwenden und dann

00:30:09.340 --> 00:30:11.000
sind schreckliche Dinge passiert.

00:30:11.640 --> 00:30:13.140
Ich meine, vielleicht haben Leute das auch verwendet

00:30:13.140 --> 00:30:14.300
und es war voll cool, aber

00:30:14.300 --> 00:30:16.500
ich erinnere mich an große Schmerzen.

00:30:18.040 --> 00:30:18.980
Ja, okay. Und in

00:30:18.980 --> 00:30:21.180
HTTP selbst ist dann sowas eingebaut

00:30:21.180 --> 00:30:23.240
wie, gib mir ein Objekt

00:30:23.240 --> 00:30:25.340
oder bekomme ein Objekt.

00:30:26.180 --> 00:30:27.280
Genau, HTTP selbst

00:30:27.280 --> 00:30:28.940
hat ja erstmal

00:30:28.940 --> 00:30:31.080
nicht so viele verschiedene Dinge, die es

00:30:31.080 --> 00:30:33.020
garantiert, aber es garantiert

00:30:33.020 --> 00:30:35.260
im Wesentlichen einen Pfad

00:30:35.260 --> 00:30:36.920
und ein Verb. Und diese Verben

00:30:36.920 --> 00:30:38.580
sind sehr

00:30:38.580 --> 00:30:40.740
streng limitiert. Also prinzipiell kann man da jedes

00:30:40.740 --> 00:30:42.760
Verb mitschicken, aber der Standard hat nur

00:30:42.760 --> 00:30:44.860
so eine Handvoll. Und da gibt es insbesondere

00:30:44.860 --> 00:30:46.760
Get und Post und Get heißt halt

00:30:46.760 --> 00:30:48.640
gib mir und Post heißt

00:30:48.640 --> 00:30:49.160
nimm das.

00:30:51.320 --> 00:30:52.740
Es gibt noch

00:30:52.740 --> 00:30:54.680
ein, zwei andere, die da wichtig sind. Es gibt noch

00:30:54.680 --> 00:30:56.780
Put und Delete, die immer wieder

00:30:56.780 --> 00:30:58.920
notwendig sind.

00:31:00.060 --> 00:31:00.520
Ja, aber

00:31:00.520 --> 00:31:02.660
gerade da fängt es dann schon so an. Was ist eigentlich der

00:31:02.660 --> 00:31:04.160
Unterschied zwischen Put, Post und Patch?

00:31:04.620 --> 00:31:06.840
Ich weiß es nicht. Ich würde sagen, spontan

00:31:06.840 --> 00:31:08.960
wäre es so, Put, da updatest

00:31:08.960 --> 00:31:09.960
du ein komplettes Objekt

00:31:09.960 --> 00:31:12.800
und Patch nur ein Teil davon. Also wenn du

00:31:12.800 --> 00:31:14.700
sozusagen nur ein Attribut an einem Objekt änderst,

00:31:14.780 --> 00:31:16.960
dann machst du das per Patch. Wenn das Objekt

00:31:16.960 --> 00:31:19.100
eine Version

00:31:19.100 --> 00:31:20.620
änderst, dann puttest du das komplett.

00:31:20.880 --> 00:31:23.140
Und Post? Post ist hinzufügen.

00:31:24.880 --> 00:31:26.640
Ja, aber das ist ja auch nicht so. Das ist ja bei REST

00:31:26.640 --> 00:31:28.600
auch nochmal anders geregelt. Das ist ja, wenn du auf eine

00:31:28.600 --> 00:31:30.780
ID postest, puttest, dann

00:31:30.780 --> 00:31:32.920
ist es ein neues Objekt

00:31:32.920 --> 00:31:34.680
mit dieser, wenn es die noch nicht gibt, dann ist es

00:31:34.680 --> 00:31:36.020
ein neues und wenn du auf eine

00:31:36.020 --> 00:31:37.780
Ja, so ganz klar ist es.

00:31:38.320 --> 00:31:40.100
Okay, ja, ehrlich

00:31:40.100 --> 00:31:41.940
gesagt, weiß ich auch nicht genau. Also braucht man nur noch zwei.

00:31:42.860 --> 00:31:44.020
Get und Post. Ja, das

00:31:44.020 --> 00:31:46.020
ist halt das, was viele Leute machen. Mit denen kommt man zurecht.

00:31:46.140 --> 00:31:47.900
Mit denen kommt man schon zurecht, aber das ist

00:31:47.900 --> 00:31:49.960
natürlich. Delete brauchst du noch, Dominik.

00:31:50.040 --> 00:31:51.100
Delete brauchst du auf jeden Fall. Na gut.

00:31:51.740 --> 00:31:54.020
Man kann nicht posten und sagen, das Objekt bitte entfernen.

00:31:55.140 --> 00:31:55.740
Du kannst,

00:31:56.060 --> 00:31:57.800
nee, weil du kannst

00:31:57.800 --> 00:31:59.040
auch, du kannst posten,

00:31:59.840 --> 00:32:01.740
das kommt jetzt drauf an. Und

00:32:01.740 --> 00:32:04.020
da fangen schon so ein bisschen die Probleme bei

00:32:04.020 --> 00:32:05.800
REST an. REST ist, besteht

00:32:05.800 --> 00:32:07.760
ja aus mehreren Teilen und ein Teil ist

00:32:07.760 --> 00:32:10.160
eben, benutze nur diese HTTP-Werben.

00:32:10.960 --> 00:32:11.140
Und

00:32:11.140 --> 00:32:13.880
da fängt eben

00:32:13.880 --> 00:32:15.300
das, eins der Probleme schon an,

00:32:15.980 --> 00:32:17.620
eine der Konventionen ist,

00:32:17.740 --> 00:32:18.780
wenn du auf

00:32:18.780 --> 00:32:21.740
den Pfad eines Objektes postest

00:32:21.740 --> 00:32:23.580
und nur eine gewisse

00:32:23.580 --> 00:32:25.820
Menge von Attributen mitgibst,

00:32:25.880 --> 00:32:28.000
dann heißt es, ändere bitte diese Attribute.

00:32:30.460 --> 00:32:31.700
Wenn du jetzt sagen würdest,

00:32:31.700 --> 00:32:33.560
wenn ich darauf poste, ohne ein Attribut

00:32:33.560 --> 00:32:35.500
zu geben, dann kann das, hat es schon zwei

00:32:35.500 --> 00:32:37.680
Bedeutung. Hat es entweder die Bedeutung, die du jetzt sagst,

00:32:37.740 --> 00:32:39.080
nämlich lösche dieses Objekt,

00:32:39.580 --> 00:32:41.000
also entferne alle Attribute,

00:32:41.500 --> 00:32:42.700
oder es hat die Bedeutung,

00:32:44.260 --> 00:32:45.360
ändere kein Attribut.

00:32:47.520 --> 00:32:47.680
Und

00:32:47.680 --> 00:32:49.580
weil das

00:32:49.580 --> 00:32:51.440
nicht offensichtlich ist, ist es einfacher,

00:32:51.540 --> 00:32:53.640
Delete zu nehmen. Delete ist eindeutig

00:32:53.640 --> 00:32:55.460
und Delete ist auch, Delete ist

00:32:55.460 --> 00:32:57.200
eine von den Sachen bei REST, die völlig unstrittig sind.

00:32:57.560 --> 00:32:59.500
Wenn ich eine URL habe, wenn ich einen Pfad

00:32:59.500 --> 00:33:01.480
habe, der zu einem Objekt gehört und ich mache da Delete

00:33:01.480 --> 00:33:03.480
drauf und ich darf das und

00:33:03.480 --> 00:33:05.440
da kommt der richtige Status zurück, dann ist es

00:33:05.440 --> 00:33:07.580
gelöscht. Das ist völlig unstrittig

00:33:07.580 --> 00:33:08.880
und das ist auch eine super Sache,

00:33:09.440 --> 00:33:10.840
weil ab jetzt brauche ich mir ums Löschen

00:33:10.840 --> 00:33:12.700
von Adre, von Adrecken keine

00:33:12.700 --> 00:33:14.720
Sorgen mehr machen. Das ist

00:33:14.720 --> 00:33:16.320
jetzt geregelt. Das geht immer.

00:33:19.220 --> 00:33:20.820
Was dafür sprechen würde, dass man Post

00:33:20.820 --> 00:33:22.920
nicht löscht? Nein, eigentlich

00:33:22.920 --> 00:33:24.660
nicht. Genau, mit Post löscht du nie. Post ist

00:33:24.660 --> 00:33:26.640
immer nur, Post und Put und Patch

00:33:26.640 --> 00:33:27.740
sind immer nur Additiv.

00:33:30.460 --> 00:33:32.680
Okay, also, aber okay, den Unterschied da genau

00:33:32.680 --> 00:33:34.580
zu verwenden ist wahrscheinlich, wie man gerade schon

00:33:34.580 --> 00:33:36.200
rausgehört hat, eher

00:33:36.200 --> 00:33:38.660
vielleicht gar nicht so. Ja, man findet

00:33:38.660 --> 00:33:40.480
auch ganz viel tatsächlich

00:33:40.480 --> 00:33:42.440
in freier Wildbahn dann halt Leute, die

00:33:42.440 --> 00:33:44.580
irgendwie das halt

00:33:44.580 --> 00:33:46.500
anders machen, als man das vielleicht tun sollte.

00:33:47.300 --> 00:33:48.720
Ja, und wir werden sicherlich

00:33:48.720 --> 00:33:50.500
auch hier ganz viele Kommentare kriegen,

00:33:50.680 --> 00:33:52.600
dass wir alle Idioten sind und dass es nur eine

00:33:52.600 --> 00:33:53.420
wahre Lösung gibt.

00:33:55.800 --> 00:33:56.480
Ja, da kommt

00:33:56.480 --> 00:33:57.600
ein Response zurück, 4.02.

00:34:00.320 --> 00:34:02.100
Nee, 2.01 kommt dann zurück.

00:34:03.440 --> 00:34:04.320
2.01 heißt,

00:34:04.440 --> 00:34:05.600
Objekt erzeugt.

00:34:05.980 --> 00:34:07.780
Ja, und ich meine, ich sehe immer,

00:34:08.220 --> 00:34:10.180
wenn ich irgendwie, also es gibt, wenn ich mit

00:34:10.180 --> 00:34:12.000
anderen APIs rede, ist es ganz oft, dass ich irgendwie

00:34:12.000 --> 00:34:13.860
was erzeuge und dann kommt halt 200 zurück zum Beispiel.

00:34:14.200 --> 00:34:16.060
Was halt falsch ist oder...

00:34:16.060 --> 00:34:17.000
Ja, aber kann auch sein.

00:34:17.000 --> 00:34:18.680
Kann auch sein.

00:34:19.540 --> 00:34:20.660
Ja, kann auch sein.

00:34:21.540 --> 00:34:23.240
Weil 200 bedeutet ja nur

00:34:23.240 --> 00:34:25.240
okay. 200 bedeutet

00:34:25.240 --> 00:34:26.660
ja nur in Ordnung. Und

00:34:26.660 --> 00:34:29.100
es kann ja tatsächlich sein, und ich halte das

00:34:29.100 --> 00:34:31.060
tatsächlich für sinnvoll, 200 zurückzugeben

00:34:31.060 --> 00:34:32.400
in vielen Fällen und nicht 201,

00:34:33.220 --> 00:34:45.600
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.

00:34:46.220 --> 00:34:55.520
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.

00:34:55.800 --> 00:34:57.280
Ja, aber nicht Berechtigung, sondern wieder was anderes.

00:34:57.740 --> 00:34:58.000
Ah gut.

00:34:58.000 --> 00:35:06.160
Ja, okay, weil sie halt verworfen wurden. Und dann ist es absolut richtig, meiner Meinung nach, mit 200 das erzeugte Objekt zurückzugeben.

00:35:10.080 --> 00:35:14.140
Tja, das kommt ja normalerweise auch beim 201, kommt ja auch das erzeugte Objekt zurück.

00:35:14.140 --> 00:35:15.580
Nee, 201 hat keinen Inhalt.

00:35:15.900 --> 00:35:16.140
Nein?

00:35:17.000 --> 00:35:19.620
Nee, 201 hat normalerweise, sollte keinen Inhalt haben.

00:35:21.360 --> 00:35:25.040
Okay, okay, okay, gut, ja, also es ist, okay, ja.

00:35:28.000 --> 00:35:30.140
ja. Auch das ist so ein Problem,

00:35:30.420 --> 00:35:32.220
auch das ist so ein Problem, wenn man auf 201

00:35:32.220 --> 00:35:34.160
wartet und erwartet, dass das Subjekt

00:35:34.160 --> 00:35:34.800
zurückgegeben wird,

00:35:36.180 --> 00:35:38.060
dann kommt ganz oft

00:35:38.060 --> 00:35:39.880
gar nichts zurück und dann schlägt diese,

00:35:40.000 --> 00:35:41.880
schlägt quasi diese Abfrage fehl, weil du, weil

00:35:41.880 --> 00:35:43.200
kein Content kommt.

00:35:46.120 --> 00:35:47.820
Ach je. Auch das, auch damit

00:35:47.820 --> 00:35:49.440
habe ich mich schon abgeplagt.

00:35:49.640 --> 00:35:49.980
Ja, ja.

00:35:51.520 --> 00:35:54.040
Na gut. Ich verplage mich immer mit dem 402

00:35:54.040 --> 00:35:54.320
ab.

00:35:56.040 --> 00:35:57.900
Was war das nochmal? Kein Geld bezahlt?

00:35:58.800 --> 00:35:59.560
Payment required.

00:35:59.700 --> 00:36:00.460
Payment required, ja.

00:36:01.680 --> 00:36:02.560
Reserved for future use.

00:36:02.560 --> 00:36:04.300
Nee, der wichtigste ist doch 418.

00:36:04.780 --> 00:36:06.140
Ja, T-Pod war das, oder?

00:36:06.480 --> 00:36:07.300
Armer T-Pod, ja.

00:36:10.360 --> 00:36:10.940
Ja, genau.

00:36:11.120 --> 00:36:12.400
Also ich meine, tatsächlich in der Praxis

00:36:12.400 --> 00:36:14.560
funktioniert es meistens ja eigentlich ganz gut.

00:36:14.960 --> 00:36:16.600
Man kann sich da irgendwie durchwurschteln

00:36:16.600 --> 00:36:17.580
und dann geht es schon.

00:36:20.200 --> 00:36:21.480
Und genau.

00:36:22.760 --> 00:36:23.620
Tatsächlich ist aber auch,

00:36:23.700 --> 00:36:24.340
da gibt es ja so,

00:36:24.980 --> 00:36:26.260
und dann, wie nennt sich das dann immer,

00:36:27.500 --> 00:36:28.640
Maturity-Level

00:36:28.640 --> 00:36:30.240
irgendwie, Rest, also

00:36:30.240 --> 00:36:32.520
hinter diesem ganzen Kram ist ja

00:36:32.520 --> 00:36:34.460
so ein Konzept, irgendwie

00:36:34.460 --> 00:36:36.080
einer der Leute, die halt

00:36:36.080 --> 00:36:37.760
ja auch so

00:36:37.760 --> 00:36:40.300
eine der Hauptverantwortlichen

00:36:40.300 --> 00:36:41.700
hinter dem Web hat,

00:36:41.920 --> 00:36:44.600
steckt halt auch hinter dieser Rest-

00:36:44.600 --> 00:36:46.160
Idee, ne, Roy Fielding,

00:36:46.280 --> 00:36:48.480
hat da seine Dissertation drüber geschrieben,

00:36:48.640 --> 00:36:50.120
ja genau, 2005 ist sie glaube ich erschienen,

00:36:51.160 --> 00:36:52.600
und da

00:36:52.600 --> 00:36:54.520
genau, kann man

00:36:54.520 --> 00:36:56.140
sich angucken, gibt es online, auch als Webseite.

00:36:56.500 --> 00:36:56.820
Sehr schön.

00:36:59.060 --> 00:36:59.840
Oh, auch sehr interessant.

00:37:00.040 --> 00:37:01.980
Link, please. Ja, genau, Link kommt in die

00:37:01.980 --> 00:37:03.120
Show Notes. Auch sehr interessant,

00:37:03.800 --> 00:37:05.980
die Dissertation fängt an

00:37:05.980 --> 00:37:08.300
und endet jeweils mit einem Zitat

00:37:08.300 --> 00:37:09.900
von, na, wie heißt er noch?

00:37:10.500 --> 00:37:11.680
Der Architekt mit den

00:37:11.680 --> 00:37:13.020
Entwurfsmustern.

00:37:15.720 --> 00:37:16.880
Mit den Entwurfsmustern.

00:37:16.880 --> 00:37:18.800
Der mit diesen Patterns

00:37:18.800 --> 00:37:19.680
angefangen hat, genau.

00:37:20.660 --> 00:37:21.920
Christopher Alexander, glaube ich.

00:37:24.180 --> 00:37:52.340
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?

00:37:52.980 --> 00:38:06.140
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.

00:38:08.180 --> 00:38:10.360
Wenn man das wirklich genau wissen will, sollte man sich nochmal diese

00:38:10.360 --> 00:38:12.760
also tatsächlich finde ich das beste

00:38:12.760 --> 00:38:14.580
Beispiel dafür, wie das funktionieren kann, ist halt

00:38:14.580 --> 00:38:16.380
das Web. Dass man sagt, also

00:38:16.380 --> 00:38:18.700
da ist das Hypermedia, was man halt

00:38:18.700 --> 00:38:20.220
sieht, ist das HTML

00:38:20.220 --> 00:38:22.120
und

00:38:22.120 --> 00:38:24.640
du kannst da halt dann Links folgen

00:38:24.640 --> 00:38:26.980
und

00:38:26.980 --> 00:38:28.960
siehst dann halt neue Sachen, neue Webseiten

00:38:28.960 --> 00:38:30.680
und so und kannst dann Dinge

00:38:30.680 --> 00:38:32.480
machen und sozusagen

00:38:32.480 --> 00:38:35.020
wie deine Applikation, also deine Webseite

00:38:35.020 --> 00:38:36.880
aussieht, bestimmt das Hypermedia

00:38:36.880 --> 00:38:37.280
da drin.

00:38:38.180 --> 00:39:01.700
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.

00:39:02.200 --> 00:39:04.180
Insofern, ich bin mal gespannt, wie es ausgeht.

00:39:04.340 --> 00:39:06.120
Es kann ja auch sein, dass sich das dann durchsetzt.

00:39:06.720 --> 00:39:10.000
Aber tatsächlich, also ich finde einen wichtigen Punkt,

00:39:10.180 --> 00:39:12.560
so bei dem, diese Single-Page-App ist eigentlich voll cool und so.

00:39:12.620 --> 00:39:14.620
Man kann damit tatsächlich ja Applikationen bauen,

00:39:14.740 --> 00:39:17.400
die so ein bisschen wirken, als wären sie Desktop-Applikationen,

00:39:17.420 --> 00:39:18.100
so wie früher.

00:39:20.040 --> 00:39:22.580
Aber wenn man sich jetzt vorstellt, man will ein Web draus bauen

00:39:22.580 --> 00:39:24.840
und jetzt hinter jedem Link liegt so eine Single-Page-App,

00:39:24.900 --> 00:39:26.540
wo erstmal ein paar MB Zeug kommen,

00:39:28.300 --> 00:39:30.620
dann ist das ja eigentlich gar nicht so gut.

00:39:31.840 --> 00:39:34.160
Also Stau, Stau, Stau

00:39:34.160 --> 00:39:35.860
auf der Datenautobahn. Das macht das

00:39:35.860 --> 00:39:37.940
Web halt irgendwie kaputt. Das macht es halt

00:39:37.940 --> 00:39:40.080
nicht so, also so eine

00:39:40.080 --> 00:39:41.980
Single-Page, ja ich meine Single-Page ist eigentlich

00:39:41.980 --> 00:39:43.400
auch ein falter Name, aber so diese

00:39:43.400 --> 00:39:45.740
JavaScript-Applikationen, die halt nur

00:39:45.740 --> 00:39:47.640
RPC quasi zu einem Server machen,

00:39:48.720 --> 00:39:49.980
die sind halt eine in sich

00:39:49.980 --> 00:39:51.700
abgeschlossene Applikation. Und wenn man da,

00:39:51.900 --> 00:39:53.940
wenn alle Webseiten nur noch so etwas wäre,

00:39:54.220 --> 00:39:56.200
dann würden Links... Also wenn man nicht sehr viel Arbeit

00:39:56.200 --> 00:39:56.920
macht, meinst du.

00:39:58.060 --> 00:39:59.960
Weil gute SPAs haben

00:39:59.960 --> 00:40:04.300
natürlich den internen Zustand,

00:40:04.300 --> 00:40:06.180
wo du auch Deep Links machen kannst auf SPAs.

00:40:06.440 --> 00:40:09.320
Aber das ist nicht so gängig, um es mal so zu sagen.

00:40:09.320 --> 00:40:10.580
Ja, aber was ist jetzt ein Deep Link wieder?

00:40:11.840 --> 00:40:13.880
Ja, wenn du so eine SPA aufrufst,

00:40:13.940 --> 00:40:15.660
dann bist du ja jetzt nochmal auf, keine Ahnung,

00:40:15.760 --> 00:40:16.740
spa.io, ja?

00:40:17.780 --> 00:40:21.400
Und dann gehst du da in deine Daten rein

00:40:21.400 --> 00:40:22.620
und in die Tabelle

00:40:22.620 --> 00:40:25.180
und dann gehst du da in Zelle A17.

00:40:26.180 --> 00:40:28.020
Und ein Deep Link wäre,

00:40:28.140 --> 00:40:29.780
wenn es eine Möglichkeit gäbe,

00:40:29.860 --> 00:40:31.740
eine URL anzugeben, die auf diese

00:40:31.740 --> 00:40:33.580
Zelle verweist, damit du deinem Kollegen

00:40:33.580 --> 00:40:35.700
sagen kannst, hier, schau dir mal diese Zelle

00:40:35.700 --> 00:40:37.640
an. Und

00:40:37.640 --> 00:40:39.680
ganz viele SPAs machen das aber nicht. Du kannst

00:40:39.680 --> 00:40:40.900
nicht sozusagen

00:40:40.900 --> 00:40:43.620
dahin navigieren und dann aus

00:40:43.620 --> 00:40:45.420
der Adresszeile den Link rauskopieren.

00:40:46.680 --> 00:40:47.640
Weil die eben,

00:40:47.840 --> 00:40:49.640
weil du immer noch bei spa.io bist

00:40:49.640 --> 00:40:51.540
und sonst nirgends, weil der Zustand, den du

00:40:51.540 --> 00:40:53.140
erreicht hast, nur innerhalb der

00:40:53.140 --> 00:40:55.800
Anwendung ist und nicht in eben

00:40:55.800 --> 00:40:57.680
diesem Hypertext. Das heißt,

00:40:57.740 --> 00:40:59.660
du kannst da nicht drauf verlinken. Und das ist

00:40:59.660 --> 00:41:01.260
genau das, was sozusagen

00:41:01.260 --> 00:41:03.600
das Problem an dieser Stelle ist. Du kannst

00:41:03.600 --> 00:41:05.400
nicht darauf verlinken. Du kannst nicht sagen,

00:41:06.280 --> 00:41:07.660
das hier und jeder, der

00:41:07.660 --> 00:41:09.600
es abruft, sieht es dann, wenn er

00:41:09.600 --> 00:41:11.500
es sehen darf. Immer Modulo

00:41:11.500 --> 00:41:13.880
dieser Berechtigungen

00:41:13.880 --> 00:41:15.160
und der Sichtbarkeit und so weiter.

00:41:16.020 --> 00:41:17.480
Und das ist ja aber eigentlich eine Sache,

00:41:17.680 --> 00:41:19.340
die in REST APIs

00:41:19.340 --> 00:41:21.460
schon so drin sein sollte, dass du zum

00:41:21.460 --> 00:41:23.620
einen Links machen kannst

00:41:23.620 --> 00:41:24.440
auf Objekte.

00:41:25.640 --> 00:41:26.460
Also API

00:41:26.460 --> 00:41:28.880
Slash Spreadsheet

00:41:28.880 --> 00:41:30.080
Slash

00:41:30.080 --> 00:41:32.660
Spreadsheet ID Slash Table

00:41:32.660 --> 00:41:33.880
Slash

00:41:33.880 --> 00:41:36.980
Slash Row 17

00:41:36.980 --> 00:41:37.600
Irgendwie sowas, ja?

00:41:38.220 --> 00:41:40.280
Solltest du prinzipiell machen können und auch

00:41:40.280 --> 00:41:42.720
innerhalb dieser API solltest du eigentlich

00:41:42.720 --> 00:41:43.300
nie

00:41:43.300 --> 00:41:46.080
irgendwie nur IDs angeben, ja?

00:41:46.080 --> 00:41:48.020
Das ist jetzt dann hier, da ist

00:41:48.020 --> 00:41:50.020
der Inhalt 23 drin,

00:41:50.720 --> 00:41:51.960
sondern eigentlich solltest du angeben,

00:41:52.020 --> 00:41:53.980
da ist der Inhalt drin, der

00:41:53.980 --> 00:41:55.480
unter folgender URL erreichbar ist.

00:41:56.460 --> 00:41:58.840
und wenn man das sauber macht,

00:41:58.940 --> 00:42:00.900
dann ist das eine ganz, ganz mächtige Sache. Ich versuche

00:42:00.900 --> 00:42:02.440
das bei meinen APIs immer zu machen,

00:42:03.020 --> 00:42:04.860
weil das die Entwicklung mit der API

00:42:04.860 --> 00:42:06.620
wesentlich vereinfacht, weil ich eben nicht

00:42:06.620 --> 00:42:08.860
wissen muss, was das bedeutet,

00:42:08.940 --> 00:42:10.300
wenn da drin steht ID 17,

00:42:11.600 --> 00:42:12.800
sondern ich muss

00:42:12.800 --> 00:42:14.620
nur einen Link aufrufen können und einen Link aufrufen,

00:42:14.740 --> 00:42:16.680
das geht. Das geht, genau. Dann kriegst du das Objekt

00:42:16.680 --> 00:42:18.280
und weißt, was da drin ist. Genau.

00:42:18.540 --> 00:42:19.620
Und dann kannst du auch weitergucken.

00:42:20.080 --> 00:42:22.620
Ja, aber tatsächlich

00:42:22.620 --> 00:42:24.500
eben, genau. Und das ist halt so der Unterschied, wenn man

00:42:24.500 --> 00:42:26.520
jetzt RPC machen würde oder so, wenn du jetzt

00:42:26.520 --> 00:42:28.440
da irgendein Objekt kriegst mit bestimmten Parametern

00:42:28.440 --> 00:42:29.940
oder so, kannst du halt auch nicht drauf verlinken.

00:42:31.260 --> 00:42:32.440
Das ist schon, genau,

00:42:32.540 --> 00:42:34.520
das ist halt irgendwie so eine der wesentlichen Geschichten,

00:42:34.620 --> 00:42:36.180
wobei man halt auch sagen muss, also die Idee ist

00:42:36.180 --> 00:42:38.180
nett und das Web

00:42:38.180 --> 00:42:40.360
funktioniert ja auch so, aber tatsächlich

00:42:40.360 --> 00:42:42.180
alle anderen Beispiele, die ich

00:42:42.180 --> 00:42:44.360
gehört habe oder die versuchen Leute dann zu konstruieren

00:42:44.360 --> 00:42:46.080
für, wo das noch eine gute Idee wäre,

00:42:46.760 --> 00:42:47.820
die sind alle ziemlich konstruiert.

00:42:48.340 --> 00:42:50.220
Also in diesem Webfall hat es einmal

00:42:50.220 --> 00:42:52.520
geklappt, aber ansonsten

00:42:52.520 --> 00:42:54.480
also irgendwelche Applikationen,

00:42:54.500 --> 00:42:56.640
die ihr UI dadurch aufbauen,

00:42:56.780 --> 00:42:57.700
dass sie irgendwie

00:42:57.700 --> 00:43:00.580
aus einer API irgendwie ihre Formulare

00:43:00.580 --> 00:43:02.420
bekommen und das, wo sie, wo sie

00:43:02.420 --> 00:43:04.460
Ja, das hört sich ja grauenhaft an.

00:43:04.540 --> 00:43:06.480
Genau, das hört sich schon ziemlich grauenhaft an,

00:43:06.560 --> 00:43:07.880
ja, das klingt so ein bisschen nach SAP,

00:43:08.280 --> 00:43:10.420
irgendwie alle Sachen sehen irgendwie gleich aus und so.

00:43:10.900 --> 00:43:11.520
Ja. Also.

00:43:12.080 --> 00:43:14.120
Alles zur Laufzeit wird das zusammengebaut.

00:43:14.340 --> 00:43:16.180
Ja, also ich meine, es wäre natürlich schön, also

00:43:16.180 --> 00:43:18.420
der Vorteil, den du halt hast, wenn du das so machst, ist halt,

00:43:18.420 --> 00:43:20.520
dass auch ältere Browser funktionieren können.

00:43:20.680 --> 00:43:22.160
Du musst halt nicht immer irgendwie

00:43:22.160 --> 00:43:24.320
den Client austauschen und gerade

00:43:24.320 --> 00:43:26.200
wenn du jetzt App-Stores hast oder so, wäre es natürlich

00:43:26.200 --> 00:43:28.500
auch nett, wenn Leute mit alten

00:43:28.500 --> 00:43:30.600
Client-Anwendungen

00:43:30.600 --> 00:43:31.920
halt auch deine neue

00:43:31.920 --> 00:43:34.220
Geschichten benutzen können und du sozusagen

00:43:34.220 --> 00:43:36.020
so ein bisschen Progressive Enhancement machst

00:43:36.020 --> 00:43:38.140
und die neuen Geräte können dann halt

00:43:38.140 --> 00:43:40.120
den neuen Kram machen und die alten sehen aber immer noch

00:43:40.120 --> 00:43:41.240
die alte Seite sozusagen.

00:43:42.120 --> 00:43:44.100
Tatsächlich glaube ich aber, dass das praktisch niemand so

00:43:44.100 --> 00:43:44.480
macht.

00:43:46.400 --> 00:43:48.180
Das ist auch ungeheuer schwierig,

00:43:48.320 --> 00:43:49.660
das zu machen, weil die

00:43:49.660 --> 00:43:51.340
Interna verändern sich ja auch.

00:43:51.420 --> 00:43:52.100
Also ich meine,

00:43:52.480 --> 00:43:54.680
wir können auch gerne mal noch ein

00:43:54.680 --> 00:43:56.580
Stündchen über API-Versionierung sprechen,

00:43:56.700 --> 00:43:58.480
weil auch da hat nämlich jeder von uns

00:43:58.480 --> 00:43:59.940
eine Meinung dazu.

00:44:02.360 --> 00:44:04.400
Und ich weiß auch mindestens drei

00:44:04.400 --> 00:44:05.940
verschiedene Wege, wie man das machen kann.

00:44:07.600 --> 00:44:08.120
Aber

00:44:08.120 --> 00:44:11.360
ja, das

00:44:11.360 --> 00:44:14.540
ich kenne quasi keinen Fall, wo

00:44:14.540 --> 00:44:16.580
es sich lohnen würde, verschiedene API-Versionen

00:44:16.580 --> 00:44:18.480
gleichzeitig laufen zu haben, was

00:44:18.480 --> 00:44:19.700
ja sehr teuer ist erst mal.

00:44:21.260 --> 00:44:21.380
Ja.

00:44:23.260 --> 00:44:24.380
Und deshalb, das mag

00:44:24.380 --> 00:44:26.460
ein heroisches Ideal sein, aber es ist

00:44:26.460 --> 00:44:28.200
vielleicht schwierig, das in der echten Welt zu machen.

00:44:28.200 --> 00:44:30.620
Du müsstest nicht unbedingt

00:44:30.620 --> 00:44:32.560
unterschiedliche API-Versionen, sondern du würdest es halt

00:44:32.560 --> 00:44:34.460
so machen wie bei HTML auch. Du würdest halt sagen,

00:44:34.580 --> 00:44:36.520
okay, hier ist halt ein Attribut und da steht

00:44:36.520 --> 00:44:38.480
halt an dem Attribut noch dran, weil wenn du das

00:44:38.480 --> 00:44:40.300
in JSON machst, nicht in HTML, so

00:44:40.300 --> 00:44:42.380
ab hier nur für Clients mit der Version

00:44:42.380 --> 00:44:44.380
oder so, keine Ahnung, die anderen müssen hier gar nicht gucken,

00:44:44.460 --> 00:44:44.940
die können das nicht.

00:44:46.780 --> 00:44:48.180
Ja, okay, aber dann hast du ja unterschiedliche

00:44:48.180 --> 00:44:49.660
API-Versionen, die halt additiv sind.

00:44:50.320 --> 00:44:52.260
Ja, aber du würdest auch dem alten Client das

00:44:52.260 --> 00:44:54.340
neue ausliefern und der wird das dann einfach ignorieren

00:44:54.340 --> 00:44:55.920
und er sagt, oh, das ist für mich nicht interessant.

00:44:56.240 --> 00:44:58.120
Also wie bei HTML ist es ja auch so, genau, wenn du

00:44:58.120 --> 00:45:00.000
ein neues Tag hast, die Browser ignorieren das einfach,

00:45:00.100 --> 00:45:02.320
die es nicht können. Ja, oder auch Header generell.

00:45:02.600 --> 00:45:04.100
Das ist generell eine gute Idee, so

00:45:04.100 --> 00:45:05.400
additive,

00:45:06.040 --> 00:45:07.820
nur die Sachen verarbeiten, die man versteht.

00:45:07.980 --> 00:45:10.100
Also nicht generell, aber in vielen

00:45:10.100 --> 00:45:11.160
Fällen ist das eine gute Idee,

00:45:11.760 --> 00:45:12.840
weil man dann eben diese

00:45:12.840 --> 00:45:16.000
automatische Backwards-Compatibility hat

00:45:16.000 --> 00:45:17.860
oder automatische Forwards-Compatibility, je nachdem,

00:45:17.960 --> 00:45:18.600
wie man das sehen möchte.

00:45:21.800 --> 00:45:27.120
Ja, also irgendwie, also die Idee ist irgendwie voll cool,

00:45:27.320 --> 00:45:29.080
aber ehrlich gesagt, ich weiß nicht so richtig.

00:45:29.220 --> 00:45:29.780
Ich bin mal gespannt.

00:45:30.300 --> 00:45:33.720
Also bei jetzt HTML und Web hat es ja eigentlich mal geklappt,

00:45:33.720 --> 00:45:37.680
aber ob das, wie sich das so in Zukunft entwickelt, keine Ahnung.

00:45:39.740 --> 00:45:44.780
Ja, und andere Dinge sozusagen sind auch nicht mehr so richtig gut gealtert,

00:45:44.880 --> 00:45:45.160
fürchte ich.

00:45:45.240 --> 00:45:48.220
Also sowas wie zum Beispiel, also eigentlich, das sind schon nette Ideen.

00:45:48.880 --> 00:45:50.980
Also das HTTP-Stateless ist ja eigentlich cool,

00:45:51.060 --> 00:45:52.580
es hat diverse coole Vorteile,

00:45:53.180 --> 00:45:54.900
dass Get halt immer nur

00:45:54.900 --> 00:45:56.980
irgendwas an Daten liefert und

00:45:56.980 --> 00:45:59.180
nichts ändert, ist auch super cool, weil das bedeutet halt,

00:45:59.220 --> 00:46:00.080
du kannst super cashen.

00:46:01.020 --> 00:46:02.660
Und kannst du auch so oft machen, wie du willst.

00:46:02.800 --> 00:46:04.260
Kannst du so oft machen, wie du willst, voll gut.

00:46:04.700 --> 00:46:06.000
Das Problem ist nur, so inzwischen

00:46:06.000 --> 00:46:07.580
ist halt

00:46:07.580 --> 00:46:10.680
TLS, HTTPS ist halt

00:46:10.680 --> 00:46:11.220
überall.

00:46:12.680 --> 00:46:13.860
Sollte man auch nicht mehr ohne machen.

00:46:14.200 --> 00:46:16.340
Ja, und zu Recht auch.

00:46:16.860 --> 00:46:18.500
Ja, genau. Und damit wird das mit der

00:46:18.500 --> 00:46:20.760
Cachebarkeit und so, das ist halt dann alles so ein bisschen für die Tonne,

00:46:20.760 --> 00:46:22.740
weil, ja gut, der Browser selber kann es noch cachen,

00:46:22.880 --> 00:46:24.820
aber so, dass da irgendwo

00:46:24.820 --> 00:46:26.040
Der Server kann es cachen.

00:46:26.460 --> 00:46:28.640
Der Server kann es cachen, der Client kann es cachen, aber dazwischen

00:46:28.640 --> 00:46:29.720
kann es nicht. Ja, alles dazwischen nicht.

00:46:30.900 --> 00:46:32.240
Und ja, damit

00:46:32.240 --> 00:46:34.700
hat das nicht mehr so eine riesig große Relevanz

00:46:34.700 --> 00:46:36.620
und das war ja auch

00:46:36.620 --> 00:46:38.260
in die,

00:46:38.680 --> 00:46:40.560
ja, das sieht man jetzt auch heute ja, die ganzen

00:46:40.560 --> 00:46:42.300
so, ja, Phoenix Live View,

00:46:42.980 --> 00:46:44.620
bei Ripple & Wells gibt es das,

00:46:44.700 --> 00:46:45.680
mit Stimulus und

00:46:45.680 --> 00:46:48.360
diese ganzen Hotwire-Geschichten

00:46:48.360 --> 00:46:50.520
in anderen Frameworks

00:46:50.520 --> 00:46:52.460
kommt das jetzt auch irgendwie, dass man wieder HTML

00:46:52.460 --> 00:46:53.820
über WebSockets schickt oder so.

00:46:54.540 --> 00:46:56.500
Und einer der Gründe, warum man das anfängt zu machen

00:46:56.500 --> 00:46:58.340
oder so, ist halt auch, dass es einfach, wenn man

00:46:58.340 --> 00:47:00.520
sich anguckt, was auf dem

00:47:00.520 --> 00:47:02.580
auf der

00:47:02.580 --> 00:47:03.300
Leitung passiert,

00:47:04.340 --> 00:47:06.140
der totale Wahnsinn ist.

00:47:06.480 --> 00:47:08.460
Weil es eben, weil HTTP stateless ist,

00:47:08.840 --> 00:47:10.300
muss da halt immer irgendwie

00:47:10.300 --> 00:47:12.060
alles mitgeschickt werden, weil

00:47:12.060 --> 00:47:14.360
naja, ist ja stateless. Ja klar, weißt ja nicht,

00:47:14.380 --> 00:47:16.120
weißt ja nicht, was der schon hat oder nicht. Genau.

00:47:16.500 --> 00:47:17.380
Und das

00:47:17.380 --> 00:47:20.180
das ist eigentlich total ineffizient

00:47:20.180 --> 00:47:22.000
auch, ehrlich gesagt. Und

00:47:22.000 --> 00:47:23.920
deswegen gehen halt dann viele Richtung, ja,

00:47:24.320 --> 00:47:26.120
nehmen wir doch einfach WebSocket oder so, da haben wir

00:47:26.120 --> 00:47:27.420
dann, das ist halt dann nicht mehr Sadness.

00:47:28.340 --> 00:47:28.700
Ja.

00:47:30.280 --> 00:47:31.720
Ja, das ist aber auch so eine der,

00:47:31.880 --> 00:47:33.940
eine der, jetzt sind wir schon so weit, dass wir

00:47:33.940 --> 00:47:36.000
über die Nachteile von REST APIs

00:47:36.000 --> 00:47:36.400
sprechen,

00:47:37.560 --> 00:47:39.860
dass diese Objekte so ein bisschen in sich

00:47:39.860 --> 00:47:42.160
geschlossen sind und auch nicht auf den Anwendungsfall

00:47:42.160 --> 00:47:42.880
eingehen können.

00:47:43.820 --> 00:47:46.000
Das ist ja eine der Vorteile

00:47:46.000 --> 00:47:47.940
von RPC, dass du halt sagst, ich möchte, dass

00:47:47.940 --> 00:47:49.940
folgende Operation passiert und dafür sind

00:47:49.940 --> 00:47:51.820
die folgenden drei Werte

00:47:51.820 --> 00:47:54.040
notwendig und dann kriegst du eben die Ergebnisse

00:47:54.040 --> 00:47:56.060
der Operation und es sind dann genau sieben Werte

00:47:56.060 --> 00:47:58.040
oder irgendwie sowas. Oder genau diese

00:47:58.040 --> 00:47:59.220
Subjekte und genau diese Subjekte.

00:47:59.860 --> 00:48:01.900
Und das hast du jetzt mit REST ja nicht mehr so einfach.

00:48:02.040 --> 00:48:03.960
Mit REST greifst du ja immer quasi

00:48:03.960 --> 00:48:05.420
auf ganze Ressourcen zu.

00:48:08.000 --> 00:48:09.400
Oder eben auf Teil

00:48:09.400 --> 00:48:11.540
Ressourcen, die dann vom Server

00:48:11.540 --> 00:48:14.120
auf eine gewisse Art und Weise zur Verfügung gestellt werden,

00:48:14.660 --> 00:48:15.960
die aber eventuell gar nichts mit

00:48:15.960 --> 00:48:17.940
deinem Use Case zu tun haben. Also wenn ich

00:48:17.940 --> 00:48:19.840
jetzt meine gesamte

00:48:19.840 --> 00:48:22.420
Freundesliste abrufen möchte, dann müsste ich prinzipiell

00:48:22.420 --> 00:48:25.680
ja alle Links zu meinen

00:48:25.680 --> 00:48:27.840
Freundesobjekten abrufen und dann allen

00:48:27.840 --> 00:48:29.800
Links folgen und jedes Freundesobjekt

00:48:29.800 --> 00:48:30.600
einzeln abrufen,

00:48:31.620 --> 00:48:34.000
damit ich meine Freundesliste anzeigen

00:48:34.000 --> 00:48:35.920
kann. Was ja absurd ist, weil meine

00:48:35.920 --> 00:48:37.280
Freundesliste ist ja einfach nur

00:48:37.280 --> 00:48:39.920
eine Liste von den Namen der

00:48:39.920 --> 00:48:40.760
Freunde und fertig.

00:48:43.440 --> 00:48:44.280
Ja, ja.

00:48:44.280 --> 00:48:47.880
Ja, ich meine, man würde sich dann halt vielleicht wünschen,

00:48:48.040 --> 00:48:50.320
eben auch gerade, wenn man dann jetzt unterschiedliche Clients hat,

00:48:50.500 --> 00:48:52.080
die unterschiedliche Sachen darstellen,

00:48:52.500 --> 00:48:54.880
dass man als Client kontrollieren kann, was denn dann da kommt

00:48:54.880 --> 00:48:56.860
und das je nachdem, was man halt braucht.

00:48:57.860 --> 00:49:01.780
Ja, aber dann hat man im Grunde eben keine Restschnittstelle

00:49:01.780 --> 00:49:04.500
und dann hält man irgendwie sowas wie eine Datenbank-Schnittstelle.

00:49:05.700 --> 00:49:06.120
Ja, genau.

00:49:06.200 --> 00:49:09.580
Und das ist ja auch der Grund, warum es diese Weiterentwicklungen gibt,

00:49:09.580 --> 00:49:11.080
die du jetzt gleich erklärst.

00:49:12.840 --> 00:49:13.980
Genau, GraphQL.

00:49:14.280 --> 00:49:17.120
wo der Client eben kontrollieren kann,

00:49:17.340 --> 00:49:18.680
welche Attribute geschickt werden

00:49:18.680 --> 00:49:20.140
und welche Objekte geschickt werden.

00:49:20.700 --> 00:49:22.460
Weil es eben Use Cases gibt,

00:49:22.740 --> 00:49:25.720
in denen nicht das ganze Objekt interessant ist

00:49:25.720 --> 00:49:28.600
und oder sehr viele verschiedene Objekte interessant sind.

00:49:28.980 --> 00:49:30.440
Ja, nur dann würde,

00:49:30.680 --> 00:49:32.400
also aus der Sicht eines Restpuristen

00:49:32.400 --> 00:49:34.120
würde ich jetzt sagen, ja gut,

00:49:34.240 --> 00:49:36.520
aber das ist ja, da macht der Client ja schon viel zu viel.

00:49:37.060 --> 00:49:38.520
Das hat dem Client alles nichts anzugehen,

00:49:38.520 --> 00:49:39.640
das muss alles der Server machen.

00:49:41.100 --> 00:49:41.600
Das ist ja nicht,

00:49:41.980 --> 00:49:43.780
da hat der Client viel zu viel State

00:49:43.780 --> 00:49:47.980
Und das geht ja alles gar nicht.

00:49:48.760 --> 00:49:51.580
Ja, aber das ist ein bisschen unrealistisch.

00:49:51.720 --> 00:49:52.880
Gegen Regen argumentieren.

00:49:54.280 --> 00:49:55.720
Es ist schlecht, dass es den gibt.

00:49:56.100 --> 00:49:58.440
Und der fällt aus dem Himmel runter und der macht alles nass.

00:49:58.580 --> 00:49:59.380
Aber es ist halt so.

00:50:00.420 --> 00:50:01.640
Ja, ja.

00:50:05.120 --> 00:50:08.660
Es ist nicht schwer, sich vorzustellen,

00:50:08.780 --> 00:50:11.080
dass es Leute gibt, die ihren Freunden Nachrichten schicken wollen.

00:50:11.080 --> 00:50:12.740
Sondern schon brauche ich eine Liste der Leute,

00:50:12.880 --> 00:50:13.880
denen ich Nachrichten schicken kann.

00:50:16.580 --> 00:50:20.160
Und da hilft mir aller Rest Purismus nichts,

00:50:20.340 --> 00:50:22.220
weil das müsste dann irgendwie abdecken.

00:50:26.500 --> 00:50:28.520
Es gibt auch Fälle,

00:50:29.160 --> 00:50:30.060
sagen wir mal so,

00:50:30.700 --> 00:50:32.660
um es positiv zu formulieren,

00:50:33.700 --> 00:50:35.440
für manche Anwendungsfälle

00:50:35.440 --> 00:50:39.540
braucht es ein bisschen Umdenken

00:50:39.540 --> 00:50:41.800
von diesem Prozeduraldenken.

00:50:42.280 --> 00:50:43.740
Wir als Programmierer

00:50:43.740 --> 00:50:45.960
haben ja oft so ein prozedurales

00:50:45.960 --> 00:50:47.540
Denken, ja, ich möchte, dass jetzt irgendwas

00:50:47.540 --> 00:50:49.560
passiert und deshalb schreibe ich

00:50:49.560 --> 00:50:51.240
diese, rufe ich diese Funktion auf, ja.

00:50:51.300 --> 00:50:53.920
In Python ist ja im Wesentlichen

00:50:53.920 --> 00:50:55.460
alles, was man macht, irgendwelche Funktionen

00:50:55.460 --> 00:50:57.520
aufrufen und innerhalb der Funktionen passiert

00:50:57.520 --> 00:50:58.340
dann irgendwas anderes.

00:50:59.560 --> 00:51:01.600
Und das ist jetzt bei REST ganz

00:51:01.600 --> 00:51:03.540
anders, ja, bei REST sage ich einfach nur,

00:51:04.400 --> 00:51:05.500
es soll dieses Objekt

00:51:05.500 --> 00:51:07.480
geben, mehr kann ich ja nicht sagen.

00:51:08.740 --> 00:51:30.380
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.

00:51:30.380 --> 00:51:51.260
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.

00:51:51.700 --> 00:51:53.620
Aber wenn das irgendwas ist, was steuert,

00:51:53.700 --> 00:51:55.120
wenn ich eine

00:51:55.120 --> 00:51:57.480
Schnittstelle habe für irgendwelche Geräte

00:51:57.480 --> 00:51:59.460
oder für irgendwelche

00:51:59.460 --> 00:52:00.120
Prozesse,

00:52:00.780 --> 00:52:02.800
dann finde ich das schon schwieriger

00:52:02.800 --> 00:52:05.480
zu sagen, es soll jetzt dieses

00:52:05.480 --> 00:52:06.120
Objekt geben.

00:52:08.120 --> 00:52:08.520
Ja, ja.

00:52:09.080 --> 00:52:11.600
Wenn ich ein Licht anmache über eine REST-Schnittstelle,

00:52:11.740 --> 00:52:13.360
dann heißt das, ich

00:52:13.360 --> 00:52:15.480
bearbeite das Lichtaktivierungsobjekt

00:52:16.120 --> 00:52:17.440
und setze das Attribut an

00:52:17.440 --> 00:52:19.500
auf, ja, anstatt dass ich sage,

00:52:19.600 --> 00:52:20.180
mach das Licht an.

00:52:21.440 --> 00:52:25.360
Ja, das ist so ein bisschen, ja.

00:52:26.360 --> 00:52:27.660
Es erfordert ein gewisses Umdenken.

00:52:28.140 --> 00:52:28.260
Ja.

00:52:30.180 --> 00:52:31.280
Ja, ja, ja, ja.

00:52:31.440 --> 00:52:32.940
Ja, ich überlege gerade, ob man sagen könnte,

00:52:33.020 --> 00:52:36.640
man erzeugt einfach ein Event oder so, dann, aber.

00:52:37.620 --> 00:52:39.780
Ja, das ist ja dann auch das, was man sich dann.

00:52:40.220 --> 00:52:42.480
Ein Kontrollvorgang, dem steht Licht an oder Licht aus.

00:52:43.140 --> 00:52:44.860
Ja, genau, wo du dann eben sagst,

00:52:45.640 --> 00:52:47.760
wo man sich so ein bisschen behilft, ja,

00:52:47.820 --> 00:52:50.500
wo man sich sagt, ich erzeuge jetzt nicht,

00:52:50.880 --> 00:52:52.840
ich verändere jetzt nicht das Lichtzustandobjekt,

00:52:52.840 --> 00:52:57.120
sondern ich erzeuge ein Lichtanschalten-Wunschobjekt

00:52:57.120 --> 00:52:58.080
oder irgendwie sowas, ja.

00:52:58.220 --> 00:53:01.040
Dass du sozusagen Funktionen als Objekte siehst

00:53:01.040 --> 00:53:03.440
und dann eben ein neues Funktionsobjekt erzeugst.

00:53:03.940 --> 00:53:06.180
Aber das ist ja schon ein bisschen beschummelt, oder, Jochen?

00:53:06.660 --> 00:53:08.460
Fühlst du dich da gut dabei, wenn du sowas machst?

00:53:09.260 --> 00:53:11.240
Nee, auf der anderen Seite würde ich sagen,

00:53:11.360 --> 00:53:12.940
ich meine, worauf es hinausläuft,

00:53:13.180 --> 00:53:16.080
die grundsätzlichen Operationen, die man tun kann, sind halt,

00:53:16.460 --> 00:53:17.340
das ist mal, ich weiß nicht,

00:53:17.360 --> 00:53:18.880
das hatten wir bestimmt auch schon ein paar Mal erwähnt oder so,

00:53:18.900 --> 00:53:19.400
ist halt CRUD.

00:53:20.200 --> 00:53:23.220
So, create, read, update, delete.

00:53:24.660 --> 00:53:26.160
Und ich finde es immer wieder erstaunlich,

00:53:26.280 --> 00:53:28.640
was sich alles darauf mappen lässt, weil tatsächlich ...

00:53:28.640 --> 00:53:29.960
Ja, alles, du kannst alles darauf mappen.

00:53:30.020 --> 00:53:30.720
Ja, ja, gut, aber ...

00:53:30.720 --> 00:53:32.360
Alles, was in dem Computer drin ist, kannst du darauf mappen.

00:53:32.360 --> 00:53:33.840
Es geht sogar halbwegs elegant.

00:53:34.180 --> 00:53:35.580
Also oft ist es tatsächlich so,

00:53:35.660 --> 00:53:37.820
dass es auf den tatsächlichen Anwendungsfall eigentlich ganz gut,

00:53:38.200 --> 00:53:40.100
also oft passt es einfach ganz gut.

00:53:41.140 --> 00:53:43.460
Und man ist eigentlich dann zufrieden.

00:53:44.460 --> 00:53:47.180
Natürlich, in manchen Spezialfällen,

00:53:47.500 --> 00:53:49.940
da muss man halt dann überlegen und tricksen.

00:53:50.200 --> 00:53:51.760
weil es dann so nicht einfach geht, ja.

00:53:53.200 --> 00:53:57.200
Aber prinzipiell, ja, das ist auch immer etwas,

00:53:57.260 --> 00:53:58.980
was man da auch ...

00:53:58.980 --> 00:54:00.700
Es gibt schon so Sachen, Jochen,

00:54:00.920 --> 00:54:02.500
wo ich mir da sehr schwer tue,

00:54:03.280 --> 00:54:06.560
wo eben was passieren soll,

00:54:06.900 --> 00:54:08.700
wo mein gedankliches Modell nicht ist,

00:54:09.260 --> 00:54:11.940
da wird ein Datensatz erzeugt oder bearbeitet,

00:54:12.100 --> 00:54:13.480
sondern da soll jetzt etwas passieren,

00:54:13.580 --> 00:54:15.120
da soll jetzt ein ...

00:54:15.120 --> 00:54:17.280
Ich schicke ein Bild an eine Bilderkennungs-API,

00:54:17.400 --> 00:54:19.680
dann ist es für mich nicht ...

00:54:19.680 --> 00:54:28.500
Ich möchte, dass es dieses Bilderkennungsobjekt gibt, sondern dann sage ich im Wesentlichen, ich möchte, dass jetzt dieses Bild ausgeführt wird.

00:54:28.500 --> 00:54:30.740
Ich möchte, dass jetzt mit diesem Bild irgendwas ausgeführt wird.

00:54:31.440 --> 00:54:41.620
Und trotz allem, es gibt ja die vorgenannten Puristen, die sagen, alles muss eine REST-Schnittstelle sein und du musst alles 100% RESTful machen,

00:54:42.380 --> 00:54:48.440
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,

00:54:48.540 --> 00:54:50.440
weil ich eben so prozedurale Endpunkte

00:54:50.440 --> 00:54:51.460
habe, so prozedurale.

00:54:53.480 --> 00:54:53.920
Ein

00:54:53.920 --> 00:54:56.180
Funktionsobjekt mit folgenden

00:54:56.180 --> 00:54:57.520
Parametern wurde angelegt.

00:54:58.460 --> 00:54:59.740
Ja, das ist natürlich irgendwie,

00:55:00.360 --> 00:55:02.280
also ja, nee, ich meine, es gibt Dinge, die

00:55:02.280 --> 00:55:04.100
da nicht so gut reinpassen, wo man dann auch nicht,

00:55:04.200 --> 00:55:06.300
gerade bei sowas wie, wenn man jetzt Blobs hat, eben

00:55:06.300 --> 00:55:07.520
Bilder oder sowas,

00:55:08.440 --> 00:55:10.420
da ist sowieso

00:55:10.420 --> 00:55:12.180
schwierig da irgendwie, genau.

00:55:14.040 --> 00:55:14.680
Ist ja auch

00:55:14.680 --> 00:55:16.500
dann ganz schwierig, das kriegst du ja auch nicht

00:55:16.500 --> 00:55:18.160
per Get, so, also das

00:55:18.160 --> 00:55:20.480
natürlich, du kriegst

00:55:20.480 --> 00:55:22.360
auf jeden Fall nicht mehr bei JSON. Du musst dann halt, wenn du

00:55:22.360 --> 00:55:24.440
ByteRange pressst, ob du irgendwelche Blobs machst, dann

00:55:24.440 --> 00:55:26.460
da gibt's... Moment, wenn du über ByteRange

00:55:26.460 --> 00:55:28.560
denkst, dann irgendwelche Blobs. Also ein Blob ist irgendwie eine Art

00:55:28.560 --> 00:55:30.460
Datei-Objekt oder sowas. Ja. Also

00:55:30.460 --> 00:55:32.500
zum Beispiel so was wie eine Podcast-Episode. Ein Binary

00:55:32.500 --> 00:55:33.840
Large Object. Ja.

00:55:35.020 --> 00:55:36.440
Also eine Podcast-Episode und du

00:55:36.440 --> 00:55:38.520
willst jetzt an Minute 30

00:55:38.520 --> 00:55:40.560
weil, anfangen

00:55:40.560 --> 00:55:41.980
zu hören, weil da beginnt

00:55:41.980 --> 00:55:44.260
der interessante Teil über REST.

00:55:45.560 --> 00:55:46.540
Aber das ist ja tatsächlich

00:55:46.540 --> 00:55:48.620
bei REST nicht vorgegeben,

00:55:48.740 --> 00:55:50.340
welche Datenstrukturen du

00:55:50.340 --> 00:55:51.720
verwendest, sondern ganz im Gegenteil.

00:55:51.960 --> 00:55:54.320
Jeder Request soll ja immer einen Media-Type haben

00:55:54.320 --> 00:55:56.280
und dann halt kannst du es in verschiedenen

00:55:56.280 --> 00:55:58.240
Sachen abrufen. Also REST ist gar nicht

00:55:58.240 --> 00:55:58.980
nur JSON.

00:56:00.240 --> 00:56:02.280
Kann auch XML

00:56:02.280 --> 00:56:04.160
sein, wenn du willst.

00:56:04.700 --> 00:56:04.960
Hurra!

00:56:06.120 --> 00:56:08.220
Aber das ist ja eine der Eigenschaften vom Web, dass

00:56:08.220 --> 00:56:10.360
das Web eben nicht nur JSON

00:56:10.360 --> 00:56:12.320
übertragen kann, sondern es kann alles übertragen

00:56:12.320 --> 00:56:14.620
und das soll hier eben auch mit reingehen

00:56:14.620 --> 00:56:16.400
und das ist auch eine der großen Stärken,

00:56:16.620 --> 00:56:18.440
die zum Beispiel in Django hat man ja

00:56:18.440 --> 00:56:20.380
diese wunderbare Bibliothek

00:56:20.380 --> 00:56:21.260
Django REST Framework.

00:56:22.060 --> 00:56:24.500
Ich erinnere mich noch, als ich die zum ersten Mal

00:56:24.500 --> 00:56:26.920
gefunden habe und das war so eine Offenbarung,

00:56:27.660 --> 00:56:28.700
dass so was geht

00:56:28.700 --> 00:56:30.400
und dann so schön die Schnellen macht

00:56:30.400 --> 00:56:32.360
und die einen ganz einfachen Trick

00:56:32.360 --> 00:56:34.660
verwenden, Browser senden

00:56:34.660 --> 00:56:36.200
als Media Type

00:56:36.200 --> 00:56:38.380
oder als Preferred Media Type immer

00:56:38.380 --> 00:56:39.700
Application HTML mit

00:56:39.700 --> 00:56:42.680
und so

00:56:42.680 --> 00:56:44.700
Schnittstellen haben ja normalerweise Application

00:56:44.700 --> 00:56:46.520
JSON und

00:56:46.520 --> 00:56:48.760
wenn du aber Application

00:56:48.760 --> 00:56:50.700
HTML abrufst

00:56:50.700 --> 00:56:52.880
von dieser mit Django REST Framework

00:56:52.880 --> 00:56:54.660
erzeugten Schnittstelle, dann kriegst du das

00:56:54.660 --> 00:56:56.400
Ergebnis als Webseite

00:56:56.400 --> 00:56:58.680
mit allen Bells und

00:56:58.680 --> 00:57:00.520
Whistles, die es so gibt, also mit Formularen

00:57:00.520 --> 00:57:02.760
und mit Login-Anzeige

00:57:02.760 --> 00:57:04.620
und mit Dokumentation automatisch

00:57:04.620 --> 00:57:06.160
angezeigt und das ist eine super Sache.

00:57:06.420 --> 00:57:08.580
Du kannst verschiedene Media Types

00:57:08.580 --> 00:57:10.820
anfordern. Und auch Juggeress-Framework

00:57:10.820 --> 00:57:12.740
stellt ja durch diese Serializer, die man

00:57:12.740 --> 00:57:13.620
normalerweise hat.

00:57:14.760 --> 00:57:16.600
Das ist wie das Formular, was man sonst so kennt, ja?

00:57:17.400 --> 00:57:18.680
Genau, der stellt dieses Formular

00:57:18.680 --> 00:57:20.720
zur Verfügung, der stellt auch den JSON-Datentyp

00:57:20.720 --> 00:57:22.500
zur Verfügung, also es gibt auch

00:57:22.500 --> 00:57:24.740
die Möglichkeit, da XML einzustellen. Dann kriegst du halt

00:57:24.740 --> 00:57:26.700
XML-Objekte, die auf irgendeine Art

00:57:26.700 --> 00:57:28.580
und Weise formatiert sind. Du kannst auch

00:57:28.580 --> 00:57:30.620
selber einen schreiben, der halt irgendwas anderes

00:57:30.620 --> 00:57:32.760
macht. Und das ist auch

00:57:32.760 --> 00:57:34.620
eine der Stärken. Das bedeutet

00:57:34.620 --> 00:57:36.600
ja aber nicht, dass jede Antwort auf

00:57:36.600 --> 00:57:38.440
ein Get immer ein JSON sein muss.

00:57:38.520 --> 00:57:40.340
Das bedeutet halt nur, dass

00:57:40.340 --> 00:57:42.480
es Media-Types gibt,

00:57:42.640 --> 00:57:44.320
die von verschiedenen Branches unterstützt werden

00:57:44.320 --> 00:57:46.560
und andere werden halt nicht unterstützt. Und gerade

00:57:46.560 --> 00:57:48.220
bei so einem Blob-Objekt wäre es halt dann

00:57:48.220 --> 00:57:50.340
ja, Application

00:57:50.340 --> 00:57:52.340
irgendwie ein binäres Name. Binary.

00:57:52.800 --> 00:57:54.760
Weiß ich nicht. Octet. Octet-Stream.

00:57:54.760 --> 00:57:54.980
Ja.

00:57:56.420 --> 00:57:58.840
Ja, ja, ja. Nee, stimmt schon. Also insofern

00:57:58.840 --> 00:58:00.300
würde das da auch reinpassen. Ja.

00:58:00.580 --> 00:58:02.340
Ganz kurz nochmal. Octet-Stream. Was ist das denn?

00:58:03.400 --> 00:58:04.700
Ja, Octet ist ein cooler,

00:58:04.860 --> 00:58:06.200
ist der coolere Name für Byte.

00:58:06.360 --> 00:58:07.020
Also es sind einfach

00:58:07.020 --> 00:58:09.560
Binärdaten, die übertragen werden.

00:58:09.620 --> 00:58:10.740
Also zwei hoch...

00:58:10.740 --> 00:58:14.440
Das ist so der Fallback-Type.

00:58:14.840 --> 00:58:16.020
Wenn ich nicht weiß, was es ist,

00:58:16.080 --> 00:58:17.300
dann sind es halt irgendwie Binärdaten.

00:58:17.440 --> 00:58:19.900
Und das heißt halt als Mime-Typ oder als Datentyp

00:58:19.900 --> 00:58:22.480
heißt es Application-slash-Octet-Stream.

00:58:22.780 --> 00:58:23.400
Heißt einfach nur

00:58:23.400 --> 00:58:24.800
irgendwelche Daten, keine Ahnung.

00:58:25.280 --> 00:58:26.300
Okay, Octet-Stream.

00:58:27.460 --> 00:58:29.320
Auch gerade, wie er zum ersten Mal drüber gestolpert hat, das ist ja Wahnsinn.

00:58:29.940 --> 00:58:31.580
Wie lange macht er das eigentlich schon? Ich weiß es nicht.

00:58:32.540 --> 00:58:33.100
Zu lange.

00:58:35.360 --> 00:58:46.740
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?

00:58:47.320 --> 00:58:55.860
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.

00:58:55.860 --> 00:59:00.860
Ja, das heißt, man kann quasi nach Options fragen und dann bekommt man alle Optionen, die Datentypen bereichern.

00:59:01.420 --> 00:59:19.180
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 …

00:59:19.180 --> 00:59:20.400
Geradezu mickrig, kurzen.

00:59:21.180 --> 00:59:23.220
Meine Frau hat sich vorhin drüber lustig gemacht,

00:59:23.320 --> 00:59:25.060
dass wir immer so lange eine Episode aufnehmen.

00:59:25.160 --> 00:59:27.180
Aber ich habe gesagt, das ist halt so.

00:59:29.560 --> 00:59:31.200
Dann möchte ich eben nicht

00:59:31.200 --> 00:59:32.220
die gesamte,

00:59:32.880 --> 00:59:35.280
möchte ich nicht diese ganze

00:59:35.280 --> 00:59:37.260
Episode auf einmal abrufen, sondern ich möchte erst mal

00:59:37.260 --> 00:59:38.800
sehen, ob ich die überhaupt verwenden kann.

00:59:39.520 --> 00:59:41.140
Und dann schicke ich da einen Options-Request hin

00:59:41.140 --> 00:59:43.200
und dann sagt mir der Server halt, ja, der hat so und so

00:59:43.200 --> 00:59:44.860
viel Bytes und

00:59:44.860 --> 00:59:46.620
der Content-Type ist so und so.

00:59:47.720 --> 00:59:48.700
Und dann kann ich sozusagen

00:59:48.700 --> 00:59:50.720
ausprobieren, ob die

00:59:50.720 --> 00:59:52.500
ob diese Anfrage sinnvoll ist.

00:59:53.300 --> 00:59:54.040
Ja, okay.

00:59:56.840 --> 00:59:57.240
Interessant.

00:59:58.980 --> 00:59:59.740
Aber um jetzt wieder zu

00:59:59.740 --> 01:00:02.640
REST-APIs zurückzukommen in Python.

01:00:03.200 --> 01:00:04.540
Also Django REST Framework haben wir gerade erwähnt,

01:00:04.660 --> 01:00:06.480
also da wir alle gerne Django machen,

01:00:06.580 --> 01:00:07.920
ist das glaube ich einer der Ways to go.

01:00:07.940 --> 01:00:10.100
Das ist tatsächlich auch ziemlich großartig, da habe ich auch viel.

01:00:10.380 --> 01:00:11.300
Das ist auch so ein Ding,

01:00:12.500 --> 01:00:14.020
ich weiß nicht, ich glaube, das ist auch so ein

01:00:14.020 --> 01:00:16.400
wiederkehrendes Thema, das habe ich jetzt auch

01:00:16.400 --> 01:00:18.080
von anderen schon gehört

01:00:18.080 --> 01:00:19.960
und das war bei mir so und

01:00:19.960 --> 01:00:20.880
vielleicht auch bei anderen noch.

01:00:22.380 --> 01:00:23.860
Also oft sind so die ersten

01:00:23.860 --> 01:00:25.860
gut funktionierenden Projekte

01:00:25.860 --> 01:00:28.140
irgendwas mit Jungle-Rest-Framework bei vielen Leuten

01:00:28.140 --> 01:00:30.080
gewesen. Ich weiß nicht so genau, woran

01:00:30.080 --> 01:00:31.980
das liegt, aber tatsächlich würde ich jetzt mal so

01:00:31.980 --> 01:00:34.160
okay, keine Ahnung, also ich habe ja

01:00:34.160 --> 01:00:34.600
Wirtschaft,

01:00:35.240 --> 01:00:37.880
mag daran liegen, dass es super ist, aber auch,

01:00:38.000 --> 01:00:39.840
dass es halt einfach, dass man da

01:00:39.840 --> 01:00:42.020
dann anfängt, in einem etwas interessanteren

01:00:42.020 --> 01:00:42.820
Markt zu sein, weil das,

01:00:43.820 --> 01:00:45.480
was man sonst so sieht, also

01:00:45.480 --> 01:00:47.660
naja, wenn du

01:00:47.660 --> 01:00:49.900
irgendwie, keine Ahnung, also das, was halt so

01:00:49.900 --> 01:00:52.520
gibt es ja viele, viele, die

01:00:52.520 --> 01:00:54.760
Wordpress-Seiten machen oder so, keine Ahnung,

01:00:54.840 --> 01:00:56.900
Zeugs. Und da

01:00:56.900 --> 01:00:58.720
bist du halt in einem sehr

01:00:58.720 --> 01:01:00.800
unglücklichen Quadranten aus meiner Perspektive.

01:01:00.960 --> 01:01:02.680
Das ist halt irgendwie low budget.

01:01:04.060 --> 01:01:04.820
Die Kunden sind

01:01:04.820 --> 01:01:06.640
üblicherweise nicht bereit, da so wahnsinnig viel Geld für

01:01:06.640 --> 01:01:08.460
auszugeben, weil es gibt so wahnsinnig...

01:01:08.460 --> 01:01:10.700
Es war früher ein besserer Markt. Ja, kann auch sein, dass

01:01:10.700 --> 01:01:12.680
es mal gut war, aber ich glaube, mittlerweile ist es nicht mehr so richtig

01:01:12.680 --> 01:01:14.440
toll. Dann ist es auch low value,

01:01:14.660 --> 01:01:16.060
weil irgendwie es ist

01:01:16.060 --> 01:01:18.840
einfach nicht so geil. Es ist meistens

01:01:18.840 --> 01:01:20.960
irgendwelche, naja,

01:01:21.320 --> 01:01:23.440
doch eher so technisch herausgeforderte

01:01:23.440 --> 01:01:25.540
Hoster. Das kommt dann über die Add-ons,

01:01:25.680 --> 01:01:27.040
glaube ich, wenn du dann noch ein Magento

01:01:27.040 --> 01:01:28.960
dran machen kannst, dann bist du wieder. Genau,

01:01:29.120 --> 01:01:31.120
dann kannst du natürlich irgendwie so lange Plugins

01:01:31.120 --> 01:01:32.800
installieren, bis es dann vielleicht doch funktioniert.

01:01:33.180 --> 01:01:35.060
Das Problem dabei ist, dann bist du aber auch bei

01:01:35.060 --> 01:01:36.120
einem anderen unangenehmen

01:01:36.120 --> 01:01:39.420
Attribut, nämlich ist es dann kompliziert

01:01:39.420 --> 01:01:41.320
und schwierig, das irgendwie richtig hinzukriegen.

01:01:41.620 --> 01:01:42.920
Das heißt, es ist schlecht bezahlt,

01:01:43.240 --> 01:01:44.960
du kriegst nicht so viel richtig Wert

01:01:44.960 --> 01:01:47.100
hin und es ist auch noch

01:01:47.100 --> 01:01:49.300
schwierig. Das ist einfach ein unangenehmer

01:01:49.300 --> 01:01:50.360
Ort. Während,

01:01:50.480 --> 01:01:51.920
würde ich jetzt mal so sagen,

01:01:52.460 --> 01:01:53.520
wenn du halt

01:01:53.520 --> 01:01:56.680
dann sowas machst wie die Django REST Framework oder so,

01:01:57.300 --> 01:01:58.700
da ist plötzlich

01:01:58.700 --> 01:02:00.680
richtig Wert drin, wenn da

01:02:00.680 --> 01:02:02.600
irgendwie die Apps von Leuten richtig gut

01:02:02.600 --> 01:02:03.120
funktionieren,

01:02:04.340 --> 01:02:06.420
da suchen Leute

01:02:06.420 --> 01:02:08.780
händeringend, da sind dann die Preise irgendwie anders

01:02:08.780 --> 01:02:10.600
und es generiert

01:02:10.600 --> 01:02:12.680
halt auch irgendwie ordentlich mehr Wert,

01:02:13.160 --> 01:02:14.460
wenn das halt gut funktioniert und man ein

01:02:14.460 --> 01:02:16.460
nettes Interface hat, wo man die API

01:02:16.460 --> 01:02:17.960
sich angucken kann und so.

01:02:18.900 --> 01:02:20.720
Und ja, das funktioniert dann

01:02:20.720 --> 01:02:22.160
plötzlich irgendwie, würde ich mal so

01:02:22.160 --> 01:02:23.040
sagen.

01:02:24.000 --> 01:02:26.700
Ja, mit Django ist das

01:02:26.700 --> 01:02:28.480
echt tatsächlich ganz nett. Also ich habe mal so ein bisschen

01:02:28.480 --> 01:02:30.520
geguckt, was tatsächlich in der Zukunft noch

01:02:30.520 --> 01:02:32.580
so geplant ist. Und da stehen

01:02:32.580 --> 01:02:34.500
tatsächlich relativ nette Dinge drin. Zum Beispiel

01:02:34.500 --> 01:02:36.060
Realtime-API-Support

01:02:36.060 --> 01:02:37.380
using Websockets.

01:02:38.960 --> 01:02:40.700
Ja, dann mit Django-Channels

01:02:40.700 --> 01:02:41.980
in Zusammenhang.

01:02:42.400 --> 01:02:44.560
Better Authentication by Default, also die wollen

01:02:44.560 --> 01:02:46.340
vielleicht sogar Jot und

01:02:46.340 --> 01:02:48.660
Core-Support in das Core-Package reinbringen,

01:02:49.260 --> 01:02:50.660
wo wir ja eben schon kurz sprachen.

01:02:50.780 --> 01:02:52.100
Das klingt doch ganz interessant.

01:02:53.680 --> 01:02:54.340
Was war das?

01:02:55.280 --> 01:02:56.240
Django REST Framework.

01:02:57.620 --> 01:02:58.400
Dominik, erzähl mal,

01:02:58.440 --> 01:02:59.800
ich habe gleich noch eine

01:02:59.800 --> 01:03:01.400
kleine Randnotiz.

01:03:02.140 --> 01:03:04.140
Was war das für eine Authentifizierung?

01:03:04.320 --> 01:03:06.600
Jot JWT.

01:03:07.880 --> 01:03:08.760
Ah, echt?

01:03:08.760 --> 01:03:10.920
Ja, das ist Java JSON Web Tokens.

01:03:10.920 --> 01:03:11.720
JSON Web Tokens?

01:03:12.080 --> 01:03:14.180
Aber da gibt es ja Bibliotheken.

01:03:14.320 --> 01:03:17.860
Also ich meine, das ist ja nur ein PIP-Installed entfernt.

01:03:17.860 --> 01:03:24.560
Ja, aber da gibt es ja verschiedene nicht so gute Varianten.

01:03:24.860 --> 01:03:26.220
Die sind alle so ein bisschen ...

01:03:26.220 --> 01:03:27.860
Ja, aber das Problem ist halt irgendwie,

01:03:27.940 --> 01:03:29.180
dass der Standard wohl nicht okay ist.

01:03:29.320 --> 01:03:30.820
Und dann ist es halt schwierig, dass ...

01:03:30.820 --> 01:03:32.180
Ja, aber die Frage ist, warum der Standard nicht okay ist.

01:03:32.200 --> 01:03:33.020
Wenn ich das richtig verstanden habe,

01:03:33.100 --> 01:03:34.240
weil es verschiedene Möglichkeiten gibt,

01:03:34.300 --> 01:03:36.620
diese Schlüssel zu erzeugen oder überhaupt diese Token zu erzeugen.

01:03:36.620 --> 01:03:38.260
Weil es so viele Konfigurationen gibt.

01:03:38.480 --> 01:03:42.120
Weil du sozusagen so Downgrade-Angriffe machen kannst.

01:03:42.200 --> 01:03:43.400
Du kannst dem Server sagen,

01:03:43.940 --> 01:03:46.320
ja, schön, dass du diese ganzen sicheren Methoden hast.

01:03:47.080 --> 01:03:48.000
Ich bin ein kleiner, dummer Client.

01:03:48.060 --> 01:03:48.920
Ich kann das leider alles nicht.

01:03:49.240 --> 01:03:50.120
Ich unterstütze die alle nicht.

01:03:50.260 --> 01:03:55.020
Ich unterstütze nur etwas, was halt im Standard definiert ist,

01:03:55.120 --> 01:03:56.080
was aber super unsicher ist.

01:03:56.400 --> 01:03:57.680
Und dann nutze ich aus, dass es unsicher ist.

01:03:58.280 --> 01:03:59.920
Und das ist natürlich Kacke, wenn das im Standard steht.

01:04:00.060 --> 01:04:00.600
Das kannst du machen.

01:04:01.080 --> 01:04:02.560
Ja, also das ist halt ...

01:04:02.560 --> 01:04:05.580
Du musst dann deinen Server so konfigurieren,

01:04:05.700 --> 01:04:06.920
dass der die Sachen nicht annimmt.

01:04:07.020 --> 01:04:09.180
Aber es ist relativ schwierig, herauszufinden,

01:04:09.300 --> 01:04:11.240
was jetzt gerade alles schon unsicher ist.

01:04:11.940 --> 01:04:14.020
Also das heißt, es geht darum, welche Algorithmen

01:04:14.020 --> 01:04:15.700
der nehmen kann zum Bereitstellen dieser Token,

01:04:15.780 --> 01:04:16.780
dass man den nicht zurückrechnen kann.

01:04:19.040 --> 01:04:20.040
Ja, zum einen das

01:04:20.040 --> 01:04:21.440
und zum anderen auch die Token Art.

01:04:21.660 --> 01:04:23.880
Es gibt ja signierte Token und unsignierte Token

01:04:23.880 --> 01:04:25.840
und wenn der Kleinteil sagt, ich kann nur

01:04:25.840 --> 01:04:26.420
die unsignierten.

01:04:27.280 --> 01:04:29.780
Und der Server ist so eingestellt, dass er auch die unsignierten

01:04:29.780 --> 01:04:31.420
annimmt, dann nimmt er halt auch die unsignierten an.

01:04:31.440 --> 01:04:33.660
Und dann irgendwie so einen kleinen Verschlüsselungsalgorithmus nimmt,

01:04:33.720 --> 01:04:35.380
den man in der Rainbow Table nachgucken kann oder sowas.

01:04:36.260 --> 01:04:37.440
Ja, oder halt auch gar keinen.

01:04:37.600 --> 01:04:39.620
Wenn du sagst, naja, Verschlüsselung, naja, kann ich nicht.

01:04:41.940 --> 01:04:43.680
Das ist eben wirklich so

01:04:43.680 --> 01:04:45.860
die Frage,

01:04:46.000 --> 01:04:47.640
was ist jetzt gerade der aktuelle

01:04:47.640 --> 01:04:49.780
Zustand der Sicherheit? Und eigentlich müsste man sich da

01:04:49.780 --> 01:04:50.840
sehr gut drum kümmern.

01:04:52.060 --> 01:04:53.780
Und also ich weiß

01:04:53.780 --> 01:04:55.700
nur mal, so ganz im Detail kann ich es nicht. Ich weiß nur,

01:04:55.760 --> 01:04:57.620
dass Leute immer sagen, oh mein Gott, das ist alles schrecklich.

01:04:58.660 --> 01:04:59.500
Und JVT, also

01:04:59.500 --> 01:05:01.700
von ihm, gab es

01:05:01.700 --> 01:05:03.540
irgendwie einen Post auf der Django-Mailing-Liste

01:05:03.540 --> 01:05:05.680
von James Bennett, glaube ich, wo der mehr oder

01:05:05.680 --> 01:05:07.680
weniger klipp und klar gesagt hat, JVT werden wir

01:05:07.680 --> 01:05:09.940
in Django niemals machen. Das ist irgendwie...

01:05:09.940 --> 01:05:10.260
Jott?

01:05:11.940 --> 01:05:13.600
Was ist das?

01:05:13.600 --> 01:05:14.280
Ich glaube, man sagt Jot.

01:05:14.440 --> 01:05:17.300
Dominik, du bist der Einzige, der Jot sagt.

01:05:17.620 --> 01:05:19.660
Ich habe das im Blogpost gelesen von

01:05:19.660 --> 01:05:20.560
Toni, der das schrieb.

01:05:21.400 --> 01:05:22.900
Vielleicht ist das richtig, ich weiß es nicht.

01:05:25.400 --> 01:05:26.020
Schöne Grüße.

01:05:26.260 --> 01:05:27.220
Ich sage immer Jason Webtoon.

01:05:28.240 --> 01:05:29.560
Ich sage immer Jason Webtoon.

01:05:32.660 --> 01:05:33.900
Genau, jedenfalls

01:05:33.900 --> 01:05:35.360
ist da die Ansage so,

01:05:35.460 --> 01:05:37.920
das Protokoll ist scheiße, das machen wir nicht.

01:05:38.880 --> 01:05:39.980
Was ist denn die Alternative?

01:05:39.980 --> 01:05:41.540
Jochen. Genau, das ist halt die

01:05:41.540 --> 01:05:43.780
offizielle Alternative, sozusagen

01:05:43.780 --> 01:05:45.540
jedenfalls, so wie es

01:05:45.540 --> 01:05:47.460
in dem offiziellen Django

01:05:47.460 --> 01:05:49.700
Podcast, Django Chat von

01:05:49.700 --> 01:05:51.480
Carlton Gibson, einem der offiziellen

01:05:51.480 --> 01:05:52.220
Django-Maintenner.

01:05:53.520 --> 01:05:55.220
Der übrigens ein total netter Kerl ist.

01:05:55.220 --> 01:05:55.900
Der ist total nett, ja.

01:05:57.200 --> 01:05:59.460
Sometimes pronounced Jot, sagt Wikipedia.

01:05:59.860 --> 01:06:01.000
Sometimes pronounced.

01:06:01.700 --> 01:06:03.480
Sometimes pronounced. Ich versuche es dann mal

01:06:03.480 --> 01:06:04.420
jedes dritte Mal zu machen.

01:06:07.640 --> 01:06:08.980
Genau, der sagt halt.

01:06:09.040 --> 01:06:10.780
hier im Rheinland sagt man doch JWT.

01:06:11.840 --> 01:06:13.100
JWT, JWT.

01:06:13.700 --> 01:06:14.740
Egal, ja.

01:06:15.580 --> 01:06:17.060
Es ist noch immer

01:06:17.060 --> 01:06:18.340
Jotje-Jange oder so, ne?

01:06:19.040 --> 01:06:21.160
Es gibt doch so andere Token-Typen auch noch,

01:06:21.220 --> 01:06:23.060
oder? Ich vergesse nicht, wie die heißen.

01:06:23.280 --> 01:06:25.140
Paseto zum Beispiel. Paseto,

01:06:25.300 --> 01:06:27.040
genau, danke. Aber das ist ja genau das Gleiche.

01:06:27.140 --> 01:06:29.260
Aber du wolltest gerade irgendwas aus dem Django-Tet-Talk erzählen.

01:06:29.380 --> 01:06:30.820
Genau, genau. Also da

01:06:30.820 --> 01:06:32.480
war halt sozusagen die Ansage, na,

01:06:32.860 --> 01:06:35.320
nimm doch einfach die normale Session-Authentication.

01:06:36.200 --> 01:06:36.900
Die ist halt so ein bisschen

01:06:36.900 --> 01:06:38.940
unkomfortabel und so, aber

01:06:38.940 --> 01:06:41.700
auch nicht so arg, ganz ehrlich.

01:06:41.960 --> 01:06:43.440
Ja, so arg unkomfortabel.

01:06:43.740 --> 01:06:45.680
Ja, aber wenn man doch, also, ja, wenn man

01:06:45.680 --> 01:06:47.620
irgendwie kann, das, was man in Python

01:06:47.620 --> 01:06:49.660
macht, kann die Dot-Bibliothek nicht einfach sagen,

01:06:50.040 --> 01:06:51.720
nee, ich bin nicht downgradebar, also ist das nicht

01:06:51.720 --> 01:06:53.180
da schon mit drin? Also das muss ja dann,

01:06:54.360 --> 01:06:56.640
ja doch, kannst du schon,

01:06:56.640 --> 01:06:58.760
aber das Problem ist, du weißt ja nicht,

01:06:58.860 --> 01:07:00.560
mit welchen Clients du redest. Ja, aber wenn

01:07:00.560 --> 01:07:02.600
der Client das gar nicht sagen kann, weil meine Bibliothek das gar

01:07:02.600 --> 01:07:04.700
nicht zulässt, dann. Ja, dann bist du inkompatibel.

01:07:05.200 --> 01:07:06.140
Dann sagen die Clients,

01:07:06.940 --> 01:07:08.560
mit der API kann ich nicht reden, kaputt.

01:07:08.940 --> 01:07:10.280
Ja, gut, kann ja sein.

01:07:11.040 --> 01:07:12.660
Aber den kleinen, den kann ich ja quasi selber sagen.

01:07:13.460 --> 01:07:14.400
Kannst du machen, Dominik.

01:07:14.540 --> 01:07:15.400
Kannst du machen.

01:07:15.580 --> 01:07:17.080
Dann kann man es mit Job machen.

01:07:17.240 --> 01:07:19.480
Dann kann man dabei bleiben, da muss man nicht sagen, oh nein.

01:07:20.680 --> 01:07:21.880
Ja, aber wenn ich den kleinen selber ausliefer,

01:07:22.140 --> 01:07:23.900
also das JavaScript beispielsweise,

01:07:24.060 --> 01:07:25.540
was dann mit meinem Backend reden soll

01:07:25.540 --> 01:07:27.180
und ich selber bestimmen kann, was da drin steht,

01:07:27.240 --> 01:07:28.620
dann kann doch nicht einfach irgendwer sagen,

01:07:28.720 --> 01:07:30.020
dass er jetzt einen anderen Standard dafür nehmen will.

01:07:30.480 --> 01:07:32.760
Dann kannst du aber auch die Session-Authentifizierung nehmen,

01:07:32.880 --> 01:07:34.520
weil da hast du ja nicht viel gewonnen.

01:07:36.140 --> 01:07:38.400
Außer, dass du jetzt selber immer die Authentifizierung

01:07:38.400 --> 01:07:40.360
in jeden Request reintun musst, weil der Browser das

01:07:40.360 --> 01:07:42.340
nicht automatisch macht. Ja, aber bei Session

01:07:42.340 --> 01:07:44.360
habe ich ja noch andere Probleme, glaube ich.

01:07:46.320 --> 01:07:46.640
Ja.

01:07:47.680 --> 01:07:48.000
Ja.

01:07:48.820 --> 01:07:50.420
Dann kann ja jemand so tun, dass wer meine Session

01:07:50.420 --> 01:07:51.540
klauen will oder sowas und dann

01:07:51.540 --> 01:07:53.840
Ja, kann er machen, aber

01:07:53.840 --> 01:07:55.860
das verhindert der Browser.

01:07:57.260 --> 01:07:58.140
Ja, aber ja, egal.

01:07:59.100 --> 01:08:00.480
Es ist kompliziert.

01:08:00.580 --> 01:08:02.620
Das mit der Authentifizierung ist auch noch nicht so richtig abschließend.

01:08:03.420 --> 01:08:04.620
Ich bin überrascht

01:08:04.620 --> 01:08:06.380
immer, ich habe mich da schon ein paar Mal Gedanken

01:08:06.380 --> 01:08:07.620
gemacht und ich war immer überrascht,

01:08:08.240 --> 01:08:10.940
dass es da keine einfache fertige Antwort gibt.

01:08:10.940 --> 01:08:12.040
Wie wenig gelöst es ist.

01:08:12.120 --> 01:08:13.400
Sondern, dass man immer denkt so,

01:08:13.440 --> 01:08:14.380
oh, ich habe die Antwort gefunden

01:08:14.380 --> 01:08:17.440
und dann irgendwie ein paar Monate, Jahre später

01:08:17.440 --> 01:08:18.540
kommt einer um die Ecke und sagt,

01:08:18.600 --> 01:08:19.240
was machst du denn da?

01:08:19.280 --> 01:08:20.460
Das ist doch totaler Quatsch.

01:08:21.520 --> 01:08:23.140
Das machen wir schon seit Jahren nicht mehr.

01:08:23.240 --> 01:08:24.480
Seit Jahren machen wir das nicht mehr.

01:08:25.340 --> 01:08:25.660
Genau.

01:08:26.180 --> 01:08:27.080
Und dann denkt man sich immer so,

01:08:27.180 --> 01:08:28.100
oh, okay.

01:08:30.100 --> 01:08:31.260
Ich glaube, ich brauche Hilfe.

01:08:32.140 --> 01:08:33.660
Okay, Authentifizierung über REST.

01:08:33.660 --> 01:08:34.820
Es ist erstaunlich ungelöst.

01:08:35.560 --> 01:08:36.740
Es ist erstaunlich ungelöst.

01:08:37.020 --> 01:08:38.280
Ja, REST ist ja erst mal

01:08:38.280 --> 01:08:40.240
keine, ist ja erst mal nur eine ganz normale

01:08:40.240 --> 01:08:42.240
HTTP-Webseite. Also du kannst Authentifizierung

01:08:42.240 --> 01:08:43.800
machen mit allen Mechanismen, die du da

01:08:43.800 --> 01:08:45.400
oder halt auch nicht. Ich meine,

01:08:46.020 --> 01:08:47.920
wir haben auch, wir haben früher alle die Webseiten

01:08:47.920 --> 01:08:50.240
gesehen, die die PHP-Session-It

01:08:50.240 --> 01:08:52.300
die die PHP-Session-It

01:08:52.300 --> 01:08:54.040
als Get-Parameter drin hatten und

01:08:54.040 --> 01:08:58.040
ja, durfte man halt nicht

01:08:58.040 --> 01:08:58.680
kopieren.

01:09:00.220 --> 01:09:01.740
Dann durfte man halt die Links nicht verschicken, ne?

01:09:02.440 --> 01:09:02.680
Ja.

01:09:03.400 --> 01:09:05.780
Ja, wie macht man denn sonst noch

01:09:05.780 --> 01:09:07.600
Rest-APIs mit Python.

01:09:07.700 --> 01:09:08.800
Genau, also ja,

01:09:09.800 --> 01:09:11.900
General REST-Fanwork, schöne Sache.

01:09:13.360 --> 01:09:13.760
Ich glaube,

01:09:13.860 --> 01:09:15.820
in der Flask, ich weiß jetzt wahnsinnig

01:09:15.820 --> 01:09:17.880
gar nicht mehr, wie man das ausspricht, vielleicht spricht man das auch J aus.

01:09:18.560 --> 01:09:19.720
Nein, Flask.

01:09:20.040 --> 01:09:21.120
Ich weiß es nicht genau.

01:09:21.460 --> 01:09:22.800
Ich spreche alle Sachen immer falsch aus.

01:09:23.860 --> 01:09:24.680
Flaske, Jochen.

01:09:24.880 --> 01:09:25.320
Flaske.

01:09:26.720 --> 01:09:27.160
Jaisson.

01:09:28.780 --> 01:09:29.620
Jaisson, ja, oui.

01:09:32.460 --> 01:09:34.580
Genau, da verwendet man eher Marshmallow,

01:09:34.680 --> 01:09:35.920
Das gibt es auch für Django,

01:09:36.340 --> 01:09:38.140
aber da verwenden wir es

01:09:38.140 --> 01:09:39.460
in Django Rest Framework.

01:09:41.000 --> 01:09:42.240
Ist so ähnlich.

01:09:42.320 --> 01:09:43.260
Was ist das jetzt wieder? Marshmallow?

01:09:43.600 --> 01:09:45.800
Das ist auch eine Bibliothek, so ähnlich wie Django Rest Framework,

01:09:45.920 --> 01:09:47.960
aber im Grunde, ja. Endpunkte.

01:09:48.580 --> 01:09:49.560
Benutzt man denn noch Flask, Jochen?

01:09:50.060 --> 01:09:52.180
Ja, aber genau, da wäre Hot Take.

01:09:53.700 --> 01:09:54.500
Ich würde ja sagen,

01:09:55.800 --> 01:09:56.620
so,

01:09:56.780 --> 01:09:58.240
jetzt habe ich ja etwas ganz Gemeines.

01:09:59.100 --> 01:09:59.520
Oh, oh, Jochen,

01:09:59.520 --> 01:10:01.640
jetzt machst du die Tore

01:10:01.640 --> 01:10:02.460
für Flameworks auf.

01:10:03.280 --> 01:10:06.040
Der einzige Grund, Flask noch zu

01:10:06.040 --> 01:10:07.980
verwenden, ist ja so im Grunde, aus meiner Perspektive,

01:10:08.080 --> 01:10:09.580
ich kenne mich auch nicht wirklich mit Flask aus, aber

01:10:09.580 --> 01:10:11.820
wenn man alte Python-Versionen hat,

01:10:11.900 --> 01:10:13.960
weil, ja, das geht

01:10:13.960 --> 01:10:15.540
mit Flask und vielleicht mit anderen Sachen nicht.

01:10:16.360 --> 01:10:17.300
Aber wenn man jetzt

01:10:17.300 --> 01:10:19.900
größer Python 3.6 unterwegs ist, warum

01:10:19.900 --> 01:10:21.680
Flask? Warum nimmt man dann nicht sowas wie FastAPI?

01:10:22.820 --> 01:10:23.860
Also, Meinung

01:10:23.860 --> 01:10:25.420
Weil ich dir so eine API schreiben will.

01:10:25.500 --> 01:10:27.840
Hallo at PythonPodcast.de, da könnt ihr gerne

01:10:27.840 --> 01:10:29.720
eure Kommentare oder ein paar Aspray

01:10:29.720 --> 01:10:32.080
an uns kommentieren,

01:10:32.240 --> 01:10:34.400
jederzeit erwünscht hinterlassen. Machen wir

01:10:34.400 --> 01:10:36.380
mal so eine Episode, wo wir die vorlesen einfach.

01:10:36.980 --> 01:10:38.400
Die Mail? Ja, das Problem

01:10:38.400 --> 01:10:40.340
ist, die ist dann aber keine zwei Stunden

01:10:40.340 --> 01:10:40.560
lang.

01:10:42.360 --> 01:10:43.760
Ja, außerdem wollen wir ja nicht,

01:10:44.540 --> 01:10:46.240
ja, es sind ja immer viele nette Nachrichten,

01:10:46.340 --> 01:10:48.300
da freuen wir uns immer. Es gibt ein sehr

01:10:48.300 --> 01:10:50.500
schönes Buch von einem Science-Fiction-

01:10:50.500 --> 01:10:52.380
Autoren, das heißt Your Hate Mail Will Be

01:10:52.380 --> 01:10:54.480
Graded, wo er

01:10:54.480 --> 01:10:56.020
einfach Post,

01:10:56.280 --> 01:10:58.620
Fanpost, sagen wir es mal in Anführungszeichen,

01:10:58.860 --> 01:11:00.300
die an ihn geschickt

01:11:00.300 --> 01:11:02.660
würde, diskutiert.

01:11:03.260 --> 01:11:04.960
Hm, ja.

01:11:06.480 --> 01:11:08.420
Und sowas,

01:11:09.040 --> 01:11:10.060
Jochen, du wirst jetzt sicherlich,

01:11:10.060 --> 01:11:11.720
ihr werdet jetzt, jetzt wo du das gesagt hast,

01:11:11.820 --> 01:11:14.260
das Flask, das umfasst

01:11:14.260 --> 01:11:15.800
ja auch alle anderen alternativen

01:11:15.800 --> 01:11:18.040
APIs, alle

01:11:18.040 --> 01:11:19.740
anderen alternativen Systeme.

01:11:20.260 --> 01:11:21.660
CherryPi, Pyramid,

01:11:22.220 --> 01:11:24.060
Ripos, Soap.

01:11:24.760 --> 01:11:26.100
Gab ja eine neue

01:11:26.100 --> 01:11:28.080
Version, Pyramid 2.0, voll gut.

01:11:28.400 --> 01:11:30.040
Nee, ich weiß es ehrlich gesagt gar nicht so

01:11:30.040 --> 01:11:32.040
genau, was FastPyramid, ich weiß, die gibt es

01:11:32.040 --> 01:11:32.800
alle und so.

01:11:34.160 --> 01:11:35.800
Manche davon können bestimmt auch voll coole Sachen.

01:11:36.020 --> 01:11:36.940
Bei Soap, ja.

01:11:39.540 --> 01:11:40.100
Ja, das

01:11:40.100 --> 01:11:41.500
war mal voll groß und so, aber

01:11:41.500 --> 01:11:43.720
ja, vielleicht ist es auch voll cool.

01:11:44.260 --> 01:11:45.880
Es gibt noch Bottle oder sowas, ist das nicht auch?

01:11:45.940 --> 01:11:47.960
Das ist super. Ja, Bottle, ja. Bottle gibt's.

01:11:48.120 --> 01:11:49.300
Es ist super klein.

01:11:51.160 --> 01:11:51.980
Ja, das ist kleiner

01:11:51.980 --> 01:11:53.880
als Flask, deshalb heißt es ja so.

01:11:54.240 --> 01:11:54.360
Ja.

01:11:56.200 --> 01:11:57.680
Aber ich meine,

01:11:58.020 --> 01:11:59.920
tatsächlich FastAPI würde ich jetzt aus meiner

01:11:59.920 --> 01:12:01.760
Perspektive, es macht im Grunde das, was Fast macht.

01:12:01.940 --> 01:12:03.900
Mehr oder weniger. Hat auch, also ich weiß

01:12:03.900 --> 01:12:06.000
jetzt nicht im Vergleich zu Fast, aber hat mehr Stars bei GitHub.

01:12:06.080 --> 01:12:07.340
Auf jeden Fall als Bottle. Na, super.

01:12:09.220 --> 01:12:10.160
Ja, aber das ist doch,

01:12:10.260 --> 01:12:11.800
also Fast-API ist doch wirklich nur

01:12:11.800 --> 01:12:13.640
für APIs gedacht, oder? Nee,

01:12:13.800 --> 01:12:15.560
du kannst, also ich hab damit auch schon Webseiten, du kannst,

01:12:16.000 --> 01:12:17.800
das Problem, also ja, ist gedacht,

01:12:17.920 --> 01:12:20.000
aber es geht auch anders. Du kannst da einfach

01:12:20.000 --> 01:12:21.860
Ginger-2-Templates verwenden

01:12:21.860 --> 01:12:24.080
und die Dinger ausliefern, gar kein Problem geht.

01:12:25.580 --> 01:12:25.940
Und

01:12:25.940 --> 01:12:27.600
genau, du musst halt alles... Starlet?

01:12:28.280 --> 01:12:29.800
Genau, Starlet ist halt sozusagen das

01:12:29.800 --> 01:12:31.760
Ding da drunter.

01:12:32.740 --> 01:12:34.160
Die Werbung ist on par

01:12:34.160 --> 01:12:35.380
mit Node.js and Go.

01:12:36.300 --> 01:12:36.560
Ja.

01:12:37.500 --> 01:12:40.140
Ja, das besprechen wir

01:12:40.140 --> 01:12:40.660
in der Benchmark.

01:12:43.380 --> 01:12:44.200
War das wieder ein

01:12:44.200 --> 01:12:45.440
Benchmark, der legal war?

01:12:45.880 --> 01:12:48.040
Aber du hast halt, aber ja, ich meine, ich mache

01:12:48.040 --> 01:12:49.720
in letzter Zeit schon auch so Dinge mit

01:12:49.720 --> 01:12:52.140
FastAPI und ich finde das super.

01:12:53.200 --> 01:12:53.920
Ich finde gerade

01:12:53.920 --> 01:12:56.120
auch

01:12:56.120 --> 01:12:58.040
die Integration mit Pydentic echt

01:12:58.040 --> 01:12:58.780
nett und

01:12:58.780 --> 01:13:02.320
gut für Daten.

01:13:02.320 --> 01:13:04.740
Alle Leute, die sich damit nicht abfinden wollen, können auch

01:13:04.740 --> 01:13:05.520
bitte an

01:13:05.520 --> 01:13:08.540
welche Willadresse schreiben.

01:13:08.660 --> 01:13:10.300
Hallo, at pythonpodcast.de

01:13:10.300 --> 01:13:12.320
Def0, at fein.

01:13:16.440 --> 01:13:18.640
Aber ich finde, die Syntax ist halt besser.

01:13:18.900 --> 01:13:20.000
Du hast halt da, das ist halt

01:13:20.000 --> 01:13:22.040
nativ Async, direkt alles.

01:13:23.280 --> 01:13:24.240
Die ganzen Geschichten

01:13:24.240 --> 01:13:25.320
sind halt,

01:13:26.560 --> 01:13:28.080
du könntest ja auch quasi in

01:13:28.080 --> 01:13:30.220
Django oder halt in den Serializern Sachen

01:13:30.220 --> 01:13:32.120
mit Type-Annotationen halt sozusagen

01:13:32.120 --> 01:13:33.860
da die Typen festlegen oder so.

01:13:34.480 --> 01:13:36.160
Geht nur nicht, weil das ist halt älter als

01:13:36.160 --> 01:13:38.080
Type-Annotationen, deswegen musste man sich da schon was anderes

01:13:38.080 --> 01:13:39.720
überlegen, ja, in Django mit den Descriptoren.

01:13:41.380 --> 01:13:41.740
Aber

01:13:41.740 --> 01:13:44.060
in FastAPI ist er halt erst ab Python 3.6,

01:13:44.160 --> 01:13:46.240
das heißt, da kann man das halt so machen und dann hat man halt

01:13:46.240 --> 01:13:48.360
das in relativ

01:13:48.360 --> 01:13:50.120
eleganter Syntax ausgedrückt, wo man sonst

01:13:50.120 --> 01:13:51.180
eine Menge schreiben muss.

01:13:52.800 --> 01:13:54.120
Ob es jetzt so schlimm ist, weiß ich auch nicht,

01:13:54.120 --> 01:13:55.860
aber es ist auf jeden Fall irgendwie so ein bisschen erfrischend

01:13:55.860 --> 01:13:57.960
und was man halt auch geschenkt kriegt, ist

01:13:57.960 --> 01:14:01.140
das sind wir auch schon eher beim Restthema,

01:14:01.840 --> 01:14:03.220
ein Frontend,

01:14:03.340 --> 01:14:05.060
das aber nicht so wie bei Django REST

01:14:05.060 --> 01:14:07.180
Framework so ein eingebautes, gerendertes

01:14:07.180 --> 01:14:08.960
Ding ist, sondern das ist halt sozusagen

01:14:08.960 --> 01:14:10.840
Swagger oder halt

01:14:10.840 --> 01:14:12.540
OpenAPI heißt das jetzt irgendwie,

01:14:13.720 --> 01:14:14.180
dass

01:14:14.180 --> 01:14:17.080
sich aus dem Schema

01:14:17.080 --> 01:14:18.700
quasi das Frontend generiert.

01:14:18.860 --> 01:14:20.420
Es ist halt quasi komplett JavaScript, aber

01:14:20.420 --> 01:14:22.680
dem sagt man halt hier, so ist das Schema, dann

01:14:22.680 --> 01:14:24.840
macht es halt ein Frontend dazu, das tatsächlich

01:14:24.840 --> 01:14:26.780
auch so ähnlich ist wie jetzt bei

01:14:26.780 --> 01:14:28.260
Jungle-Rest-Framework.

01:14:29.760 --> 01:14:31.040
Und das funktioniert eigentlich sehr gut.

01:14:31.220 --> 01:14:33.660
Sieht echt gut aus und ist übrigens auch von Sebastian Ramirez,

01:14:33.920 --> 01:14:35.200
der auch Typer gemacht hat.

01:14:35.320 --> 01:14:37.200
Den hatten wir auch schon mal kurz ein, zwei Mal erwähnt.

01:14:37.280 --> 01:14:38.260
Das sind schon interessante Sachen.

01:14:39.500 --> 01:14:41.820
Da gab es doch noch was von dem einen, der Jungle-Rest-Framework

01:14:41.820 --> 01:14:43.640
gemacht hat. Wie hieß es denn gleich noch?

01:14:44.160 --> 01:14:45.400
Ja, das ist ja

01:14:45.400 --> 01:14:47.600
Tom, na, wer heißt

01:14:47.600 --> 01:14:49.340
er noch? Christy.

01:14:49.340 --> 01:14:50.100
Tom Christy, genau.

01:14:51.120 --> 01:14:53.440
Der hat auch

01:14:53.440 --> 01:14:54.440
Starlet gemacht.

01:14:55.580 --> 01:14:56.720
Ah, ist das Starlet?

01:14:56.780 --> 01:14:58.440
Ja, ja. Und wie hieß, wie hieß

01:14:58.440 --> 01:15:00.580
dieses, das hieß Star API oder irgendwie sowas?

01:15:00.960 --> 01:15:02.160
Fast API, meinst du, oder?

01:15:02.840 --> 01:15:04.200
Nee, dieser Standard,

01:15:04.440 --> 01:15:06.420
den er da sich ausgedacht hat. Ach, ich weiß es nicht mehr.

01:15:06.600 --> 01:15:08.480
Ach ja, das gab's auch. Er hat

01:15:08.480 --> 01:15:09.600
auch ein API-Ding gemacht.

01:15:10.360 --> 01:15:12.700
Ja, ja, aber, ja, ob das...

01:15:12.700 --> 01:15:14.000
Das war nur sehr kurzlebig, oder?

01:15:14.540 --> 01:15:16.340
Ja, also jedenfalls habe ich davon dann irgendwann

01:15:16.340 --> 01:15:18.500
nichts mehr gehört. Es war auch eine coole, da waren auch coole Ideen dabei.

01:15:18.600 --> 01:15:20.440
Da war zum Beispiel sowas dabei, wie, dass du dann halt auch

01:15:20.440 --> 01:15:22.340
gleich Kommando-Zeilen-Interface kriegst und so.

01:15:23.120 --> 01:15:24.220
Aber irgendwie...

01:15:24.220 --> 01:15:25.120
Was ist denn jetzt da?

01:15:25.120 --> 01:15:26.640
Das wäre auch schon wieder

01:15:26.640 --> 01:15:28.160
ein super Schwung.

01:15:28.220 --> 01:15:30.500
Das ist das, was FastAPI darunter

01:15:30.500 --> 01:15:31.820
verwendet.

01:15:32.580 --> 01:15:34.260
Das ist quasi von einem Blame-Entwickler, der

01:15:34.260 --> 01:15:36.280
Dango Resprimer gemacht hat und das hat dann

01:15:36.280 --> 01:15:37.440
FastAPI-Benutzung.

01:15:38.860 --> 01:15:39.300
Verstehe.

01:15:40.480 --> 01:15:42.120
Top Christy macht eine Menge coole Sachen.

01:15:43.080 --> 01:15:43.640
Der hat auch

01:15:43.640 --> 01:15:46.360
einen Nachfolger von Requests.

01:15:46.560 --> 01:15:48.480
Die Requests-Bibliothek hat so ein

01:15:48.480 --> 01:15:50.360
HTTPX. Genau.

01:15:50.440 --> 01:15:52.300
Hat so ein bisschen ein Problem. Und zwar

01:15:52.300 --> 01:15:53.620
einmal ist sie so

01:15:53.620 --> 01:15:55.520
slightly unmaintained

01:15:55.520 --> 01:15:57.600
so ein bisschen und

01:15:57.600 --> 01:15:59.780
sie ist auch nicht async

01:15:59.780 --> 01:16:01.300
und zwar auch so gar nicht.

01:16:02.700 --> 01:16:03.740
Und das ist ja

01:16:03.740 --> 01:16:05.200
heutzutage auch so ein bisschen doof, weil

01:16:05.200 --> 01:16:07.120
wenn schon alles async wird, dann will man

01:16:07.120 --> 01:16:09.200
auch so async HTTP-Requests machen

01:16:09.200 --> 01:16:10.960
und das geht halt mit Requests nicht.

01:16:11.980 --> 01:16:13.560
Oder es geht schon, aber

01:16:13.560 --> 01:16:14.520
da muss man halt irgendwie

01:16:14.520 --> 01:16:17.240
sehr unheilige Dinge tun und irgendwie

01:16:17.240 --> 01:16:18.580
das in Threads machen und so.

01:16:19.860 --> 01:16:21.520
Aber es geht halt nicht mit async.io oder so

01:16:21.520 --> 01:16:21.860
einfach.

01:16:23.060 --> 01:16:26.060
Ja, und HTTPX ist aber dann async-fähig

01:16:26.060 --> 01:16:30.340
und hat halt quasi fast die gleiche API wie Requests.

01:16:30.340 --> 01:16:34.000
Also bemüht sich auch quasi die gleiche API zu haben,

01:16:34.140 --> 01:16:35.340
sodass man das halt einfach quasi...

01:16:36.080 --> 01:16:37.060
Man kann es so verwenden, wie man es gewohnt ist.

01:16:37.280 --> 01:16:38.860
Genau, man kann es so verwenden, wie man es gewohnt ist.

01:16:38.920 --> 01:16:41.720
Man verwendet einfach HTTPX anstelle von Requests.

01:16:42.680 --> 01:16:44.660
Ja, auch sehr nett.

01:16:45.140 --> 01:16:48.600
Aber tatsächlich irgendwie ein bisschen langsam manchmal.

01:16:48.880 --> 01:16:49.380
Ich weiß nicht so genau.

01:16:49.680 --> 01:16:51.380
Naja. Ich verwechsel es immer

01:16:51.380 --> 01:16:53.100
mit HTMX.

01:16:54.880 --> 01:16:55.320
Das ist eine

01:16:55.320 --> 01:16:56.540
JavaScript-Bibliothek, die

01:16:56.540 --> 01:16:59.200
Elemente interaktiv macht.

01:16:59.940 --> 01:17:00.900
Ja, das ist auch interessant.

01:17:01.400 --> 01:17:03.240
Aber ich

01:17:03.240 --> 01:17:03.860
verwechsel es immer.

01:17:06.280 --> 01:17:06.680
Ja.

01:17:07.220 --> 01:17:08.220
Genau, also ja.

01:17:09.480 --> 01:17:11.060
Das sind so, ich weiß nicht, ob ihr jetzt noch,

01:17:11.140 --> 01:17:12.960
also Marshmallow, Django REST Framework,

01:17:14.060 --> 01:17:15.100
FastAPI mit

01:17:15.100 --> 01:17:17.040
Swagger Pidentic. Man kann

01:17:17.040 --> 01:17:19.120
dieses Swagger-Interface auch bei anderen APIs, man kann das

01:17:19.120 --> 01:17:21.000
auch mit Django REST-Framework verwenden. Das machen ja auch viele.

01:17:22.100 --> 01:17:22.980
Bei Marshmallow geht das

01:17:22.980 --> 01:17:25.100
bestimmt auch. Ich weiß nicht, gibt es da sonst noch

01:17:25.100 --> 01:17:26.820
Dinge? Ja, das ist doch das, was jetzt OpenA, also

01:17:26.820 --> 01:17:29.040
dieses OpenA-API-Share, was

01:17:29.040 --> 01:17:30.120
dann zu einem Swagger-File.

01:17:32.540 --> 01:17:34.480
Das ist da auch verlinkt. Ja, aber

01:17:34.480 --> 01:17:37.020
jetzt, um sozusagen mal noch einen Schritt weiter zu gehen,

01:17:37.080 --> 01:17:38.860
Jochen, du hast es ja schon angekündigt

01:17:38.860 --> 01:17:40.960
oder angedeutet, wenn ich jetzt eben

01:17:40.960 --> 01:17:42.320
nicht mehr so ein Interface habe, was

01:17:42.320 --> 01:17:44.060
gut auf diese

01:17:44.060 --> 01:17:46.840
Einzelobjekte passt, um es jetzt mal so zu sagen,

01:17:46.920 --> 01:17:48.500
sondern wenn ich mehr Kontrolle darüber brauche,

01:17:49.120 --> 01:17:52.200
was ich genau abrufe und welche Attribute

01:17:52.200 --> 01:17:53.540
ich abrufe, wie könnte ich das denn

01:17:53.540 --> 01:17:56.140
machen? Ja, genau, da kann man

01:17:56.140 --> 01:17:57.280
dann natürlich sowas nehmen wie

01:17:57.280 --> 01:17:58.580
GraphQL.

01:18:00.500 --> 01:18:02.040
Ja, das ist von

01:18:02.040 --> 01:18:03.520
Facebook, oder? Das ist Facebook, das

01:18:03.520 --> 01:18:06.280
entwickelt im Wesentlichen,

01:18:06.460 --> 01:18:07.660
um genau diesen

01:18:07.660 --> 01:18:09.940
Use Case abzudecken,

01:18:10.040 --> 01:18:11.980
dass man eben Sachen aus diesem Social

01:18:11.980 --> 01:18:13.940
Graph abrufen kann, der

01:18:13.940 --> 01:18:15.740
sich nicht an die Standard-

01:18:15.740 --> 01:18:17.920
Konventionen hält. Ja, sie haben halt im Grunde

01:18:17.920 --> 01:18:19.300
genau das Problem, dass sie halt

01:18:19.300 --> 01:18:21.600
sehr viele unterschiedliche, in sehr vielen

01:18:21.600 --> 01:18:23.740
unterschiedlichen Kontexten halt diese Daten,

01:18:24.400 --> 01:18:25.480
so grafförmige Daten,

01:18:25.640 --> 01:18:27.840
ich meine, da passt halt

01:18:27.840 --> 01:18:29.680
auch normales SQL, man kann ja sonst auch

01:18:29.680 --> 01:18:30.800
normales SQL nehmen,

01:18:31.340 --> 01:18:33.780
aber da passt

01:18:33.780 --> 01:18:35.420
das halt gar nicht so super drauf und dann

01:18:35.420 --> 01:18:37.620
GraphQL passt da besser und

01:18:37.620 --> 01:18:39.940
ja, gut, okay, ist auch wieder

01:18:39.940 --> 01:18:41.820
Ja, ist ja immer

01:18:41.820 --> 01:18:42.980
bei SQL, da hast du immer Sicherheit.

01:18:43.200 --> 01:18:45.520
Ihr habt das kurz übersehen, was war jetzt gerade

01:18:45.520 --> 01:18:46.540
der Joke dahinter?

01:18:47.360 --> 01:18:49.480
Da war ein bisschen tieferer Druck hinter der …

01:18:49.480 --> 01:18:52.420
Jeder Softwareentwickler hat sich schon mal gedacht,

01:18:52.500 --> 01:18:54.440
wisst ihr was, ich mache meine Schnittstelle einfach so,

01:18:54.500 --> 01:18:56.940
dass ich SQL-Strings hinschicke und dann das Ergebnis zurückschicke.

01:18:57.200 --> 01:18:59.420
Und das ist super genial, weil das ist für die Entwickler

01:18:59.420 --> 01:19:01.060
genau das, was die Entwickler haben wollen.

01:19:01.760 --> 01:19:04.960
Nur hast du damit halt … Sicherheit kannst du vergessen.

01:19:05.140 --> 01:19:06.980
Du hast keine Sicherheitsabfragen.

01:19:07.580 --> 01:19:08.720
Mit SQL kannst du alles machen.

01:19:09.860 --> 01:19:10.480
Ja, ja.

01:19:10.760 --> 01:19:14.180
Und deshalb macht man das dann doch nicht,

01:19:14.440 --> 01:19:16.060
sondern denkt sich eben so Sprachen aus,

01:19:16.060 --> 01:19:17.440
wie zum Beispiel REST oder GraphQL.

01:19:17.740 --> 01:19:20.120
Ja, genau. Ich weiß gar nicht,

01:19:20.200 --> 01:19:22.100
ob die EdgeDB-Leute noch eine eigene

01:19:22.100 --> 01:19:24.000
Sprache da haben oder ob die

01:19:24.000 --> 01:19:25.300
auch GraphQL...

01:19:25.300 --> 01:19:26.160
Was ist EdgeDB?

01:19:27.940 --> 01:19:29.980
Das sind eigentlich im Grunde die Leute

01:19:29.980 --> 01:19:30.640
hinter Python,

01:19:32.220 --> 01:19:33.900
hinter dieser ganzen Python

01:19:33.900 --> 01:19:34.820
Async-Geschichte,

01:19:36.020 --> 01:19:37.260
hinter Async.io und so.

01:19:38.560 --> 01:19:39.780
Die machen

01:19:39.780 --> 01:19:41.660
ein Ding namens EdgeDB

01:19:41.660 --> 01:19:42.160
und

01:19:42.160 --> 01:19:45.680
ja, es ist

01:19:45.680 --> 01:19:47.460
auch alles Async und so und

01:19:47.460 --> 01:19:49.480
eigentlich ziemlich cool, basiert auf Postgres

01:19:49.480 --> 01:19:50.460
auch, aber

01:19:50.460 --> 01:19:53.380
ich glaube, die hatten auch eine eigene Abfragesprache.

01:19:54.640 --> 01:19:55.380
Also ich dachte nur so,

01:19:55.460 --> 01:19:57.460
das ist vielleicht eventuell eine Konkurrenz zu GraphQL

01:19:57.460 --> 01:19:58.280
oder so, ich weiß nicht genau.

01:19:59.900 --> 01:20:01.340
Vielleicht nochmal ganz kurz zu dem Unterschied,

01:20:01.520 --> 01:20:03.240
also was REST jetzt macht, ist Objekte

01:20:03.240 --> 01:20:05.360
und damit kann man wunderbar Quad machen und das eignet sich super

01:20:05.360 --> 01:20:07.200
für normales Sequel.

01:20:08.100 --> 01:20:09.020
Und GraphQL,

01:20:09.600 --> 01:20:10.580
nein, falsch.

01:20:10.940 --> 01:20:12.080
Nee, da gibt es sowas gar nicht.

01:20:12.080 --> 01:20:13.100
Du kannst bei

01:20:13.100 --> 01:20:15.700
bei REST kannst du halt nicht

01:20:15.700 --> 01:20:17.500
sagen, was du gerne hättest oder du kriegst es halt.

01:20:18.200 --> 01:20:19.840
Genau, es sind immer einzelne Objekte

01:20:19.840 --> 01:20:21.820
und immer ganze Objekte.

01:20:21.860 --> 01:20:23.440
Oder Listen von Objekten oder sowas.

01:20:24.180 --> 01:20:25.320
Ja gut, du kannst halt natürlich

01:20:25.320 --> 01:20:27.660
unterschiedliche URLs machen, die dann unterschiedliche

01:20:27.660 --> 01:20:29.640
Sachen liefern, aber du kannst halt

01:20:29.640 --> 01:20:31.620
jetzt nicht, das wäre halt

01:20:31.620 --> 01:20:32.760
nicht REST-komfort. Eigentlich,

01:20:33.240 --> 01:20:35.580
genau, hat jedes Objekt

01:20:35.580 --> 01:20:37.640
in REST seine eigene URL und

01:20:37.640 --> 01:20:39.640
das höchste der Gefühle ist, dass du halt Listen haben

01:20:39.640 --> 01:20:41.400
kannst, die bestimmte Eigenschaften haben.

01:20:41.480 --> 01:20:48.660
Zum Beispiel entweder alle oder die, die in X verlinkt sind, dass du so Sublisten hast.

01:20:49.240 --> 01:20:57.740
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.

01:20:57.900 --> 01:20:58.480
Und das ist schon so.

01:20:59.340 --> 01:21:00.100
Gar nicht Rest.

01:21:01.080 --> 01:21:03.040
Eigentlich soll das nicht so sein.

01:21:03.040 --> 01:21:07.180
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.

01:21:08.020 --> 01:21:26.780
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.

01:21:27.020 --> 01:21:29.700
Jetzt musst du nochmal kurz erklären, was Hateras ist, das hat nämlich eben niemand verstanden.

01:21:29.940 --> 01:21:33.620
Das sind diese Hypertext, also dass alles über einen Hyperlink erreichbar ist.

01:21:34.240 --> 01:21:37.060
Deswegen nennt man auch Hyper-Serializer beim Dango REST-Framework.

01:21:38.020 --> 01:21:40.320
Hyperlinks, Serializer, genau, ja, das ist ...

01:21:40.320 --> 01:21:42.240
Genau, damit die Links alle korrekt drin sind,

01:21:42.340 --> 01:21:43.280
damit du draufklicken kannst,

01:21:43.700 --> 01:21:46.260
das ist eigentlich einer der Grundsätze,

01:21:46.440 --> 01:21:48.420
dass du sozusagen den AP-Root anklickst

01:21:48.420 --> 01:21:49.980
und da steht dann drin, was es alles gibt

01:21:49.980 --> 01:21:51.000
und dann klickst du da drauf

01:21:51.000 --> 01:21:52.540
und da steht dann drin,

01:21:52.640 --> 01:21:54.080
hier gibt es die Objekte vom Typ so und so

01:21:54.080 --> 01:21:54.960
und dann klickst du da drauf

01:21:54.960 --> 01:21:56.420
und dann kommt ein Objekt vom Typ so und so.

01:21:57.440 --> 01:21:59.080
Dass alles, was es gibt,

01:21:59.180 --> 01:22:00.580
über einen Hyperlink erreichbar ist.

01:22:00.980 --> 01:22:02.760
Und wenn du jetzt so Get-Parameter einführst,

01:22:02.840 --> 01:22:03.960
die Filter haben oder so,

01:22:04.920 --> 01:22:07.440
dann sind die nirgendwo verlinkt.

01:22:07.900 --> 01:22:08.720
Die musst du kennen.

01:22:10.280 --> 01:22:11.320
Und das ist schlecht, weil

01:22:11.320 --> 01:22:13.960
dann ist deine API nicht mehr

01:22:13.960 --> 01:22:16.160
durchsichtig, sondern die ist jetzt

01:22:16.160 --> 01:22:17.960
undurchsichtig geworden.

01:22:18.660 --> 01:22:19.780
Du findest das nicht

01:22:19.780 --> 01:22:20.540
in der API.

01:22:21.400 --> 01:22:23.800
Vielleicht über Options? Kann man sowas

01:22:23.800 --> 01:22:24.520
in die Options schreiben?

01:22:25.720 --> 01:22:28.080
In den Options

01:22:28.080 --> 01:22:29.980
kriegst du eigentlich die Header zurück.

01:22:30.280 --> 01:22:31.640
Da kriegst du eigentlich die Header zurück

01:22:31.640 --> 01:22:33.540
und dann müsstest du dir wieder irgendwelche

01:22:33.540 --> 01:22:35.340
X-Header überlegen,

01:22:35.600 --> 01:22:37.180
die auch nicht standardkonform sind,

01:22:37.400 --> 01:22:39.220
die du auch, von denen du auch

01:22:39.220 --> 01:22:41.060
wissen musst, dass du quasi

01:22:41.060 --> 01:22:42.480
die Header gucken musst, um das zu finden.

01:22:43.320 --> 01:22:45.200
Das, was Django REST Framework da macht,

01:22:45.980 --> 01:22:47.300
ist ja schon eine sehr

01:22:47.300 --> 01:22:49.520
gute Sache, dass du die Dokumentation mitlieferst,

01:22:49.580 --> 01:22:51.000
kannst dir die Dokumentation anschreiben.

01:22:52.580 --> 01:22:53.560
In einem Swagger-File

01:22:53.560 --> 01:22:55.260
weiß ich gar nicht, wie das abgebildet werden

01:22:55.260 --> 01:22:56.800
würde. Ich glaube, da gibt es auch eine Möglichkeit,

01:22:56.980 --> 01:22:57.920
Parameter zu definieren.

01:22:59.400 --> 01:23:00.820
Aber es ist eben nicht mehr

01:23:00.820 --> 01:23:03.180
in der API selber drin, sondern es geht

01:23:03.180 --> 01:23:05.020
über die API hinaus. Und das ist

01:23:05.020 --> 01:23:06.800
eigentlich nicht was, was man möchte. Es ist nicht

01:23:06.800 --> 01:23:08.920
erfahrbar. Gut, aber das ist ja schon wieder

01:23:08.920 --> 01:23:10.860
jetzt sowas, wo es halt regnet und

01:23:10.860 --> 01:23:12.980
du willst halt, jeder möchte irgendwelche

01:23:12.980 --> 01:23:14.940
Dinge filtern. Ja klar und

01:23:14.940 --> 01:23:16.840
deshalb hat da jede REST

01:23:16.840 --> 01:23:19.000
API auch sowas. Aber es ist eben

01:23:19.000 --> 01:23:20.880
nicht offensichtlich. Wenn du die zum ersten Mal benutzt, dann

01:23:20.880 --> 01:23:22.720
weißt du nicht, dass es da ist.

01:23:22.860 --> 01:23:24.440
Du findest es eventuell erst, wenn du sie

01:23:24.440 --> 01:23:26.940
fünf Jahre lang benutzt hast. Und das

01:23:26.940 --> 01:23:27.660
ist eigentlich nicht gut.

01:23:30.920 --> 01:23:32.940
Und GraphQL ist jetzt wieder so ein kleines bisschen

01:23:32.940 --> 01:23:34.980
einen Schritt in Richtung Remote Procedure Call,

01:23:35.160 --> 01:23:36.120
wo du eben nicht sagst,

01:23:36.940 --> 01:23:38.200
gib mir folgendes Objekt, sondern

01:23:38.200 --> 01:23:41.040
es ist mehr so, führe bitte folgende Abfrage

01:23:41.040 --> 01:23:41.380
aus.

01:23:43.200 --> 01:23:44.920
Du hast halt eine Schritte von Objekten, die in

01:23:44.920 --> 01:23:46.860
einer Kette liegen. Du hast halt

01:23:46.860 --> 01:23:48.820
auch nicht eine URL für die unterschiedlichen Geschichten,

01:23:48.960 --> 01:23:51.020
sondern du hast halt eine URL,

01:23:51.420 --> 01:23:52.800
an die alles geht. Und

01:23:52.800 --> 01:23:54.380
es gibt nicht mehr Delete,

01:23:54.600 --> 01:23:55.500
Pad, Putsch,

01:23:55.600 --> 01:23:58.620
Putsch, der

01:23:58.620 --> 01:24:00.080
mächtigste aller

01:24:00.080 --> 01:24:02.880
Aber auch

01:24:02.880 --> 01:24:03.680
sehr teuer.

01:24:05.820 --> 01:24:06.540
Funktioniert nicht immer.

01:24:08.880 --> 01:24:09.280
Genau.

01:24:10.520 --> 01:24:10.860
Es gibt

01:24:10.860 --> 01:24:12.800
eben diese ganzen Werben nicht. Es gibt nur

01:24:12.800 --> 01:24:14.320
Post. Das war's.

01:24:14.320 --> 01:24:16.360
Und ja, das ist natürlich

01:24:16.360 --> 01:24:20.480
Ja. Hat andere Vor- und Nachteile.

01:24:20.520 --> 01:24:22.280
Ja, es hat halt andere Trade-Offs

01:24:22.280 --> 01:24:24.200
irgendwie. Okay, also

01:24:24.200 --> 01:24:26.520
ich kann aber dann tiefer reingucken

01:24:26.520 --> 01:24:28.040
und bekomme

01:24:28.040 --> 01:24:30.260
andere, deutlich fokussiertere

01:24:30.260 --> 01:24:32.060
Daten schneller

01:24:32.060 --> 01:24:34.020
oder, worum geht es bei der Grafik?

01:24:34.040 --> 01:24:35.600
Ja, eventuell schneller.

01:24:36.260 --> 01:24:37.540
Insbesondere kannst du es steuern.

01:24:37.900 --> 01:24:40.000
Du kannst sagen, ich habe jetzt in diesem Request

01:24:40.000 --> 01:24:42.040
brauche ich alle Objekte,

01:24:42.240 --> 01:24:44.060
die folgende Eigenschaften haben und

01:24:44.060 --> 01:24:46.160
dazu alle, die folgende Eigenschaften

01:24:46.160 --> 01:24:48.320
haben und davon aber nur das Attribut

01:24:48.320 --> 01:24:49.760
Name. Und

01:24:49.760 --> 01:24:52.460
anstatt, dass du dann halt in deiner Übersichtsliste,

01:24:52.840 --> 01:24:53.940
so wie es bei REST ist, erstmal

01:24:53.940 --> 01:24:55.960
alle abrufen musst, um den Namen anzuzeigen,

01:24:57.620 --> 01:24:57.980
führst du halt

01:24:57.980 --> 01:24:59.920
Designer-Abfrage aus und kriegst die Liste

01:24:59.920 --> 01:25:01.860
der Namen zurück, die du dann direkt anzeigen kannst.

01:25:02.420 --> 01:25:03.840
Also diese GraphQL-Schnittstelle

01:25:03.840 --> 01:25:05.900
ist viel näher an

01:25:05.900 --> 01:25:07.980
so einem Datenbank-Interface

01:25:07.980 --> 01:25:09.860
jetzt ganz

01:25:09.860 --> 01:25:11.720
spezifisch für Graph-Datenbanken

01:25:11.720 --> 01:25:13.660
als es

01:25:13.660 --> 01:25:14.580
REST ist.

01:25:15.640 --> 01:25:17.620
REST ist ja wirklich eigentlich ein Object-Store.

01:25:17.800 --> 01:25:19.960
Mehr dann Sinn, wenn man sowas wie

01:25:19.960 --> 01:25:21.740
ich versuche

01:25:21.740 --> 01:25:23.260
jetzt mal abstrakt zu

01:25:23.260 --> 01:25:25.460
visualisieren, wolkige

01:25:25.460 --> 01:25:27.920
Datenformen hat als tabellenförmige

01:25:27.920 --> 01:25:30.340
Datenform? Ja, wenn du

01:25:30.340 --> 01:25:32.400
verschachtelte

01:25:32.400 --> 01:25:33.820
Strukturen hast, also wenn du zum Beispiel

01:25:33.820 --> 01:25:35.960
eine Liste von Freunden von Freunden hast

01:25:35.960 --> 01:25:37.840
oder Kommentare, die

01:25:37.840 --> 01:25:39.920
auf Kommentare zeigen, die

01:25:39.920 --> 01:25:41.960
irgendwie in so einer

01:25:41.960 --> 01:25:44.120
Grafenstruktur

01:25:44.120 --> 01:25:46.200
halt irgendwie angeordnet

01:25:46.200 --> 01:25:48.140
sind, weil dann wird es halt mit SQL immer so ein bisschen

01:25:48.140 --> 01:25:49.900
ätzend, das geht auch, aber es ist halt dann,

01:25:50.000 --> 01:25:52.060
da muss man sich dann was einfallen lassen. Also wenn ich

01:25:52.060 --> 01:25:54.000
in SQL jetzt denken würde, wenn ich

01:25:54.000 --> 01:25:56.000
zu viele Following Keys hätte in meinen

01:25:56.000 --> 01:25:56.960
einzelnen Daten.

01:25:57.320 --> 01:26:00.040
Nee, rekursive.

01:26:00.440 --> 01:26:01.980
Genau, wenn du einen Baum hast oder

01:26:01.980 --> 01:26:03.780
einen Grafen im Allgemeinen.

01:26:04.360 --> 01:26:08.040
Was ja schon schwierig ist,

01:26:08.040 --> 01:26:09.560
in der Datenbank abzubilden.

01:26:09.860 --> 01:26:11.340
Das ist gar nicht so einfach, das abzubilden.

01:26:11.340 --> 01:26:14.500
Was sind deine Lieblingsgrafenstrukturen

01:26:14.500 --> 01:26:15.180
in Datenbanken?

01:26:16.200 --> 01:26:17.880
Ich weiß es nicht.

01:26:18.640 --> 01:26:19.340
Ich weiß, dass der

01:26:19.340 --> 01:26:21.740
Auto von FeinCMS

01:26:21.740 --> 01:26:24.340
der Treebird

01:26:24.340 --> 01:26:25.620
ich weiß nicht genau, was...

01:26:25.620 --> 01:26:28.360
Was ich eine ganze Zeit

01:26:28.360 --> 01:26:29.380
gemacht habe, ist Nesse Z.

01:26:30.800 --> 01:26:32.280
Das geht eigentlich ganz gut.

01:26:33.020 --> 01:26:34.420
Aber es ist halt schon

01:26:34.420 --> 01:26:35.680
echt haarig. Also

01:26:35.680 --> 01:26:38.480
das ist schon so...

01:26:38.480 --> 01:26:39.760
Ja, bei

01:26:39.760 --> 01:26:42.040
Matthias Pass sind die

01:26:42.040 --> 01:26:44.340
Abfragen so bescheuert. Das ist schon

01:26:44.340 --> 01:26:45.660
cool, aber die Abfragen sind so blöd.

01:26:46.120 --> 01:26:48.400
Matthias Pass, Entschuldigung, ihr habt jetzt gerade wieder irgendwie...

01:26:48.400 --> 01:26:50.520
Ähm...

01:26:50.520 --> 01:26:52.160
Was habt ihr gesagt?

01:26:53.580 --> 01:26:54.360
Dominik googelt.

01:26:55.100 --> 01:26:57.900
Ja, also die Frage

01:26:57.900 --> 01:26:58.600
ist halt, wie

01:26:58.600 --> 01:27:01.020
bildet man solche Strukturen eigentlich

01:27:01.020 --> 01:27:03.800
in relationalen Datenbanken ab? Und das ist halt nicht so

01:27:03.800 --> 01:27:05.700
einfach. Es gibt halt das grüne

01:27:05.700 --> 01:27:07.320
Buch von Joey Chalko oder so.

01:27:08.740 --> 01:27:09.820
Trees and Hierarchies

01:27:09.820 --> 01:27:11.960
in SQL oder so. Das kann man sich halt durchlesen.

01:27:12.040 --> 01:27:12.960
Da stehen die ganzen Methoden, die man

01:27:12.960 --> 01:27:14.460
da verwenden kann, drin.

01:27:16.340 --> 01:27:17.640
Aber tatsächlich, also das, was

01:27:17.640 --> 01:27:18.680
viele Leute... Und die sind alle schlecht.

01:27:19.540 --> 01:27:21.420
Und die sind alle schlecht. Die sind alle blöd.

01:27:22.040 --> 01:27:38.580
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.

01:27:41.180 --> 01:27:48.020
Und deshalb gibt es ja auch Graph-Datenbanken und eben andere NoSQL-Datenbanken, die dafür besser geeignet sind.

01:27:50.020 --> 01:27:51.280
Ja, und ein klassisches

01:27:51.280 --> 01:27:53.420
Anwendungsbeispiel für sowas, wo man

01:27:53.420 --> 01:27:55.080
das dann halt braucht und wo man Schwierigkeiten mit

01:27:55.080 --> 01:27:57.400
ist halt sowas wie, ja, wenn ich

01:27:57.400 --> 01:27:59.340
jetzt wissen will, was sind denn jetzt alles

01:27:59.340 --> 01:28:01.320
meine Freunde vierten Grades

01:28:01.320 --> 01:28:03.300
oder so, dann wird halt, ist halt

01:28:03.300 --> 01:28:04.700
auf einer Eskalierdatenbank, ist halt kacke.

01:28:04.920 --> 01:28:07.100
War das nicht irgendwie so eine Theorie, die sagte, dass man mit

01:28:07.100 --> 01:28:09.000
allen Freunden oder alle Leute, die in

01:28:09.000 --> 01:28:10.500
Facebook im Moment am spätesten sind?

01:28:10.540 --> 01:28:12.320
Genau, Small World Theorien, ja.

01:28:13.900 --> 01:28:14.180
Sechs?

01:28:14.980 --> 01:28:15.200
Ja.

01:28:16.200 --> 01:28:18.820
Ja, six degrees of separation heißt das.

01:28:18.900 --> 01:28:19.080
Okay.

01:28:20.020 --> 01:28:23.980
Six Degrees of Kevin Bacon heißt es auch, glaube ich, aber das ist noch was anderes.

01:28:25.040 --> 01:28:25.680
Ja, ja, ja.

01:28:27.520 --> 01:28:38.000
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.

01:28:38.320 --> 01:28:57.520
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.

01:28:57.820 --> 01:29:21.360
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.

01:29:21.920 --> 01:29:23.160
Ja, der Client

01:29:23.160 --> 01:29:25.000
ist halt viel

01:29:25.000 --> 01:29:26.920
fetter sein, sozusagen.

01:29:27.520 --> 01:29:28.980
Auch eine nette Geschichte,

01:29:29.260 --> 01:29:31.500
kommt darauf an, welchen Client und welche

01:29:31.500 --> 01:29:33.180
Server man so verwendet, aber man kann halt auch

01:29:33.180 --> 01:29:34.840
sowas machen wie Subscribe,

01:29:35.440 --> 01:29:37.300
dass man halt eine Query, die man eh stellen muss,

01:29:38.560 --> 01:29:39.640
also man muss sie eh hinschreiben,

01:29:39.760 --> 01:29:41.760
weil man ja irgendwie die Daten holt und dann sagt man halt,

01:29:42.360 --> 01:29:43.540
wenn man daran interessiert ist,

01:29:43.600 --> 01:29:45.400
Updates davon reaktiv zu bekommen, dann sagt man

01:29:45.400 --> 01:29:47.500
einfach nur Subscribe und dann

01:29:47.500 --> 01:29:49.280
kriegt man per WebSocket halt Änderungen

01:29:49.280 --> 01:29:51.420
an dem Query-Set, auf das man

01:29:51.420 --> 01:29:53.380
unsubscribed ist. Und dann kann man

01:29:53.380 --> 01:29:55.320
tatsächlich, wenn zwei Leute irgendwie den gleichen Kram

01:29:55.320 --> 01:29:56.900
editieren oder so,

01:29:57.340 --> 01:29:59.500
dann sieht man die Änderung von einem anderen halt direkt oder so.

01:29:59.600 --> 01:30:01.280
Und das ist halt, geht alles automatisch, voll gut.

01:30:02.240 --> 01:30:03.140
Ja, einfach cool.

01:30:03.140 --> 01:30:04.140
Tolle Sachen, ja.

01:30:05.900 --> 01:30:07.200
Ich habe vor einer Weile was

01:30:07.200 --> 01:30:09.160
gefunden, das heißt Graffiti mit

01:30:09.160 --> 01:30:09.680
PH.

01:30:10.940 --> 01:30:13.180
Graffiti.dev, das ist auch ein Link,

01:30:13.280 --> 01:30:15.240
der da rein muss, das mir sehr gut gefallen hat.

01:30:15.380 --> 01:30:16.400
Ich weiß noch nicht,

01:30:16.780 --> 01:30:18.800
wie ich damit zurechtkomme und ob das,

01:30:18.800 --> 01:30:20.320
das ist so ein bisschen

01:30:20.320 --> 01:30:22.320
wie Ruby on Rails. Ruby on Rails hat

01:30:22.320 --> 01:30:23.780
ja früher die ganzen coolen Sachen

01:30:23.780 --> 01:30:26.160
gekonnt, die Django, wo Django

01:30:26.160 --> 01:30:28.160
so ein bisschen langweilig war. Und hier

01:30:28.160 --> 01:30:30.300
ist es jetzt wieder genauso. Das ist so eine Ruby-Bibliothek,

01:30:30.860 --> 01:30:32.220
die so ein bisschen die Brücke schlägt

01:30:32.220 --> 01:30:34.420
zwischen REST und GraphQL.

01:30:35.680 --> 01:30:36.500
Das ist quasi

01:30:36.500 --> 01:30:38.220
REST mit ganz vielen Konventionen,

01:30:38.960 --> 01:30:39.700
sodass du

01:30:39.700 --> 01:30:42.160
daraus so eine Art

01:30:42.160 --> 01:30:44.220
GraphQL machst, mit den Vorteilen von beiden

01:30:44.220 --> 01:30:46.040
Seiten. Du kannst coole Queries

01:30:46.040 --> 01:30:48.040
ausführen, aber hast trotzdem die

01:30:48.040 --> 01:30:49.780
ganzen guten Vorteile.

01:30:50.140 --> 01:30:51.240
Okay, interessant. Mal angucken.

01:30:52.400 --> 01:30:54.000
Ja, aber es ist, alle Beispiele

01:30:54.000 --> 01:30:54.860
sind in Ruby und

01:30:54.860 --> 01:30:57.900
ich habe noch nicht

01:30:57.900 --> 01:30:59.460
gefunden, ob das auch

01:30:59.460 --> 01:31:01.880
in Python oder gar in Django

01:31:01.880 --> 01:31:03.440
geht und das wäre sehr schön.

01:31:04.960 --> 01:31:05.920
Diese Konzepte, die

01:31:05.920 --> 01:31:07.700
da drin sind, haben mir sehr gut gefallen, weil die halt

01:31:07.700 --> 01:31:09.280
sehr viel über Konventionen machen.

01:31:09.700 --> 01:31:11.520
Das ist quasi eine Restriktionstelle mit ganz vielen

01:31:11.520 --> 01:31:13.340
Konventionen.

01:31:14.160 --> 01:31:15.300
Und auch mit ganz vielen,

01:31:15.760 --> 01:31:17.640
wo dann eben Sachen über Datentypen

01:31:17.640 --> 01:31:19.700
laufen. Also hier wird dann

01:31:19.700 --> 01:31:21.680
so eine Ressource definiert,

01:31:21.820 --> 01:31:23.700
die ein Attribut hat, was ein Name ist, was ein String

01:31:23.700 --> 01:31:25.400
ist, der sortable ist, der filterable ist

01:31:25.400 --> 01:31:27.680
und wenn du diese zwei Attribute

01:31:27.680 --> 01:31:29.500
hast, dann weißt du ja schon ganz viel darüber,

01:31:29.660 --> 01:31:31.640
dann weißt du schon ganz viele Operationen, die du da

01:31:31.640 --> 01:31:33.660
machen kannst, was dann eben wieder zurückgeht

01:31:33.660 --> 01:31:34.880
auf das, was der Dominik eben

01:31:34.880 --> 01:31:37.620
angesprochen hat. Man braucht halt

01:31:37.620 --> 01:31:38.960
sortieren und filtern und

01:31:38.960 --> 01:31:41.140
irgendwie muss man das abbilden

01:31:41.140 --> 01:31:43.460
und warum nicht eine gängige Konvention

01:31:43.460 --> 01:31:45.500
machen und das der Ressource mitgeben und

01:31:45.500 --> 01:31:46.160
sagen, okay, hier,

01:31:46.880 --> 01:31:49.520
da steht immer dieses, dass es

01:31:49.520 --> 01:31:51.740
sortierbar ist, ja oder nein, oder dass es beschreibbar

01:31:51.740 --> 01:31:52.460
ist, ja oder nein,

01:31:53.160 --> 01:31:55.540
dann reicht es doch aus,

01:31:55.580 --> 01:31:57.760
das zu wissen. Und das ist quasi so eine Formalisierung

01:31:57.760 --> 01:31:58.180
davon,

01:31:59.120 --> 01:32:01.660
dass du nur noch diese Attribute

01:32:01.660 --> 01:32:03.480
hast und dann ganz viel daraus automatisch

01:32:03.480 --> 01:32:04.480
rausfällt.

01:32:06.160 --> 01:32:07.520
Und das ist ein

01:32:07.520 --> 01:32:08.700
sehr schöner Ansatz, der

01:32:08.700 --> 01:32:11.740
vielleicht meiner Meinung nach auch

01:32:11.740 --> 01:32:13.460
sehr zukunftsweisend ist und

01:32:13.460 --> 01:32:14.600
auch noch nicht weit genug

01:32:14.600 --> 01:32:16.900
überall verfügbar ist.

01:32:17.260 --> 01:32:19.400
Das heißt, du fragst einfach die API und weißt direkt, wie man die

01:32:19.400 --> 01:32:21.840
benutzen kann, ohne dass du weiter...

01:32:21.840 --> 01:32:23.360
Du fragst quasi die

01:32:23.360 --> 01:32:25.380
API nach den Datentypen und aus

01:32:25.380 --> 01:32:27.080
den Datentypen ergeben sich dann Sachen.

01:32:28.960 --> 01:32:29.400
Die

01:32:29.400 --> 01:32:31.320
API gibt dir auch zu den

01:32:31.320 --> 01:32:33.260
Datentypen die Operationen zurück, aber

01:32:33.260 --> 01:32:35.060
wenn da eben zu einem Feld Sortable

01:32:35.060 --> 01:32:37.420
drin steht, dann brauchst

01:32:37.420 --> 01:32:39.200
du ja gar nichts mehr dazu sagen, weil das ist

01:32:39.200 --> 01:32:41.280
eine Standardsache, die jeder braucht und dann kannst

01:32:41.280 --> 01:32:43.120
du einfach sagen, okay, ich weiß jetzt, wie Sortable,

01:32:43.580 --> 01:32:45.180
dass es auf diesem Feld Sortable ist und

01:32:45.180 --> 01:32:47.240
ich weiß, wie Sortable auf diesem, auf

01:32:47.240 --> 01:32:48.360
Feldern generell funktioniert.

01:32:49.360 --> 01:32:51.060
oder auf Feldern vom Typ String funktioniert,

01:32:51.240 --> 01:32:54.480
dann kann ich da einfach diese Sortable-Operation,

01:32:54.880 --> 01:32:56.120
diese Sortier-Operation machen.

01:32:56.320 --> 01:32:58.460
Und das ist so ein bisschen das,

01:32:58.760 --> 01:32:59.900
als ich das zum ersten Mal gelesen habe,

01:33:00.040 --> 01:33:01.760
war das auch so ein Moment, wo ich mir dachte,

01:33:01.900 --> 01:33:03.680
ah, das ist genau das, was beiden fehlt.

01:33:03.820 --> 01:33:06.280
Das ist eigentlich die Vorteile von REST

01:33:06.280 --> 01:33:08.200
und die Vorteile von GraphQL zusammen.

01:33:09.760 --> 01:33:11.720
Leider habe ich es noch nicht realisieren können,

01:33:11.720 --> 01:33:14.420
weil es eben, wie gesagt, so, naja,

01:33:14.500 --> 01:33:18.080
Installation, da steht dann, wie man es bei Ruby installiert,

01:33:18.260 --> 01:33:20.360
Und dann, gut, schade.

01:33:20.840 --> 01:33:23.620
Also in meine Rails-Applikationen

01:33:23.620 --> 01:33:24.980
könnte ich das jetzt sehr leicht reintun.

01:33:26.640 --> 01:33:28.060
Leider habe ich davon keine.

01:33:30.540 --> 01:33:30.980
Tja, tja.

01:33:32.260 --> 01:33:34.640
Ja, schade.

01:33:36.800 --> 01:33:37.720
Hätte jemand Lust,

01:33:37.800 --> 01:33:39.040
ein Open-Source-Projekt anzufangen?

01:33:39.420 --> 01:33:39.620
Oh.

01:33:42.340 --> 01:33:42.620
Ja.

01:33:42.820 --> 01:33:43.240
Lust schon.

01:33:44.000 --> 01:33:46.840
Falls sich Sponsoren für dieses Unternehmen finden,

01:33:47.100 --> 01:33:51.360
Die melden sich bitte bei hallo-at-podcast.de.

01:33:54.520 --> 01:33:57.420
Ich wäre sehr daran interessiert, da einen Sponsor zu finden.

01:33:57.640 --> 01:34:00.000
Ich würde auch meinen üblichen Stundensatz reduzieren,

01:34:00.160 --> 01:34:01.760
selbstverständlich für Open Source Work.

01:34:03.920 --> 01:34:06.280
Bisher habe ich keinen Sponsoren gefunden,

01:34:06.400 --> 01:34:07.220
der das bezahlen könnte.

01:34:07.220 --> 01:34:09.160
Meine Firma ist leider nicht reich genug,

01:34:10.480 --> 01:34:12.320
um sowas Großes anzugehen.

01:34:12.740 --> 01:34:14.220
Aber jemand sollte das machen, absolut.

01:34:16.140 --> 01:34:20.340
Ja, ansonsten, genau,

01:34:20.460 --> 01:34:22.380
ich weiß nicht, auch interessant

01:34:22.380 --> 01:34:24.320
diese Formate, die man

01:34:24.320 --> 01:34:25.100
da übertragen kann.

01:34:27.320 --> 01:34:28.160
Dazu fällt mir

01:34:28.160 --> 01:34:29.500
gerade noch eine

01:34:29.500 --> 01:34:32.140
Geschichte ein. Es gibt da

01:34:32.140 --> 01:34:34.240
so einen Podcast,

01:34:34.360 --> 01:34:35.800
den ich auch immer höre, weil mich dieses,

01:34:35.800 --> 01:34:37.400
im Prinzip dieses Ganze, weil ich

01:34:37.400 --> 01:34:38.300
diese,

01:34:39.020 --> 01:34:41.540
oh Gott, Hölzchen, Stöckchen,

01:34:41.640 --> 01:34:43.460
ich fange mal noch weiter vorne an.

01:34:43.480 --> 01:34:44.460
Wir kennen das von Jochen wieder.

01:34:46.020 --> 01:34:49.460
Python Podcast ist ja sozusagen

01:34:49.460 --> 01:34:51.340
in dem Python-Genre selber gehostet

01:34:51.340 --> 01:34:52.460
und

01:34:52.460 --> 01:34:55.440
ich bin nicht so richtig super zufrieden damit.

01:34:55.580 --> 01:34:57.600
Es funktioniert schon so, aber eigentlich würde mich

01:34:57.600 --> 01:34:58.960
natürlich nicht interessieren, wie man das richtig macht.

01:34:59.460 --> 01:35:01.440
Und da gibt es einen anderen Podcast, nämlich den

01:35:01.440 --> 01:35:02.880
Podlovers Podcast.

01:35:04.460 --> 01:35:04.560
Und

01:35:04.560 --> 01:35:07.500
genau, den höre ich dann, weil da reden Leute

01:35:07.500 --> 01:35:08.840
darüber, wie sie das halt, also

01:35:08.840 --> 01:35:11.180
Podlove ist halt das WordPress-Plugin.

01:35:11.500 --> 01:35:13.500
Das ist quasi ein Meta-Podcast.

01:35:14.500 --> 01:35:15.840
Ein Podcast aus Podcasten, ja.

01:35:16.020 --> 01:35:28.260
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.

01:35:29.540 --> 01:35:52.620
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.

01:35:52.620 --> 01:35:54.540
und jetzt kommen

01:35:54.540 --> 01:35:56.400
Leute wieder auf die Idee, nachdem da

01:35:56.400 --> 01:35:58.200
seit zig Jahren,

01:35:58.420 --> 01:36:00.420
über zehn Jahren, lange nichts

01:36:00.420 --> 01:36:02.540
an den Standards passiert ist, oh, vielleicht können wir

01:36:02.540 --> 01:36:04.040
doch mal was an den Standards machen, weil

01:36:04.040 --> 01:36:06.560
vielleicht will man ja

01:36:06.560 --> 01:36:08.440
auch dann so ein paar Features ändern oder sich

01:36:08.440 --> 01:36:10.380
irgendwie abgrenzen oder, keine Ahnung, cooler sein als die

01:36:10.380 --> 01:36:12.080
anderen. Und es gibt jetzt

01:36:12.080 --> 01:36:14.540
podcastindex.org und so, wo halt

01:36:14.540 --> 01:36:16.220
das sind auch Leute, die das schon ganz lange machen,

01:36:16.620 --> 01:36:18.440
sich halt wieder so überlegen, ob man da nicht

01:36:18.440 --> 01:36:19.920
noch irgendwelche neuen, interessanten Dinge

01:36:19.920 --> 01:36:22.200
statisieren kann und so. Und

01:36:22.200 --> 01:36:23.860
da ging es dann halt auch immer darum,

01:36:25.040 --> 01:36:26.620
okay, die ursprünglichen Standards

01:36:26.620 --> 01:36:28.120
zu Podcasts oder zu Blogs,

01:36:28.460 --> 01:36:30.480
das ist halt alles XML, RSS.

01:36:32.440 --> 01:36:33.740
RSS ist XML? Ja.

01:36:35.500 --> 01:36:36.800
Genau, und

01:36:36.800 --> 01:36:40.100
die Frage wäre halt,

01:36:40.540 --> 01:36:42.180
okay, und dann gab es irgendwie

01:36:42.180 --> 01:36:44.460
die Idee, oh, man könnte ja

01:36:44.460 --> 01:36:46.000
vielleicht auch JSON-Feeds nehmen,

01:36:46.000 --> 01:36:47.940
so heute macht man ja eigentlich

01:36:47.940 --> 01:36:49.100
kein XML mehr so richtig.

01:36:52.200 --> 01:36:54.160
und wäre das nicht

01:36:54.160 --> 01:36:56.320
wäre das

01:36:56.320 --> 01:36:58.460
nicht irgendwie besser und dann war so

01:36:58.460 --> 01:37:00.400
hatte ich so den Eindruck, da waren

01:37:00.400 --> 01:37:02.400
Leute doch, fanden XML eigentlich ganz cool

01:37:02.400 --> 01:37:04.600
und dachten so, ne Jason

01:37:04.600 --> 01:37:06.500
warum denn und lieber XML

01:37:06.500 --> 01:37:08.300
und zum Rest hat man

01:37:08.300 --> 01:37:10.280
dieses Problem ja auch, dass man die Daten irgendwie übertragen muss

01:37:10.280 --> 01:37:12.100
und da habe ich auch so das Gefühl

01:37:12.100 --> 01:37:14.160
XML spielt im Grunde keine Rolle mehr

01:37:14.160 --> 01:37:16.160
so richtig und

01:37:16.160 --> 01:37:17.460
alle machen halt irgendwie JSON

01:37:17.460 --> 01:37:20.220
ich weiß nicht, man könnte es auch als CSV

01:37:20.220 --> 01:37:21.520
machen, hat das jemand schon mal gemacht?

01:37:22.200 --> 01:37:25.940
Also ich müsste mal kurz Gründe nennen, warum es

01:37:25.940 --> 01:37:27.600
überhaupt XML gut sein könnte, dass

01:37:27.600 --> 01:37:29.860
ich habe das nämlich letztens irgendwann mal gehört, dass irgendwer meinte

01:37:29.860 --> 01:37:32.120
oh, XML wird doch eigentlich total unterschätzt

01:37:32.120 --> 01:37:33.880
Ja, also

01:37:33.880 --> 01:37:35.940
weiß ich, also ich

01:37:35.940 --> 01:37:37.520
kann mir vorstellen, wie man auf die Idee kommt

01:37:37.520 --> 01:37:39.900
ich würde das wahrscheinlich nicht sagen

01:37:39.900 --> 01:37:41.840
also ich hatte eigentlich nie eine besonders hohe Meinung von XML

01:37:41.840 --> 01:37:42.880
und

01:37:42.880 --> 01:37:45.900
aber ich kann in gewisser Weise

01:37:45.900 --> 01:37:47.500
verstehen, wie man aus einer theoretischen Perspektive

01:37:47.500 --> 01:37:49.760
sozusagen drauf kommt, dass das eine gute Idee wäre

01:37:49.760 --> 01:37:51.840
weil viele der Probleme, die man sonst hat

01:37:51.840 --> 01:37:52.660
wenn man das nicht macht,

01:37:53.480 --> 01:37:55.920
man ja vielleicht damit lösen könnte.

01:37:56.160 --> 01:37:57.760
Also zum Beispiel eben, wenn man jetzt

01:37:57.760 --> 01:37:59.540
das vergleicht mit sowas wie CSV,

01:37:59.740 --> 01:38:01.520
was früher, also

01:38:01.520 --> 01:38:03.560
wenn man mit CSV Probleme hat,

01:38:03.680 --> 01:38:05.540
dann könnte man denken, dass XML vielleicht eine,

01:38:06.220 --> 01:38:07.960
ja, also man könnte sich vorstellen,

01:38:08.040 --> 01:38:09.740
dass XML vielleicht eine gute Idee ist, wenn man

01:38:09.740 --> 01:38:11.960
jetzt, schon mal vorher so

01:38:11.960 --> 01:38:12.840
Es ist immer eine gute Idee.

01:38:13.440 --> 01:38:15.780
Kann man alles machen. Ja, kann man.

01:38:17.780 --> 01:38:18.180
Tatsächlich,

01:38:18.580 --> 01:38:18.820
aber

01:38:18.820 --> 01:38:21.660
ja, also wenn man jetzt

01:38:21.660 --> 01:38:23.600
vorher, wenn man jetzt irgendwie sowas wie CSV hat und man

01:38:23.600 --> 01:38:25.460
hat jetzt da Probleme, weil irgendwie

01:38:25.460 --> 01:38:27.580
Leute machen komische,

01:38:27.760 --> 01:38:29.580
schreiben da komische Sachen rein und Dinge gehen kaputt,

01:38:29.860 --> 01:38:30.540
dann kann man sich denken so,

01:38:31.560 --> 01:38:32.280
mir reicht's.

01:38:33.360 --> 01:38:35.660
Diese Barbaren, immer was sie da

01:38:35.660 --> 01:38:37.520
für komische Sachen, also tatsächlich, ich habe auch

01:38:37.520 --> 01:38:38.720
ja einige Zeit im

01:38:38.720 --> 01:38:41.540
Import-Export-Geschäft sozusagen von solchen

01:38:41.540 --> 01:38:43.780
Daten verbracht und

01:38:43.780 --> 01:38:45.360
da passieren halt die komischsten Sachen,

01:38:45.520 --> 01:38:47.100
dass halt irgendwie das

01:38:47.100 --> 01:38:49.460
das Encoding wechselt von Zeile zu Zeile,

01:38:49.980 --> 01:38:51.460
dass IDs halt keine IDs

01:38:51.460 --> 01:38:52.740
sind, dass irgendwie

01:38:52.740 --> 01:38:55.260
das Escaping sehr

01:38:55.260 --> 01:38:57.360
kreativ anders ist und das hat halt damit

01:38:57.360 --> 01:38:59.360
zu tun, dass halt da Daten

01:38:59.360 --> 01:39:01.060
aggregiert werden aus unterschiedlichen Datenquellen,

01:39:01.540 --> 01:39:03.040
dass die dann irgendwie nochmal

01:39:03.040 --> 01:39:05.260
als Excel irgendjemandem auf dem Tisch standen

01:39:05.260 --> 01:39:07.240
und der editiert dann fröhlich drin rum, speichert es wieder

01:39:07.240 --> 01:39:08.960
als was anderes und schickt es dann nochmal raus oder so.

01:39:09.980 --> 01:39:11.260
Also da passieren dann wilde Sachen

01:39:11.260 --> 01:39:13.220
und da könnte man sich jetzt denken, oh super,

01:39:13.520 --> 01:39:15.400
nehme ich doch XML, habe ich dieses Problem

01:39:15.400 --> 01:39:17.300
gelöst, weil... Da sind alle Probleme gelöst.

01:39:17.320 --> 01:39:19.340
Da sind alle Probleme gelöst, weil da habe ich ein Schema,

01:39:19.560 --> 01:39:20.840
da steht drin, was das ist

01:39:20.840 --> 01:39:23.360
und wenn da jemand dann Mist macht, dann geht das

01:39:23.360 --> 01:39:25.500
einfach gar nicht. Da steht Spezifikation quasi

01:39:25.500 --> 01:39:26.280
mit in der Datei.

01:39:27.320 --> 01:39:29.380
Ja, ein Schema. In einer anderen Datei.

01:39:29.800 --> 01:39:30.380
Ah ja, genau.

01:39:34.980 --> 01:39:36.480
Und ja,

01:39:37.220 --> 01:39:38.960
tatsächlich ist es aber so,

01:39:39.140 --> 01:39:41.240
ich würde sagen, eben, das klingt

01:39:41.240 --> 01:39:43.220
danach, als wäre das eine Lösung, praktisch.

01:39:43.940 --> 01:39:45.040
Jetzt so aus diesem

01:39:45.040 --> 01:39:48.340
Tages-Import-Export-Geschäft

01:39:48.340 --> 01:39:49.160
mit vielen

01:39:49.160 --> 01:39:52.520
Dateien, die da reinkommen und rausgehen

01:39:52.520 --> 01:39:54.620
und unterschiedlichen

01:39:54.620 --> 01:39:56.260
Anforderungen und komplizierten

01:39:56.260 --> 01:39:58.300
und komischen Systemen dahinter und seltsamen Leuten

01:39:58.300 --> 01:40:00.040
und so, muss ich sagen,

01:40:00.840 --> 01:40:02.160
wir haben dann

01:40:02.160 --> 01:40:03.560
irgendwie, also

01:40:03.560 --> 01:40:06.140
XML und CSV gehabt und wir haben

01:40:06.140 --> 01:40:07.060
immer CSV empfohlen

01:40:07.060 --> 01:40:09.740
und XML hat zu

01:40:09.740 --> 01:40:11.520
vielen fiesen Problemen geführt,

01:40:12.200 --> 01:40:14.040
die ehrlich gesagt schlimmer waren als das, was wir

01:40:14.040 --> 01:40:16.100
mit CSV. Aber nicht die Encodings.

01:40:16.480 --> 01:40:18.040
Nicht die Encodings. Das Encoding war okay, ja.

01:40:18.680 --> 01:40:20.220
Encodings sind gut bei

01:40:20.220 --> 01:40:21.320
XMR. Ja.

01:40:22.660 --> 01:40:24.160
Naja, gut. Manchmal kriegt man

01:40:24.160 --> 01:40:26.080
auch so komische Byte-Order-Marker vorne dran,

01:40:26.180 --> 01:40:27.460
die dann irgendwie auch Sachen kaputt machen.

01:40:27.700 --> 01:40:30.560
Aber, ja,

01:40:31.180 --> 01:40:31.780
tatsächlich,

01:40:32.800 --> 01:40:33.940
aber das Problem ist halt,

01:40:34.020 --> 01:40:35.760
wenn du den Leuten halt

01:40:35.760 --> 01:40:37.340
sozusagen ein, oder

01:40:37.340 --> 01:40:39.020
das wäre sozusagen

01:40:39.020 --> 01:40:41.140
das Ding, was ich

01:40:41.140 --> 01:40:41.440
dazu

01:40:41.440 --> 01:40:46.680
mitgeben wollen würde.

01:40:46.760 --> 01:40:48.120
Und die Anekdote dazu wäre halt,

01:40:49.320 --> 01:40:50.700
wenn man es unmöglich

01:40:50.700 --> 01:40:52.660
macht, dass solche Fehler passieren, dass halt zum

01:40:52.660 --> 01:40:54.600
Beispiel das Encoding pro Zeile sich ändert

01:40:54.600 --> 01:40:56.500
oder so, dann kann es sein,

01:40:56.800 --> 01:40:58.060
dass das dazu führt, dass die

01:40:58.060 --> 01:41:00.280
Fehler schlimmer werden und nicht besser.

01:41:00.820 --> 01:41:02.620
Nämlich, was dann halt tatsächlich passiert, was man

01:41:02.620 --> 01:41:04.580
dann beobachtet, was ist die

01:41:04.580 --> 01:41:06.580
Konsequenz, wenn man das unmöglich macht, dass solche Fehler

01:41:06.580 --> 01:41:07.900
passieren? Naja, dann

01:41:07.900 --> 01:41:10.540
kriegt man halt Dateien, die zwar

01:41:10.540 --> 01:41:12.520
syntaktisch okay sind, aber die semantisch

01:41:12.520 --> 01:41:14.620
halt irgendwie nicht mehr funktionieren.

01:41:14.720 --> 01:41:16.260
Wo dann zum Beispiel Teile einfach fehlen

01:41:16.260 --> 01:41:18.960
oder die leer sind. Die sind ein gültiges XML-Dokument,

01:41:19.260 --> 01:41:20.100
aber es ist halt irgendwie leer.

01:41:20.600 --> 01:41:22.900
Und dann ist halt die Frage, okay, was macht man denn jetzt?

01:41:22.900 --> 01:41:24.640
Oder du hast dann die Fehler

01:41:24.640 --> 01:41:26.500
in den Daten drin. Ich meine, wir haben ja alle schon mal

01:41:26.500 --> 01:41:27.980
diese UTF-8-Steuerzeichen

01:41:27.980 --> 01:41:31.140
überall in Latin-One-Dingern

01:41:31.140 --> 01:41:31.720
drin gesehen.

01:41:32.480 --> 01:41:33.880
Und wenn das jemand reinkopiert, dann

01:41:33.880 --> 01:41:36.300
ist halt so. Und dann kannst du auch nicht mehr viel machen.

01:41:37.300 --> 01:41:37.820
Genau. Und dann

01:41:37.820 --> 01:41:40.380
das ist nämlich der Punkt, wo es dann

01:41:40.380 --> 01:41:42.660
eben, wenn dann Fehler passieren auf einer anderen Ebene

01:41:42.660 --> 01:41:44.880
oder halt so, dass der XML-Parser

01:41:44.880 --> 01:41:46.580
sagt, ja, alles okay, aber

01:41:46.580 --> 01:41:48.700
es ist eigentlich gar nicht okay, dann

01:41:48.700 --> 01:41:50.840
kannst du nicht mehr viel tun. Bei einem CSV,

01:41:51.120 --> 01:41:52.460
wo das, da kann man immer noch was tun.

01:41:52.520 --> 01:41:54.720
Wenn da irgendwie eine Exception fliegt, da kann man die immer noch fangen

01:41:54.720 --> 01:41:56.460
und kann sagen, okay, den Kunden kenne ich.

01:41:56.560 --> 01:41:58.520
Der kann sich nicht einigen,

01:41:58.820 --> 01:41:59.380
ob er da jetzt

01:41:59.380 --> 01:42:01.860
Beton-1 oder UTF-8 oder

01:42:01.860 --> 01:42:04.740
CP-51, weiß ich nicht, dieses Windows-Dings

01:42:04.740 --> 01:42:06.740
da verwendet oder so. Ja, ja, ist schon

01:42:06.740 --> 01:42:08.580
okay, dann probieren wir die mal der Reihe nach durch

01:42:08.580 --> 01:42:10.280
und einer von den Codecs wird schon funktionieren.

01:42:10.380 --> 01:42:28.880
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.

01:42:28.880 --> 01:42:30.860
Naja, das ist eine sehr interessante Beschreibung

01:42:30.860 --> 01:42:32.760
von Christful Degradation.

01:42:33.100 --> 01:42:34.720
Es kommt vielleicht auch drauf an, welche Zeile

01:42:34.720 --> 01:42:35.600
das war, aber

01:42:35.600 --> 01:42:37.720
im Endeffekt, da

01:42:37.720 --> 01:42:40.500
werden Leute nicht wütend oder rufen an,

01:42:40.500 --> 01:42:42.620
deswegen oder so, wenn da eine Zeile nicht okay war.

01:42:43.300 --> 01:42:44.560
Wenn das XML leer war

01:42:44.560 --> 01:42:46.140
und man jetzt raten muss, was passiert ist,

01:42:46.440 --> 01:42:48.460
möchte der Kunde zum Beispiel alle seine Angebote

01:42:48.460 --> 01:42:50.340
löschen, weil man definiert hat,

01:42:50.380 --> 01:42:51.440
wenn das ein leeres Ding ist,

01:42:52.000 --> 01:42:54.060
oder offline schalten,

01:42:54.160 --> 01:42:55.460
dann kann man das tun.

01:42:56.860 --> 01:42:58.460
Das könnte Ärger geben, oder man macht

01:42:58.460 --> 01:43:00.160
es nicht, das könnte auch Ärger geben, weil

01:43:00.160 --> 01:43:02.480
vielleicht wollte er es ja tatsächlich machen. Also man muss halt

01:43:02.480 --> 01:43:04.400
irgendwie dann raten und das ist

01:43:04.400 --> 01:43:06.420
halt doof, weil jede dieser

01:43:06.420 --> 01:43:08.580
Entscheidungen, die man trifft, kann halt potenziell

01:43:08.580 --> 01:43:10.340
entweder bei einem selber zu

01:43:10.340 --> 01:43:11.060
irgendwie

01:43:11.060 --> 01:43:14.260
größeren Problemen und Geldverlust oder beim Kunden

01:43:14.260 --> 01:43:15.940
zu größeren Problemen und Geldverlust führen.

01:43:16.260 --> 01:43:18.420
Und das ist halt schlecht, weil das ist halt nicht so

01:43:18.420 --> 01:43:19.280
richtig gracefully.

01:43:20.160 --> 01:43:20.300
Und

01:43:20.300 --> 01:43:24.300
ja. Das ist so ein bisschen wie

01:43:24.300 --> 01:43:26.520
diese statistische

01:43:26.520 --> 01:43:27.840
interessante Anormalität.

01:43:28.460 --> 01:43:31.600
als man die Helmpflicht für Motorräder eingeführt hat,

01:43:32.420 --> 01:43:35.240
ist die Zahl der Kopfverletzungen gestiegen.

01:43:36.520 --> 01:43:38.300
Und der Grund ist halt einfach,

01:43:38.400 --> 01:43:39.800
dass die Leute, die vorher gestorben sind,

01:43:39.880 --> 01:43:40.780
jetzt Kopfverletzungen haben.

01:43:42.060 --> 01:43:42.620
Ah, okay.

01:43:43.080 --> 01:43:45.140
Und so ein bisschen ist es da halt auch.

01:43:45.320 --> 01:43:48.080
Du schließt die einfachen Fehler aus

01:43:48.080 --> 01:43:51.160
und deshalb kommen jetzt halt die schlimmen Fehler.

01:43:52.220 --> 01:43:54.060
Ja, eine andere Möglichkeit wäre auch noch,

01:43:54.120 --> 01:43:56.200
dass die Leute, die vorher Fahrrad gefahren sind,

01:43:56.200 --> 01:43:57.620
jetzt dann halt irgendwie Autofahren

01:43:57.620 --> 01:43:59.640
und dann die Wahrscheinlichkeit für Kopfverletzungen im Auto steigt

01:43:59.640 --> 01:44:00.020
oder sowas.

01:44:01.460 --> 01:44:03.860
Ja, genau. Viele unabsehbare

01:44:03.860 --> 01:44:05.460
Konsequenzen. Unintended

01:44:05.460 --> 01:44:07.000
Konsequenzen. Externe Effekte.

01:44:09.060 --> 01:44:09.420
Ja.

01:44:10.560 --> 01:44:10.920
Insofern.

01:44:11.540 --> 01:44:13.420
Jetzt haben wir zu viel über XML geredet in der

01:44:13.420 --> 01:44:14.520
Restfolge, ehrlich gesagt.

01:44:15.920 --> 01:44:17.660
Ja, das ist ja nicht ausgeschlossen. Du kannst ja

01:44:17.660 --> 01:44:19.520
wie auch Jungle Rest Framework bietet ja

01:44:19.520 --> 01:44:20.080
den XML

01:44:20.080 --> 01:44:22.980
Sequencer.

01:44:23.460 --> 01:44:24.900
Wer will das denn lesen? Wer will das denn parsen?

01:44:25.000 --> 01:44:27.300
Wer will das denn weiterverarbeiten? Das ist doch alles

01:44:27.300 --> 01:44:29.340
total hässlich und dann... Ja, kann doch sein,

01:44:29.420 --> 01:44:31.040
dass du irgendeinen Client hast, der das halt

01:44:31.040 --> 01:44:33.380
kann er haben. Für Entity and Attributes

01:44:34.020 --> 01:44:35.120
of Attributes of Entities.

01:44:37.260 --> 01:44:38.500
XML hat ja auch Vorteile.

01:44:42.500 --> 01:44:43.240
Zähle uns die doch

01:44:43.240 --> 01:44:44.780
bitte auf, Johannes. Nein.

01:44:48.380 --> 01:44:49.360
Ich weiß,

01:44:49.480 --> 01:44:51.200
dass es welche hat, aber ich will sie jetzt nicht

01:44:51.200 --> 01:44:52.860
sagen, weil ich will niemanden dazu verführen.

01:44:53.260 --> 01:44:53.520
Na gut.

01:44:56.640 --> 01:44:57.000
Ja,

01:44:57.200 --> 01:44:59.520
anderes Format, auf dem man auch noch gut rumhalten

01:44:59.520 --> 01:45:00.340
könnte, wäre Jason.

01:45:02.420 --> 01:45:02.860
Das ist,

01:45:03.340 --> 01:45:05.340
ich meine tatsächlich, ehrlich gesagt, es hat

01:45:05.340 --> 01:45:07.500
auch so diverse Hässlichkeiten

01:45:07.500 --> 01:45:09.260
und so, aber Jason

01:45:09.260 --> 01:45:10.880
funktioniert eigentlich schon. Also,

01:45:11.340 --> 01:45:13.280
das kann man eigentlich auch, also man kann das schon

01:45:13.280 --> 01:45:14.980
nehmen. Es ist nicht so schlimm.

01:45:15.500 --> 01:45:16.980
Ja. Was war denn diese Datumangaben?

01:45:16.980 --> 01:45:18.240
Ich bin ja ein großer Freund von Messagepack.

01:45:18.880 --> 01:45:20.460
Ja, ja. Was ist Messagepack?

01:45:21.740 --> 01:45:23.260
Messagepack ist quasi binäres

01:45:23.260 --> 01:45:25.020
und gepacktes Jason. B-Jason.

01:45:26.200 --> 01:45:26.680
Sagt man das so?

01:45:27.200 --> 01:45:29.940
Ja, bjson ist noch mal was anderes.

01:45:30.520 --> 01:45:32.880
Und es gibt auch bson, also B-S-O-N.

01:45:33.580 --> 01:45:37.060
Das ist Binary Serialized Object Notation oder sowas.

01:45:38.600 --> 01:45:39.640
Ist auch was anderes.

01:45:40.580 --> 01:45:41.940
Das ist das, was in Postgres drin ist.

01:45:42.480 --> 01:45:43.720
Und dann gibt es noch hason.

01:45:44.580 --> 01:45:45.600
Das weiß ich nicht, was es ist.

01:45:45.680 --> 01:45:46.820
Das ist auch in Postgres drin.

01:45:47.960 --> 01:45:50.020
Das ist, glaube ich, die ältere Variante, aber ja.

01:45:50.400 --> 01:45:51.060
Ja, kann sein.

01:45:52.940 --> 01:45:55.500
Ja, MessagePack ist quasi ein Drop-In-Replacement für JSON,

01:45:55.680 --> 01:45:57.840
nur schneller und kleiner.

01:45:58.940 --> 01:45:59.660
Das kann man, glaube ich,

01:45:59.700 --> 01:46:01.740
bei Django REST Framework kann man das auch irgendwie

01:46:01.740 --> 01:46:03.300
mit dazu konfigurieren.

01:46:03.800 --> 01:46:05.640
Ja klar, das ist halt auch

01:46:05.640 --> 01:46:07.720
so ein Standard. Ah, die heißen nicht Serializer,

01:46:07.880 --> 01:46:09.620
sondern heißen irgendwie anders. Das muss man halt

01:46:09.620 --> 01:46:11.620
in der Konfiguration angeben als Klasse und

01:46:11.620 --> 01:46:13.420
die haben ja ihre

01:46:13.420 --> 01:46:15.580
Abfolge und wenn der Client nichts sagt, dann kriegt

01:46:15.580 --> 01:46:17.380
das halt in der richtigen...

01:46:17.380 --> 01:46:19.200
Ich glaube, die heißen irgendwie Renderer oder sowas.

01:46:19.840 --> 01:46:20.580
Ja, das kann sein.

01:46:21.400 --> 01:46:22.600
Früher war das tatsächlich,

01:46:23.160 --> 01:46:25.360
konnte man tatsächlich sehr schöne Dinge machen, weil

01:46:25.360 --> 01:46:27.540
halt Message-Pack-Nachrichten

01:46:27.540 --> 01:46:28.900
kleiner sind als JSON-Nachrichten

01:46:28.900 --> 01:46:31.320
und in einem Mobile-Umfeld war das früher

01:46:31.320 --> 01:46:33.040
ein sehr, sehr wichtiger

01:46:33.040 --> 01:46:35.300
Aspekt, dass man unter

01:46:35.300 --> 01:46:37.120
65 Kilobyte bleibt, weil das eben

01:46:37.120 --> 01:46:39.600
ein Datenpaket

01:46:39.600 --> 01:46:41.000
war, früher, damals,

01:46:41.520 --> 01:46:43.420
als es noch 3G gab

01:46:43.420 --> 01:46:44.480
oder 2G oder was auch immer.

01:46:45.200 --> 01:46:47.060
Und da war Message-Pack richtig, war ein richtiger,

01:46:47.340 --> 01:46:49.280
cooler Vorteil, weil du

01:46:49.280 --> 01:46:50.940
halt nichts machen musstest und trotzdem

01:46:50.940 --> 01:46:52.980
unter den 65K geblieben bist

01:46:52.980 --> 01:46:53.660
normalerweise.

01:46:54.940 --> 01:46:57.000
Und das war damals

01:46:57.000 --> 01:46:58.920
wichtiger. Heutzutage ist es wichtiger, dass es

01:46:58.920 --> 01:47:00.560
lesbar ist, deshalb nimmt man lieber JSON.

01:47:02.480 --> 01:47:02.700
Ja.

01:47:04.080 --> 01:47:04.680
Ja, oder

01:47:04.680 --> 01:47:06.960
andere Leute, die haben direkt komplett

01:47:06.960 --> 01:47:08.920
alle Daten, wenn man nicht viele Daten hat, was man auch

01:47:08.920 --> 01:47:10.900
ganz gut machen kann, dass man zieht einfach alle

01:47:10.900 --> 01:47:11.740
Daten komplett.

01:47:13.020 --> 01:47:15.080
Weil man dann halt auch die Antenne

01:47:15.080 --> 01:47:16.080
nicht so, das ist ja auch sowas,

01:47:16.180 --> 01:47:18.940
Stromverbrauch, wenn man die Antenne

01:47:18.940 --> 01:47:20.720
anschaltet.

01:47:22.220 --> 01:47:22.580
Ja.

01:47:22.980 --> 01:47:24.200
Macht man auch nicht mehr so häufig.

01:47:24.940 --> 01:47:27.700
Ja, eigentlich ist er dran.

01:47:27.900 --> 01:47:30.020
Jetzt haben wir noch, ich meine, jetzt haben wir

01:47:30.020 --> 01:47:32.280
sehr viel über REST gesprochen und über Alternativen.

01:47:33.040 --> 01:47:34.140
Im Grunde ist REST

01:47:34.140 --> 01:47:36.100
ja was ganz Simples. Es ist einfach nur

01:47:36.100 --> 01:47:38.120
die HTTP und

01:47:38.120 --> 01:47:39.920
HTML angewendet, äh nicht HTML,

01:47:40.020 --> 01:47:41.640
HTTP angewendet auf APIs.

01:47:44.480 --> 01:47:44.920
Und

01:47:44.920 --> 01:47:48.020
ja, so sollte man es

01:47:48.020 --> 01:47:49.960
machen. Das wäre, so wäre es gut, wenn man das

01:47:49.960 --> 01:47:50.200
macht.

01:47:51.920 --> 01:47:53.680
Und das ist ja schon

01:47:53.680 --> 01:47:56.400
Oh, eine

01:47:56.400 --> 01:47:59.000
Sache, die ich ganz interessant

01:47:59.000 --> 01:48:00.960
finde, die eventuell nochmal dazu führen

01:48:00.960 --> 01:48:02.460
könnte, dass es halt so ein bisschen Renaissance

01:48:02.460 --> 01:48:04.700
in die Richtung gibt, weil man

01:48:04.700 --> 01:48:06.800
vielleicht kann man Teile von dem, was man jetzt mit GraphQL

01:48:06.800 --> 01:48:08.360
macht, auch dadurch erreichen, dass man

01:48:08.360 --> 01:48:10.460
Endpunkte miteinander kombiniert

01:48:10.460 --> 01:48:12.340
oder irgendwelche Aggregations-Endpunkte macht

01:48:12.340 --> 01:48:14.920
und die dann halt

01:48:14.920 --> 01:48:16.820
per Async, also normalerweise würde man sagen

01:48:16.820 --> 01:48:18.600
so, ja, viele Requests machen

01:48:18.600 --> 01:48:20.660
nicht so cool, weil blockiert halt

01:48:20.660 --> 01:48:22.660
immer einen Worker im

01:48:22.660 --> 01:48:24.620
Applikations-Server, aber wenn man jetzt Async hat, dann

01:48:24.620 --> 01:48:26.560
ist es vielleicht auch egal. Und dann

01:48:26.560 --> 01:48:28.740
kann man sich sozusagen

01:48:28.740 --> 01:48:30.760
seine Ergebnissets auch

01:48:30.760 --> 01:48:33.040
so ein bisschen darüber zusammenbasteln

01:48:33.040 --> 01:48:34.700
und diese Dinge halt Endpunkte

01:48:34.700 --> 01:48:36.800
vielleicht so on the fly generieren oder weiß ich nicht.

01:48:37.660 --> 01:48:37.860
Naja.

01:48:39.820 --> 01:48:40.640
Da gibt es übrigens

01:48:40.640 --> 01:48:42.720
einen Artikel zu, wenn ich jetzt mal da Werbung machen darf.

01:48:43.100 --> 01:48:44.420
Auf deinem

01:48:44.420 --> 01:48:46.260
Blog, Jochen, über diese

01:48:46.260 --> 01:48:48.220
Async-Aggregations-API hast du da

01:48:48.220 --> 01:48:49.600
einen kleinen Beitrag so geschrieben.

01:48:49.820 --> 01:48:50.140
Achso,

01:48:50.260 --> 01:48:53.660
Ja, das ist aber

01:48:53.660 --> 01:48:54.960
sozusagen nur quasi, wenn man

01:48:54.960 --> 01:48:57.420
andere APIs abfragt, das ist natürlich auch

01:48:57.420 --> 01:48:59.400
ein Anwendungsfall für iSync, genau, weil eben man

01:48:59.400 --> 01:49:01.300
dann halt nur auf den, die Zeit,

01:49:01.500 --> 01:49:03.380
die Latenz ist nur die Zeit, die

01:49:03.380 --> 01:49:05.520
der längst laufende Request braucht und nicht mehr,

01:49:05.820 --> 01:49:07.080
wenn man das synchron abfragt, halt

01:49:07.080 --> 01:49:08.880
alle aufsummiert.

01:49:09.460 --> 01:49:11.180
Und genau, aber es wäre ja auch sozusagen,

01:49:11.320 --> 01:49:13.160
wenn diese Dinge, die man

01:49:13.160 --> 01:49:15.260
fragt, interne andere API-Endpoints sind

01:49:15.260 --> 01:49:17.040
und man dann irgendwie noch eine Transformation drauf

01:49:17.040 --> 01:49:18.320
macht und das dann rausschickt, dann...

01:49:18.320 --> 01:49:19.280
Microservices.

01:49:20.780 --> 01:49:20.960
Ja.

01:49:23.940 --> 01:49:24.460
Buzzword.

01:49:24.620 --> 01:49:25.100
Bingo.

01:49:28.100 --> 01:49:28.620
Meine

01:49:28.620 --> 01:49:30.720
Consulting-Kosten

01:49:30.720 --> 01:49:32.020
haben sich eben verdoppelt.

01:49:33.940 --> 01:49:34.820
Ja, wobei

01:49:34.820 --> 01:49:36.900
Microservice-Integration würde

01:49:36.900 --> 01:49:38.480
ich ehrlich gesagt auch nicht unbedingt

01:49:38.480 --> 01:49:40.520
über REST oder

01:49:40.520 --> 01:49:41.320
HTTP machen.

01:49:42.420 --> 01:49:44.040
Ich weiß nicht, wie der das zum Neuesten macht.

01:49:44.200 --> 01:49:46.460
Sondern über was? Wahrscheinlich über eine

01:49:46.460 --> 01:49:47.120
Message-Queue.

01:49:48.320 --> 01:49:51.160
einfach deswegen, weil du dann zum Beispiel

01:49:51.160 --> 01:49:53.080
weil du eben, ja und

01:49:53.080 --> 01:49:54.920
weil du bei HTTP hast du halt diesen Overhead

01:49:54.920 --> 01:49:56.960
immer der Verbindung, die du aufmachen musst und

01:49:56.960 --> 01:49:58.280
den

01:49:58.280 --> 01:50:00.820
Ja gut, dann kriegst du ja mit Techniken weg.

01:50:02.040 --> 01:50:02.980
Ja und intern

01:50:02.980 --> 01:50:05.040
musst du dann vielleicht auch nicht immer authentifizieren und sowas

01:50:05.040 --> 01:50:05.740
aber

01:50:05.740 --> 01:50:07.440
ja

01:50:07.440 --> 01:50:10.820
Ja okay, wie auch immer.

01:50:11.460 --> 01:50:12.840
Darauf müssen wir auch nochmal was anderes sagen.

01:50:13.220 --> 01:50:14.080
Du wolltest noch was anderes sagen?

01:50:15.380 --> 01:50:16.860
Genau, also das wäre halt vielleicht

01:50:16.860 --> 01:50:19.380
ein Ding,

01:50:19.540 --> 01:50:21.080
wie man sozusagen damit

01:50:21.080 --> 01:50:23.040
umgehen könnte, dass

01:50:23.040 --> 01:50:25.500
man ansonsten

01:50:25.500 --> 01:50:27.140
eine Explosion von Endpunkten hat

01:50:27.140 --> 01:50:28.820
und ganz viele Abfragen machen muss,

01:50:29.140 --> 01:50:31.160
wenn man bei REST im Vergleich

01:50:31.160 --> 01:50:33.220
zu UDFDL. Aber

01:50:33.220 --> 01:50:33.720
ja.

01:50:35.880 --> 01:50:36.840
Okay. Keine Ahnung.

01:50:36.900 --> 01:50:37.200
Ja, okay.

01:50:38.600 --> 01:50:41.000
Ich würde sagen, wir haben ziemlich viel bei REST heute gesprochen.

01:50:41.940 --> 01:50:43.120
Habt ihr noch irgendwas auf eurer Liste,

01:50:43.120 --> 01:50:44.940
was ihr noch losen werden wollt heute? Weil sonst würde ich

01:50:44.940 --> 01:50:45.460
nämlich sagen,

01:50:46.860 --> 01:50:50.880
Nee, ich hab sonst auch nichts mehr.

01:50:51.140 --> 01:50:53.060
Ich fand's schön, viel wieder gelernt.

01:50:54.120 --> 01:50:55.220
Ich hoffe, ihr bleibt uns

01:50:55.220 --> 01:50:56.920
weiter gewogen, hört uns weiter und

01:50:56.920 --> 01:50:59.720
schreibt uns eure Fake, eure Lobhass-Kommentare,

01:51:00.280 --> 01:51:01.480
alles, was ihr loswerden

01:51:01.480 --> 01:51:03.920
wollt an hallo.peisenpodcast.de

01:51:03.920 --> 01:51:05.280
Schön, dass ihr

01:51:05.280 --> 01:51:07.200
wieder eingeschaltet habt. Vielen Dank,

01:51:07.260 --> 01:51:09.140
dass ihr wieder alle dabei wart. Vielen Dank, Johannes.

01:51:10.900 --> 01:51:11.300
Und

01:51:11.300 --> 01:51:13.340
ja, hört uns das

01:51:13.340 --> 01:51:15.120
nächstes Mal wieder. Alles klar.

01:51:15.420 --> 01:51:17.060
Bis dann. Bis zum nächsten Mal. Jo, tschüss.

01:51:17.520 --> 01:51:19.160
Wir haben die Pics vergessen. Na, machen wir dann

01:51:19.160 --> 01:51:19.800
heute nicht.

01:51:20.980 --> 01:51:21.640
Tschö, tschö.