Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast Episode 39.
Heute reden wir mit euch über FastAPI.
Hi Jochen.
Ja, hallo, herzlich willkommen Dominik.
Wir sind mal wieder im schönen Wintergarten, es ist noch relativ dunkel draußen heute mal wieder.
Ja.
Ja, und sind schon ganz gespannt, was ihr uns für Feedback gebt an hallo-at-python-podcast.de.
Genau.
Ja, machen wir wie immer so ein bisschen zuerst News oder so.
Heute haben wir auch keinen Gast irgendwie oder so.
und die Programmiersprache Python.
und da haben sich Leute schon viele Gedanken zu gemacht, was man damit machen könnte.
Worum ging es in der App?
Ja, um ein Log-File-Format.
Das gibt es ja, also Log-Files zum Festnageln von...
Also nicht Python-Log-Files.
Ja, mit CK.
Das gibt es ja in diversen...
Also Poetry macht das, PIP-Tools macht das,
aber es gibt keinen Standard dafür und deswegen ist das halt immer ein bisschen schwierig.
und
ja, da war halt die Idee, das mal so
zu standardisieren, zumindest für Binary-Installationen,
weil das geht eigentlich auch nur so
richtig gut für Wheels, weil
bei Source-Distributionen oder so ist halt unklar,
was ist denn jetzt eigentlich der Hash da,
worüber macht man den denn jetzt, also wobei
bei Wheels ist es halt relativ einfach, genau,
und das war der Pep dazu von
Greg Ken, der sich jetzt auch seit einiger
Zeit relativ intensiv da mit diesem ganzen Packaging-Thema
beschäftigt hat und ja, das wäre
halt eine schöne Gelegenheit gewesen, das mal zu standardisieren, aber
wurde abgelehnt.
Wer war nochmal bei Canon?
Aus dem Steering Council und auch
der macht glaube ich eigentlich
ist der so der
verantwortliche VS Code Python
Integration bei Microsoft, aber
der ist eine ganz bekannte
Figur da in der Python
Entwicklungsszene. Und weißt du auch noch, warum das
abgelehnt worden ist? Ja, weil es
eben keine Source-Distribution irgendwie
mit umfasst und du kannst halt damit dann
nur Sachen, wo es ein Wheel gibt,
und dann ist halt irgendwie viele
sagen, das bringt dann nicht so viel
und ach ja,
naja, mal schauen, vielleicht mal sehen, wie das
da so weitergeht. Vielleicht denkt sich
irgendjemand aus, wie man auch Source-Sachen
hashen kann oder so?
Ja, oder vielleicht gibt es da mal was ganz anderes, keine Ahnung.
Mal abwarten, das ist Packaging-Problem.
Man könnte ja den Source in einen Zip
runterladen, den Zip hashen und dann
entpacken.
Naja, also
ist es nicht so einfach.
Ja,
Nächste News
Nächste, was sehr schön ist
WebAssembly
WebAssembly, C-Python, kompiliert
komplett nach
also das ist wirklich das richtige C-Python
nicht irgendwie kompiliert nach WebAssembly
und kann man im Browser ausführen
also es gehen da natürlich noch viele Dinge noch nicht
aber dass das überhaupt
klappt, ist halt schon mal irgendwie
sehr interessant und
dann kann man tatsächlich
Python schreiben, in C-Python kompilieren
und dann einfach im Browser laufen
der kompiliert mal nichts.
C-Python ist der Interpreter von Python.
Der ist nach WebAssembly, das heißt,
der läuft dann sozusagen im Browser zum Beispiel
oder auf irgendwas, was halt WebAssembly ausführen kann.
Und dann kannst du da einfach
Python hinschicken und dann kann das das ausführen.
Das heißt, du schickst da quasi vom Server
Python Source-Files
an den Browserskunden und das wird dann...
Ja, der könnte das ausführen.
Ist natürlich so,
die ganze Umgebung und so, das ist natürlich
dann nicht so wirklich wie
normalerweise.
System, ja, du musst halt mit rechten
Beschränkungen klarkommen, die es dann wahrscheinlich gibt.
Ja, und noch diverse andere Geschichten, du kannst ja auch nicht irgendwelche Sachen
installieren und so, aber, und irgendwie
C-Extensions und so, das geht wahrscheinlich alles nicht, aber
dass das überhaupt geklappt hat,
ist schon mal...
Es wird klar, was du halt endlich wegschmeißt.
Nee, also das...
Das aber,
aber es ist halt auf jeden Fall ein Ding,
was dazu führen kann, dass
man da eventuell
nicht in so ein Aussterbeproblem läuft,
weil halt alles irgendwann im Browser ist und so.
dann kann man da vielleicht auch sein oder so.
Was ist so ein Use Case von so WebAssembly
Zeugs?
Ja, zum Beispiel eben
im Browser halt laufen, aber auch
eventuell in Zukunft irgendwann wird es halt
vielleicht auch so sein, dass Telefone oder so
das halt irgendwie nativ ausführen.
Ich meine auch
also unter
iOS oder die iPhones, die haben ja
da ist halt ganz viel optimierter
Kram auch für JavaScript schon
drin, aber auch für WebAssembly ist es halt
ja
also da sozusagen das so zu machen, dass man
da den Kram halt auch irgendwie ausführen kann,
das wäre eigentlich relativ einfach. Das heißt, der macht dann direkt
dein Telefon mit die Datenanalyse live
auf dem Gerät direkt oder sowas? Ja, aber man könnte sagen,
also das kann halt auch WebAssembly
ausführen. Also momentan zum Beispiel, wenn
du für iOS entwickelst, geht halt nur
C, C++,
Objective-C,
Swift.
Es gibt zwar auch Pythonista
und so, man kann schon Python da ausführen, das geht auch,
aber das ist alles nicht so richtig offiziell
erlaubt. Und
ja, JavaScript geht halt auch
und
vielleicht ist halt irgendwie
WebAssembly irgendwann mal so ein offizielles Target
und dann könnte man auch Python
da so wieder reinschummeln quasi.
Und dann Apps für Telefone
in Python schreiben.
Was ja auch so ein anderes Problem ist,
die beiden Hauptdinger, auf denen Python nicht da ist,
ist halt Frontend-Web und halt
mobile Geräte und das sind
zwei Kategorien, die immens wichtig sind eigentlich.
Und das macht so ein bisschen Angst,
dass die Story für Python da nicht so gut ist.
Aber gut, dass das in die richtige Richtung geht.
Ja, genau.
Christian Heim ist Hamburger
Python User Group,
hat da ganz viel gemacht und das freut mich
sehr, dass das
coole Sachen macht.
Dann ist Black jetzt stable.
Black ist stable.
Ja, genau.
Das ist toll.
Manche Leute finden es auch schrecklich, aber
ich finde es eigentlich eine gute Nachricht.
Das heißt, man kann sich jetzt darauf verlassen,
dass das erstmal eine Zeit lang alles so bleiben wird
was auch mit dazu gekommen ist, ist Port für Python
3.10 Syntax und so
und ja, eine ganze lange Liste von
Dingen, die da irgendwie... Und damit ist jetzt auch die
DIP, die Django Enhancement
Proposal
Django Enhancement
Proposal 8 sagt irgendwie
lass doch mal Autofarmata benutzen
aber erst wenn es stable ist und
genau, weil Black Hat stable ist
ist Django jetzt auch quasi mit
Black formatiert und ja
Ja, wir haben jetzt nochmal hier drauf
und
Ich weiß aber gar nicht genau. Also es ist nichts, was
jetzt irgendwie rausstechen würde, warum man sagt,
das ist ganz toll, aber kann man ja mal
ausprobieren. Also die Information,
es gibt jetzt eine neue Version, ist vielleicht daran am interessantesten.
Ja, ansonsten
genau zu der
HTMX-Episode von letztem Mal. Es gab
noch so ein Essay von, das habe ich dann gesehen, als ich
gedacht habe, okay, kann man das nicht vielleicht irgendwie einfacher
erklären mit diesem HTOS
Ding, was ist das eigentlich
und so. Und habe dann gesehen,
es gibt ein Essay von dem
Carson Gross
dazu,
wo er beschreibt,
wie er sich das so gedacht hat und
nimmt halt so ein Bankbeispiel und
sagt halt, also wenn du eine JSON-API
hast, dann muss, wenn du
so eine JavaScript-Applikation
hast, dann muss
ja sozusagen
die Applikation immer wissen, was
zum Beispiel sowas bedeutet, wie du hast dein
Konto überzogen und
welche Aktionen du dann machen darfst und welche
nicht, während wenn du halt HTML
rüberschickst, dann können da ja zum Beispiel,
ob du jetzt eine Überweisung machen kannst oder so, ist halt
ein Link, dann kann der Link da halt entweder drin sein
oder nicht. Und
dein Browser muss halt nicht wissen,
quasi...
Dein Browser muss nicht wissen, dass du
dein Konto überzogen hast, um...
Der zeigt einfach nur Formulare an und
das Formular zum Überweisen zeigt dir halt einfach nicht mehr an.
Und sozusagen
der State, dass der das dann nicht mehr
anzeigt, ist halt im HTML und nicht in der Applikation.
Während in der
in einem JavaScript-Fall,
kriegst du halt nur die Account-Daten von der Bank
und musst dann halt in der Applikation überprüfen,
okay, hat er sein Konto überzogen? Wenn ja,
dann darf er nicht überweisen. Und das ist
natürlich sozusagen einfach
ein bisschen anders. Und vielleicht kann man sich das anhand dieser
Geschichte, ich will verlinken, packen das in die Shownotes,
also ich fand, daran kann man eigentlich ganz schön
sehen, was da eigentlich so gemeint ist mit
Hypermedia is the engine
of application state.
Okay.
Was gab es noch? Ach ja, Wagtail. Wagtail, genau.
Wagtail.
Wagtail bekommt einen neuen Page-Editor
und zwar von Google.
Genau, von Google gesponsert.
Weil Google relativ viel Wagtail wohl intern
benutzt.
Ja, und das ist natürlich schon nett. Also ist es
nicht so wahnsinnig viel Geld, irgendwie, was ist das,
150.000 Dollar oder so, die sie denen geben, aber
ich meine, da kannst du halt schon, also kannst du schon
ein bisschen was mit machen und
ja, also freut mich auf jeden Fall auch, dass die Ergebnisse dann
halt allen hinterher zugutekommen, das ist ja sehr
schön.
Genau, und ja, ich meine, ich benutze
jetzt auch für meine Geschichten da
Wagtail. Ich bin nicht immer so ganz super überzeugt, ob das die richtige Entscheidung ist, aber
solche Nachrichten sind auch gute Nachrichten für mich.
Apropos Open Source, weil das ja Open Source ist, da gab es doch irgendwie noch eine Meldung
von uns. Ja, Oliver hat netterweise einen Kommentar
zu der Open Source Episode hinterlassen und meinte, da kennt ihr eigentlich
diesen Prototype Fund. Und nö, kannte ich zumindest überhaupt gar nicht.
Ja, man sagte mir auch nichts. Und was ist das? Das ist irgendwie
ein Fonds, der aufgelegt ist, das Bildungsministerium zahlt dann irgendwie.
Das geht von 2016 bis 2024.
25 Projekte und 16
Förderungsrunden.
Da sind wir natürlich jetzt mit 2022 so mittendrin. Oder am Ende eigentlich schon fast.
Wenn er jetzt nur den Förderantrag schreiben will.
Also das Problem ist wahrscheinlich immer, der Förderantrag ist relativ lang.
aber ja, wie immer
bei solchen Dingen, aber wie viel kriegt man?
50k für 6 Monate? Ja, 47.500
Euro für 6 Monate maximal
also vielleicht auch weniger
Jochen, das ist ja so, oh, für ein Team
die helfen, ja
Ne, ich habe mir überlegt
also ich meine, tatsächlich mache ich ja eigentlich genau das
da steht auch noch in diesem Ding drin, so für Freelancer
vielleicht ganz interessant, da stelle ich mir so, oh ja, stimmt
eigentlich mache ich genau sowas und
eigentlich wäre das ja tatsächlich, vielleicht schreibe ich da einfach mal was hin
aber andererseits
ja, so
finanziell ist das jetzt nicht so super attraktiv, ehrlich gesagt.
Und für ein Team ist das natürlich
ja, nee.
Ja, der kann man.
Ach ja.
Tja, die Preise und so, öffentliche Hand.
Aber prinzipiell sehr
interessant und auch gut, dass das jemand macht, weil das ist
eigentlich total wichtig
und müsste man eigentlich noch mehr machen.
Aber immerhin, das ist ja schon nicht so schlecht.
Und vielleicht weiß ja jemand noch nicht, dass es das gibt.
Ja, und wenn jemand zum Beispiel gerade nach dem Studium
damit durchaus zu finden sein kann und dann damit was probieren kann
und damit wird das auch schon mal super.
Ja, dann, das war auch
jetzt vor ganz kurzem
HDB 1.0
Release, ist vielleicht auch interessant.
Ja, muss man eigentlich, ich weiß nicht, ob man da so
in Detail drauf eingehen kann.
Aber was ist denn eine HDB trotzdem?
HDB ist ja
quasi
ein Versuch sozusagen
diesen Object Relational
Impedance
Mismatch.
Jetzt hast du was gesagt, das habe ich überhaupt nicht verstanden.
Edge Relational
in Object Relational.
Also du hast ja immer das Problem
in objektorientierten
Sprachen, das mappt halt nicht so richtig gut
auf relationale Datenbanken.
Relationale Datenbanken ist halt so eine Idee
aus Anfang der 70er
und eigentlich eine ziemlich coole Idee,
aber damals gab es objektorientierte Programmierungen
und sowas gab es einfach nicht.
und das ist aber irgendwie das
dominante Programmierparadigma
irgendwie geworden.
Und jetzt haben wir halt immer das Problem, okay, man
speichert die Daten halt in
Relationen oder in einer relationalen
Datenbank und man hat aber jetzt
Objekte irgendwie in der
Applikation und wie
kriegt man das jetzt zusammen? Da gibt es im Grunde zwei wesentliche,
also kann es auch hohe SQL-Szenen
natürlich schreiben, aber es ist halt so ein bisschen
unhandlich.
Die meisten verwenden dann eben
ORMs, also so Object Relational
Mapper. Wie den von Django oder
Peewee oder sowas. Genau, oder SQL
Alchemies für Python, vielleicht der bekannteste.
Und da gibt es zwei
grundsätzlich unterschiedliche Patterns. Das eine ist
Active Record Pattern, was halt Ruby on Rails
verwendet. Django verwendet
das auch. Oder halt
Data Mapper Pattern, das verwendet SQL Alchemy.
Die haben halt so ihre
Trade-offs. Die haben halt Vorurteile und Nachteile.
Es kommt, man kann jetzt nicht sagen, dass ein oder anderes
besser. Jedenfalls,
aber sowas muss man halt eigentlich
oder die meisten Leute verwenden sowas heutzutage
einfach deswegen, weil es halt das Leben einfach
deutlich leichter macht, aber trotzdem hat man
immer noch das Problem, dass viele Sachen
nicht so richtig gut gehen und schwierig
sind und man da halt
ja, also man
muss mit den Dingern auch teilweise so ein bisschen
kämpfen und
ja, die Idee bei HDB ist halt einfach
zu sagen, warum denken wir das Ganze nicht einfach nochmal
neu und machen das halt eher so, dass es
zu dem, dass halt die Datenhaltung auch zu dem
zu der Art, wie wir heutzutage programmieren
besser passt. Und
die Standardfälle, wo man halt in SQL
komische Sachen schreiben muss oder die mit den
normalen ORMs nicht so gut gehen, die machen
wir halt so, dass es halt einfach geht.
Und dass man auch,
es ist halt immer so ein Fremdkörper.
Selbst wenn man es mit einem ORM macht, es ist halt,
es sieht immer komisch aus, es ist immer ein bisschen eigenartig.
Es passt halt nicht so richtig.
Und ja, genau,
dafür haben sie sich eine neue Sprache überlegt. Da haben sie gesagt,
das eigentliche Problem ist halt, warum die ORMs nicht so gut
sein können, ist halt, dass sie,
SQL als Compile-Target sozusagen
ziemlich schwierig ist, weil halt SQL ist ja auch
kompliziert. Das ist eigentlich auch dafür gemacht, dass
Menschen das schreiben, was ja heute auch
keiner mehr macht. Eigentlich war das mal gedacht für
das Analysten und so Queries schreiben.
Weiß ich nicht, ob das jemals
passiert ist, aber heutzutage
passiert das kaum, denke ich.
Sondern es ist halt immer so,
dass du verwendest halt ein ORM, der
compiled dann zu SQL, also zu etwas, was eigentlich dafür
gemacht ist, dass Menschen das schreiben. Das macht irgendwie alles
keinen Sinn. Dann ist es halt auch so, SQL
ist nicht so gut composable. Du kannst halt nicht
irgendwie Schnipsel SQL rumreichen
und die dann halt zusammensetzen oder
es geht alles nicht so gut.
Und genau,
all diese Dinge sind halt bei Edge
QL oder so, ist glaube ich dann die Sprache
besser, sozusagen.
Aber das weiß man nicht so genau.
Das ist halt jetzt gerade eine neue Ankündigung.
Wir entwickeln da schon seit ein paar Jahren dran, aber jetzt ist halt die
erste 1.0-Version
erschienen.
Also,
das hört sich auf jeden Fall interessant an, kann man sich ja mal angucken.
Und es ist halt so eine Mischung,
ist basiert, also das, was sie da gebaut haben, ist
also die Sprache soll halt standardisiert
werden, das ist eher so ein Standard.
Es gibt aber auch eine konkrete Implementation,
die basiert auf
Postgres und
quasi so ein bisschen Erweiterung Richtung
Graphen, Datenbanken, weil das ist ja auch mal so ein Ding,
das ist eigentlich gar nicht so klar, warum wir jetzt
relativ lange Datenbanken gewonnen haben gegenüber den
Graphen-Datenbanken und es gibt ja auch noch Graphen-Datenbanken
Neo4j oder diverse andere
D-Graph
Zeugs und ja, eigentlich will man
beides irgendwie haben und
und in Postgres kann man das ja ganz gut auch abbilden
und dann haben sie halt irgendwie so ein Layer über Postgres gelegt.
Ah, wie heißt das? Ein Layer über Postgres? Klingt gerade spannend.
Also das klingt auch so, als könnte man das mit FastAPI benutzen.
Ja, die Leute, die das gemacht haben, das sind bekannte Leute,
das ist nicht so, dass das irgendwie aus dem Nichts kommt,
sondern der CEO von HDB ist dann auch eine Firma,
das macht das Ganze wieder so ein bisschen, ich weiß nicht genau,
die machen halt vor allen Dingen, die haben viel Consulting gemacht,
und haben halt viele Probleme gesehen auch,
die man halt
normalerweise so hat.
Ja, der
Jure
Selin
der hat auch
irgendwie an den
Peps zu
Async Await diese ganzen Geschichten,
da hat er hauptsächlich dran mitgeschrieben.
Also der ist halt auch einer der
Verantwortlichen dafür, dass wir jetzt in
Python irgendwie Keywords für
Async Await, also
Syntax-Unterstützung für diese ganzen
ASIM-Geschichten haben.
Und hat da auch ganz viele Dinge
implementiert und
Lukas Schlanger hat
für HDB auch gearbeitet schon.
Es ist alles typisiert, genau.
Das ist auch sowas. Den letzten Namen hatte ich jetzt auch noch nicht gehört.
Welchen? Lukas.
Der Release-Manager von Python für
3.8, 3.9, 3.10.
Nee, nicht für 3.10, nicht Quatsch. Das ist Unsinn.
Aber früher
oder vielleicht noch sogar früher, ich weiß es gar nicht mehr genau.
Und der
auch ganz einer, der hat ganz viel
zu Type Annotation Geschichten gemacht.
Der hat Black geschrieben, genau.
Naja,
also auch sehr bekannte
Typ da
und ja,
genau, der hatte
und Async.io hat halt auch viel zu tun
und die, das ist alles,
die haben auch, genau, die haben auch
Async.pg
geschrieben. Das ist halt die schnellste
Postgres-Artenanbindung sozusagen,
die es so gibt.
Ist auch ein ganz tolles Projekt.
Dann haben sie
UV-Loop geschrieben,
also das Ding, was halt
unter
UV-Corn und so drunter liegt.
Also eine schnelle
Async-IO-Implementation,
die in der Standardbibliothek ist ja sozusagen nur eine Referenz-Implementation,
aber die ist halt nicht schnell.
Und sie haben halt eine schnelle Version geschrieben,
also ganz viel der Basis-Infrastruktur,
die man so bekommt, da auch aus der Ecke schon.
Insofern, das sind schon Leute,
die wissen, was sie da tun.
Dann darf man auch ein bisschen Werbung für seine Projektung machen
Genau, wobei, ja, Firma ist natürlich
Was uns jetzt zur Werbung bringt
Moment, Moment, das ist noch nicht mit den News
Das ist noch nicht mit den News durch
Achso, was geheim ist, das ich noch gar nicht weiß
Also
einen Punkt noch, genau, ich habe wieder Podcasts
gehört, Problemierbar hat jetzt auch was über
letzte Episode, das war
Laravel, PHP
Livewire
Das fand ich auch ganz interessant, weil immer so diese
Verbindungen finde ich immer interessant, weil die vielleicht nicht so
klar sind oder mir nicht so klar waren.
Und wenn man das dann weiß, dann
macht das halt das alles schon mal ein bisschen
verständlicher. Nämlich
Laravel
Livewire ist auch tatsächlich
inspiriert von Phoenix Liveview.
Ist aber auch schon ein bisschen älter.
Das ist von 2019. Ich hätte das jetzt gedacht, dass
es jünger ist, aber es ist auch schon relativ lange quasi
dabei, also bei diesem Trend, die Dinge jetzt
wieder vom Server aus zu machen. Und
der Autor von Livewire ist der gleiche wie der von
Alpine.js. Das ist halt
Caleb
und
Portio
und
genau, der hat AlphanJS gebaut und halt aber auch
LiveWire und der wollte
eigentlich ja sowas eben wie Phoenix LiveView
bauen und dann
war das Problem mit dem PHP
naja, also so WebSockets
also Phoenix LiveView macht das ja über WebSockets
das geht halt mit PHP nicht so richtig
weil du hast halt den asing-Teil
in PHP nicht, also gibt's jetzt
auch seit PHP 8.1,
das ja auch vor ein paar Monaten rausgekommen ist,
aber es gibt keine
Infrastruktur so richtig dafür und die ganzen Router
können das nicht und so. Das heißt,
quasi eine Verbindung offen halten
vom Server aus ist in PHP
sehr, sehr schwierig. Das geht eigentlich gar nicht richtig.
Und dann hat er halt angefangen nachzudenken,
so okay, mit WebSocket,
das wird irgendwie nicht funktionieren. Wie kann man das denn sonst
machen? Und die machen das,
der macht das auch alles über
Ajax-Calls und Pollen
und
sie machen so ein bisschen komplizierte Dinge darüber,
dass sie halt immer alles mit übertragen, wenn
sobald irgendwie ein Ajax-Call gemacht wird.
Also was ich daran cool finde, ist, dass das
überhaupt geht und dass man den Websocket
gar nicht so unbedingt braucht.
Also das zeigt das auf jeden Fall irgendwie. Man kann halt
sehr viel machen, ohne unbedingt einen Websocket
haben zu müssen und das ist eigentlich auch sehr nett, weil
tatsächlich
Websocket wird es wahrscheinlich in Django
ohne Django-Channels-Anstützung
wahrscheinlich nie geben.
Aber offenbar
Man braucht es auch nicht unbedingt.
Das ist interessant, da können wir vielleicht gleich nochmal drauf eingehen
und sagen, warum oder was FastAPI
Genau, aber mit FastAPI
könnte man das wahrscheinlich sehr gut machen.
Genau.
Ja, das war es eigentlich.
Ich glaube, das probiere ich
nächstes Mal aus. Habe ich auf Twitter gesehen.
Dachte ich, kann ich hier auch mal anbringen.
Wenn jemand anders das auch
Twitter-Thema
irgendwie geschrieben.
Jetzt war ich beim Zahnarzt
und da hat er irgendwie
wurde gerügt, beziehungsweise...
Warte, warte, warte.
Okay, nochmal.
Nicht ich.
Ich habe es auf Twitter gelesen.
Ja gut.
Da meinte jemand dann,
manchmal fühlt man sich ja so ausgeliefert,
wenn man so beim Zahnarzt sitzt.
Dann kriegt man auch noch so harsche
Ansagen wie
Mund auf.
Was ist das denn hier?
Besitzen sie eigentlich Zahnseide?
Warum nicht? Mach das doch mal bitte häufiger.
Und der war dann so, ja,
ich hab dann, also nachdem
ich diese zahnweite Geschichte
darauf
so hingewiesen worden bin, hab ich dann gefragt, ja,
wie sieht's eigentlich bei Ihnen aus? Machen Sie Backups?
Und
prüfen Sie die auch, ob Sie die
ab und zu mal einspielen, ob das überhaupt geht.
W schon gut wenn man das macht Das war ja eine Geschichte hab ich auch irgendwo im Talk Mitleid Ja sch Muss ich mir merken muss ich auch mal versuchen anzubringen Ja habe ich mir auch fest vorgenommen
Wenn dann die Frage kommt,
machen sie eigentlich ihre Backups.
Genau, ja.
Ja, okay.
Dann wollen wir jetzt wieder Werbung schalten.
Also wir wollen nicht, aber wir müssen natürlich.
Ja.
Und wieder mit freundlicher Unterstützung heute von unserem
Werbepartner NordVPN.
Da gibt es was Neues.
Ja, ein exklusiv Deal
und ein Geschenk obendrauf zum NordVPN
Geburtstag.
Und dann könnt ihr auf den NordVPN
Python Podcast gehen und
euch den Deal da sichern.
Und da gibt es auch so eine 30-Tage-
Geld-zurück-Garantie.
Hatten wir auch letztes Mal schon.
Ja, genau. Ich weiß nicht.
Benutzt du VPNs irgendwie?
Relativ selten, aber ich glaube, zum
Geoblocking umgehen ist das gar nicht so schlecht.
Ja, wenn du Streaming haben möchtest,
möchtest du irgendwie das Streaming-Programm von zu Hause gucken,
wenn du im Urlaub bist oder so,
ist das doch gar nicht so gut. Genau, also
diese Google-Glocken-Geschichten
oder halt auch eben,
wenn man sicherstellen möchte, dass
man genug Durchsatz hat und das irgendwie
vom lokalen ISP vielleicht nicht unbedingt zu erwarten
ist, dann
kann das durchaus hilfreich
sein. Ja, also
genau, einfach da auf
https.nordVPN.com
slash python-podcast gehen und mal angucken, was da so von dir
gibt. Genau, damit würdet ihr
uns unterstützen.
Dann machen wir
weiter im Programm und gehen zu FastAPI.
Ja, FastAPI, das Thema.
Genau, das Thema unserer Folge.
Was ist denn FastAPI
überhaupt? Also es ist ein weiteres Webframework,
ein neues Webframework
und ersetzt, oder was heißt ersetzt,
also ergänzt vielleicht so ein bisschen die Welt, die es in Python
dazu gibt. Ja, das ist sehr
interessant. Also genau, also eigentlich
die meisten anderen Sachen sind ja sehr alt, also
Flask ist sehr alt.
Django ist sehr alt.
Wenn ich das so richtig verstanden habe, ist
FlaaS API quasi das neue FlaaS, ist das so das
ein bisschen, was man da gemacht hat?
Ja, also es kommt darauf an,
aber auf jeden Fall ist es eher
vergleichbar mit
FlaaS quasi, was den
grundsätzlichen Ansatz
angeht, aber
es ist halt auch irgendwie wieder so ein bisschen anders.
Aber einfach historisch, man hatte so eine
Explosion von unterschiedlichen
Webframework-Projekten irgendwann
halt um diesen Dreh, wo die alle entstanden sind,
2004, 2005, 2006.
Pyramid ist auch aus der Zeit, oder?
Das weiß ich nicht.
Kann sein, dass das auch später war.
Ich weiß es nicht so genau bei Pyramid, aber
viele Webframeworks
kommen halt aus der Zeit.
Oder da gab es halt ganz, ganz viele.
Da gab es so eine Zeit, wo alle zwei Monate
irgendwie was Neues rausgekommen ist.
So wie jetzt bei JavaScript.
Und ja,
die meisten sind wieder verschwunden.
Ich weiß nicht, was gab es damals?
also Turbo Gears und ach was ist der Teufel
Naja, das meiste ist halt alles wieder
verschwunden und übrig
geblieben sind im Grunde Flask und Django
und die repräsentieren
ja auch so irgendwie
ja, gegensätzliche
also die Enden von irgendwie so
also entweder Batteries included oder halt irgendwie
sehr wenig dabei, aber
dafür sehr flexibel
Ja, genau, also der Unterschied auch mit den UAMs
hatten wir eben schon gesprochen, dass halt Django
den UAM
mitliefert und dass bei Flask meistens
SQL-Archive nimmst.
Ja, aber kannst halt auch irgendwas anderes nehmen.
Hast da keine feste Bindung.
Ja, aber irgendwie seit
ein paar Jahren gibt es halt sowas Ähnliches
wieder. Es gibt wieder viele neue
Web-Frameworks.
Was vor allen Dingen an der
neuen Syntax bei Python ist,
liegt halt an der Sprache, die sich geändert hat.
Genau, an den Typefilms, die es dazu gekommen sind.
Die Typefilms, der Async-IO.
Genau, das ist Async.
Und was unter FastAPI drunter liegt,
ist ja Starlet.
Starlet, genau.
Vielleicht kann man das so ein bisschen in die ganze
Historie so ein bisschen kurz erzählen.
Also eben, wir sehen
so Async-Webframeworks,
jetzt wieder ganz viele, so Scenic, Falcon,
FastAPI,
Quad,
also jetzt gibt es auch wieder ganz viele.
Und der
Autor von FastAPI
hat sich auch viele angeguckt und hatte
vorher...
Ja, viele andere coole Sachen
noch macht nebenbei.
in dem Python API.
Also Type-A ist auch sehr ähnlich.
Es gibt auch SQL-Model, wenn man das irgendwie mit OEM machen möchte.
Aber vielleicht erstmal nochmal,
was du sagen möchtest. Genau, der hat
viel Django gemacht oder
mit anderen, der hat auch viele APIs gemacht
und war auf der Suche
nach einem Framework, das halt irgendwie
bessere
Entwickler-Experience irgendwie bietet.
Also Django REST-Framework oder so.
Er fand das jetzt nicht schlecht,
er fand das schon gut. Also der hat sich halt auch
also die Browsable
API bei Django REST Framework.
Es war halt auch eine wesentliche Inspiration für das, was er
dann halt da gemacht hat.
Und fand das schon gut,
aber es war halt
nicht alles dabei, was er gerne gehabt
hätte.
Ja, dann
war aber ein Ding fast
perfekt. Also er hat sich zum Beispiel
Django REST Framework hat er sich viele Sachen
gut gefasst, aber es war halt nicht. Dann hat er sich
Marshmallow angeguckt, bei Flask
fand er auch gut, diese ganzen Validierungsgeschichten.
und Serialisierung von
ganzen Objekt-Hierarchien und so, aber
das ist halt
auch noch nicht so
hundertprozentig hat das Best getroffen, was er
irgendwie haben wollte und
es gab noch ein paar andere Sachen, die er sich auch angeguckt hat
und
dann
hat er
sich dann der Autor von
Tom Christy ist ja auch
so einer, der hat ganz, ganz viele Projekte gemacht
und
viele Dinge sind auch Basisinfrastruktur
für ganz viele andere Sachen.
Er hat Django Restorent Work irgendwann mal geschrieben,
dann hat er irgendwann Django Restorent Work
quasi abgegeben oder
macht es, weil
ehrlich gesagt ist es auch mehr oder weniger fertig, da ändert sich
schon seit einigen Jahren nicht mehr viel.
Und hat dann
etwas gemacht, wollte aber schon
APIs weitermachen und hat dann API Star
mal ins Leben gerufen.
Und die Idee dabei war halt auch
so ein bisschen irgendwie
das so zu machen, dass es halt von der Kommandozeile
ausgeht, plus irgendwie im Web, dass
es halt alles das gleiche Interface hat, mit Typen dran
und nativ Async und all sowas.
Und
genau,
Sebastian Ramirez meinte dann auch so,
ja, das war eigentlich schon genau das, was ich gerne gehabt hätte.
Und dann hat er aber
Tom Christie irgendwie angefangen, Starlet zu entwickeln.
Also
auch ein Web-Framework, aber sehr
Basis-Infrastruktur-mäßig, sehr
auf Async fokussiert und gar nicht mehr unbedingt
im API-Bereich. Und APSAR
ist dann eher zu so einem Schema,
Validierungstool geworden.
Und das heißt, das Ding, was
er am besten fand eigentlich oder am besten zu seinen
Anforderungen passte, hat plötzlich
den Fokus gewechselt und was anderes gemacht.
Und dann dachte er so, oh Mist, jetzt gibt's
nix mehr. Jetzt muss ich irgendwie,
ich wollte es wirklich vermeiden, aber jetzt muss ich es vielleicht auch selber
in einen Webfile schreiben. Und dann hat er das halt
gemacht und dabei ist FastAPI
rausgekommen. Und dabei hat er, glaube ich, relativ viel
auch noch an Pydentic mit rumgewerkelt,
wenn ich das so gesehen habe. Ja, genau. Pydentic
ist halt eine der Geschichten,
die sonst nirgendwo drin sind, die halt da
mittlerweile sind. Genau, weil halt so Erweiterung
von Data Class das halt, dass man so ein bisschen
Typen und Modelle hat
dann direkt mit Validierung und so. Aber darauf
gehen wir gleich ein bisschen genauer ein, würde ich sagen.
Also wir haben gesagt, das ist jetzt ASCII,
hast du gesagt, das ist Async.
SGI, ja. Was ist denn da eine ASCII-Applikation
überhaupt nochmal?
Die immer noch fragen.
Ja, also
ganz lange der Standard für die
Kommunikation zwischen irgendwie dem
Applikationsserver, der halt irgendwie
tatsächlich Requests annimmt und dann irgendwie
die Kommunikation mit dem Browser tatsächlich
macht. Das macht man ja normalerweise nicht,
wenn man irgendwie eine Applikation
schreibt, sondern
das nennt sich
WSGI oder WSGI oder
weiß ich nicht, wie man das am besten ausspricht,
Microwisky.
Nicht dasselbe wie
What you see is what you get, Whisky.
Das Ding,
das ist auch super
einfach. Also eigentlich ist alles total trivial.
Aber das Gute, dass es halt ein Standard ist,
das ist mehr oder weniger eine Funktion,
die man halt implementieren muss. Und wenn man das
tut, ist man halt ein WSGI-Server.
Der Grund,
warum man da jetzt nochmal irgendwas anderes brauchte,
also der kriegt im Wesentlichen ein Request,
kommt rein, Response geht raus. Das ist es eigentlich.
Das ist mein klassischer HTTP-Kind.
Ja.
Genau.
Aber genau.
So, jetzt ist aber...
Ja, Dinge haben sich geändert.
und man will jetzt eventuell auch solche Dinge
machen können wie Websockets oder halt
man hat halt eventuell langlaufende Requests
und
Man möchte halt nicht nur
einmal eine Response zurückgeben können,
sondern vielleicht halt auch irgendwie
wieder was zurückbekommen,
dann wieder was rausreichen und
mit Co-Routinen geht das ja super eigentlich.
Und genau,
dann gibt es, aber es gab kein
Standard und dann hat irgendwann
glaube ich, Andrew Godwin,
auch bekannter Django-
Entwickler, der hat
das Migrations-Ding gebaut und so.
Der
hat dann irgendwann in diesen ASGI-
Standard geschrieben,
um halt das dann halt möglich zu
machen, dass man da halt ein Standard hat für alle.
Und da ist es im Grunde so,
es ist auch wieder super minimal, aber
man hat auch eine Funktion, die man implementieren muss
und die kriegt im Grunde eine Receive- und Assistent-Funktion
und halt, ich weiß gar nicht, muss ich nachgucken,
Scope.
Ja, aber
da geht das halt. Da kannst du halt auch wieder Sachen
nochmal empfangen und
dann irgendwas machen und dann wieder was rausschicken und
bist halt nicht in diesem Request-Response-Ding
so drin.
Ja, und
genau.
Ja, und FastAPI ist halt ein SGIS-Server.
Und dann gibt es halt eine gute
Implementation darunter. Das ist
UV-Corn.
UV-Loop, da hatten wir es schon.
Also eigentlich ganz unten drunter ist LibUV.
Das ist das Ding, was halt auch unter
Node.js darunter liegt.
Aber ich glaube, da haben wir auch schon
eine Episode mal drüber gesprochen.
Ja, vielleicht einmal doch mal kurz erklären, weil nicht alle Leute haben ja alle Episoden gehört.
Das ist halt eine Bibliothek, die
Backups trahiert, die dieses
Betriebssystem, dieses Calls Backups trahiert,
die man halt benutzen muss, um halt schnell
I.O. zu machen.
Genau. Und das ist halt unterschiedlich,
je nachdem, was man verwendet. Unter Windows
TCP Completion Ports oder was auch immer
man da verwendet, keine Ahnung.
Unter FreeBSD ist es halt
KQ.
und
übrigens ist es halt
E-Poll und das Ding
bietet halt ein Standardinterface
für all diese Dinge,
SelectPoll, ich weiß nicht, was da noch alles drin ist
und das kann man halt benutzen
und da muss man sich nicht drum kümmern, auf welchem Betriebssystem
man läuft und so.
Und genau, das
und Node.js hat
das halt
relativ, hat diese
Entwicklung da getrieben, weil die haben das halt
dann stark verwendet
und
ja, mit den
AsyncIO
Primitiv Keyword-Geschichten
in Python bot es sich dann halt ja auch
an, da irgendwie sowas zu
verwenden und da gab es halt die schnelle Event-Loop
Implementation mit UV-Loop von den
Leuten, die jetzt HTML gemacht haben
und auf UV-Loop drauf
sitzt halt UV-Corn,
also quasi so wie G-Unicorn
halt als Applikations-Server, der dann halt
Web-Geschichten macht und dann halt UV-Loop
nutzt, um halt schnell I.O. machen zu können
und das ist auch wieder ein Projekt von
Tom Christie.
Okay, ja, der weißt du, die Katze mit dem Schwanz.
Genau, und da drüber
gibt es halt dann nochmal so ein minimales
Web-Framework, was halt dann
nochmal die ganzen Routing,
Request-Response-Geschichten abstrahiert und das ist
halt dann Starlet.
Ja, und FastAPI
benutzt Starlet.
Und, ja,
genau, aber
die Idee ist im Grunde viele Sachen zu kombinieren,
Pydentics kombinieren mit Typ-Annotationen,
mit
mit einer Dependency Injection
Geschichte für
Parameter und sowas.
Und
halt Stalette als
quasi schnell,
für das schnell unten drunter.
Und ASVI.
Und ja, das
ist eigentlich eine ziemlich coole Kombination
irgendwie. Man kann jetzt sagen, na gut,
ich habe mir jetzt den Fast-API-Source-Code
auch so ein bisschen angeguckt mal.
Also ganz oft sieht man schon
so irgendwie, naja, er importiert
halt Sachen von Starlet und das war's.
Das ganze WebSocket-Modul in
FastAPI ist halt irgendwie vom Starlet-Import-WebSocket
fertig. Ja gut, also abstrahiert halt
und dann abgibt es vielleicht an ein, zwei Stellen
und wird halt gut integriert.
Genau. Das, was man da haben möchte, ja. Und es ist halt,
die Dokumentation ist halt schön geschrieben und so. Er hat das dann
irgendwann mal in Reddit, auf irgendeinem
Reddit-Group oder so angekündigt,
irgendwie FastAPI
und die Reaktionen waren da so ein bisschen geteilt.
Also ich finde das
super, was er gemacht hat, aber
auf Reddit wurde dann halt irgendwie
und Python.
und
im Grunde
ist es eine wirklich
schicke Geschichte und überhaupt
ich würde mal sagen, also was daran halt neu ist,
es gibt es erst seit
2019 und das ist jetzt schon
weiß ich nicht, sehr
sehr verbreitet, keine Ahnung wie verbreitet, aber in den
entsprechenden Umfragen ist es halt irgendwie
nicht mehr viel
hinter Django und F.L.A.S.K.
sondern wie viele Leute verwenden das
und das
ist, ich glaube, einer der Gründe, warum
dass so ist es einmal, dass es halt
viele Dinge, also wo bei anderen Geschichten
was gefehlt hat, sind halt da mit drin
und dann auch
dass
diese Developer Experience Geschichte da so betont
wird, das ist auch etwas, was man jetzt in letzter Zeit
immer mehr sieht, was ich von früher
kenne ich das so nicht
Da musst du doch alles von Hand und selber
schön und hässlich
Wenn es kryptisch ist und schwer zu installieren
das war so ein bisschen
Deswegen macht man das
Ja genau, da musst du ja erstmal beweisen, dass du manns genug bist
und hier das Schwert aus dem Stein ziehen
bevor du irgendwie
so und dass man das den Entwicklern
einfach macht und dass die da
irgendwie einfach mit Google spielen
Ja das ist irgendwie so ein Ansatz
also früher wäre das Leuten
fremdartig vorgekommen
aber heute ist das irgendwie
heute, ja, Zeiten haben sich geändert
Ja so will man das wahrscheinlich auch machen, weil man keine Lust hat
die ganze Zeit nur im Keller rumzusitzen
Gut ist, wenn die Leute aus dem Business noch erwarten
und das hat genauso lange gedauert wie früher.
Ja, ja, ja, gut.
Ich meine, es ist halt die Frage, ob einem das wirklich wahnsinnig viel hilft.
Ja, ich würde schon sagen.
Ja.
Aber es ist auf jeden Fall
irgendwie eine neue Geschichte und ich
finde das ja auch im Prinzip gut, dass man da so,
dass das halt irgendwie alles ein bisschen angenehmer wird
und nicht so stochlich ist.
Okay.
Ja, vielleicht müssen wir
mal kurz darüber reden, wie der das macht. Also zum Beispiel
über Type Annotations geht halt da ganz viel an den Kunden
dran. Parameter kannst du übergeben
und kannst direkt sagen, okay,
das Query enthält jetzt ein
Integer oder sowas.
Ja, also eine Geschichte, das hatte mich am Anfang
auch so ein bisschen verwirrt.
Die Query würde ich jetzt so
intuitiv sagen, ich weiß aber nicht, ob es richtig ist,
keine Ahnung.
Das hatte mich am Anfang, da wurde ich dann nach der, also
klar, also man schreibt jetzt, also man
hat auch immer, also die Dinger, die man halt
in FastAP schreibt, sozusagen
die Endpunkte,
was man sagen möchte,
sind halt Funktionen und die Funktionen haben halt Parameter
und dann geht da was rein, also kommt ein Request
mehr oder weniger rein und es geht eine Response raus.
Man sagt jetzt nicht unbedingt Request,
beziehungsweise
bei Django wäre es halt so, da kommt ein Request rein,
geht eine Response raus und dann
popelt man sich sozusagen aus dem Request die ganzen
Sachen halt raus, die man so braucht.
Also es gibt dann Request.get oder
Request.nation oder
ja, man nimmt halt den Body
und dann gut, wenn man jetzt sowas wie
REST Framework oder Formulare
nimmt, dann natürlich eine ganze Menge ab.
Oder Class-Based Views oder sowas, ja.
Ja, aber prinzipiell
muss man sich den, ist der Teil,
man poolt sich den Kram
da selber halt raus so.
Und das ist bei FastAPI halt nicht so.
FastAPI passiert halt sehr viel
von dieser Magie direkt,
wenn du die Type-Animation richtig
dran schreibst.
Man schreibt halt Type-Animation in die Parameter und dann
kommen die Daten
irgendwie magisch da rein.
Ja, also wenn man besonders gut wird, wenn man da
Pydentic-Modelle verwendet als
Parameter
Annotation, weil dann wird halt die
Validierung von den Objekten, die da beispielsweise
als JSON reinkommen oder so, direkt
mit Pydentic durchgeführt und das ist
sehr cool, weil halt die ganzen Validierungen dabei sind,
die kann man an den Pydentic reinschreiben,
die passiert halt automatisch, die
Type-Konvertierung passiert automatisch, du hast
in den Objekten direkt die richtige
Datenstruktur vorliegen, du kannst
auch das mit, weiß nicht, sogar mit Daytimes
machen, deinen eigenen Parser dafür in dieses Pydentic
Modell integrieren, wie du das haben willst und
kriegst direkt die nutzbaren Python-Objekte
da raus, die du brauchst.
Das ist schon sehr, sehr nett.
Parametern waren.
Und ja,
das funktioniert eigentlich auch immer irgendwie ganz gut.
Das ist echt super, ja.
Also was man dann, also vielleicht an der Stelle
nochmal ganz kurz, würde ich gerne eingehen
auf SQL-Model, weil
man diese Pydentic-Modelle, die man dann halt
netterweise geschrieben hat, mit SQL-Model,
das ist auch ein Projekt von Sebastian Remires,
ist noch relativ am Anfang, also noch nicht so ganz
produktionsreif, da waren noch
so ein paar Breaking Changes drin, aber
dann kann man einfach diese Pydentic-Models
direkt in der Datenbank speichern.
und der nimmt das dann direkt und zum Beispiel
mit dem SICO-Icemi drunter
wird das halt direkt in die Datenbank geschrieben, die man da
angeschlossen hat, was halt auch sehr angenehm ist, weil man
halt diese Duplikation von der ganzen
Logik nicht mehr hat, sondern halt einfach wie
bei, wenn man das vielleicht von Dango gewohnt ist so ein bisschen,
nur so Modelle schreibt und hat
dann direkt seine Datenbank-Anastation und die Validierung
damit drin. Ja, und
das ist halt quasi das Gleiche für
Datenbank, man schreibt halt
was das ist quasi einmal
hin und dann gilt das halt für
Datenbank, also es wird
einen Datenbankschema daraus generiert, also es wird halt auch das Schema
für die API daraus generiert
und das ist halt in beiden Fällen gleich.
Das ist natürlich schon nett, also man kann sich da vielleicht schon
eine ganze Menge Schreibarbeit sparen.
Genau, man kann auch dann tatsächlich, das ist auch in FastAPI
mit drin, sich direkt das Schema daraus
rendern lassen, also
als OpenIP
kompatibles
JSON oder so, das ist direkt mit drin, muss man eigentlich
eine Funktion aufrufen, dann ist das da.
Auch sehr schick und ich mache
dabei, also mit SQL-Achimed, die Migration
ist immer mit Alembic, damit ich so ein bisschen
so eine Art Tango-mäßiges Migration-System
habe. Das heißt, kannst du dann sowas machen
wie Migrate schreiben oder so.
Das funktioniert ein bisschen anders. Da sind halt
andere Formen von
Migrationen dran, aber die schreibt man eigentlich nur an eine Datei an.
Da kann man relativ viel anpassen und der macht dann auch relativ
automatisch das Vor- und Zurückspulen.
Das finde ich ganz schick.
Ja, aber
gut, das ist aber dann irgendwie,
um diese Sachen muss man sich dann halt selber so ein bisschen kümmern.
Ja, genau. Das ist halt das, was FASAPI nicht mitliefert
im Vergleich zu Tango oder sowas, aber das
geht eigentlich auch ganz gut, wenn man es dann reinbaut.
Ja, also was den Unterschied angeht,
also wir haben ja schon
gesagt, irgendwie ist es so ähnlich wie Flask,
aber ich würde sagen, der Hauptunterschied
ist eben, dass bei Flask
man kriegt die Werte
ja relativ roh
und man hat eben nicht, weißt du,
wenn man jetzt in FastAPI
das schon annotiert hat mit, das ist ein Integer oder so,
dann kriegt man halt ein Integer.
In Flask ist das halt nicht so.
Das ist halt der, genau,
diese Pidentik-Geschichten, das könnte man
in Flask vielleicht auch so machen, aber das muss man halt selber machen,
das ist halt nicht integriert.
Ja, das ist, und
vielleicht auch noch etwas, was halt
interessant ist, wenn man
gerade so Data Science-Geschichten macht, oder halt
Dinge, die so ein bisschen anders sind als
in Django, hast du halt irgendwie
eine relationelle Datenbank da drunter, weil der ORM
ist halt so, wenn man den ORM nicht verwenden möchte,
dann macht es eigentlich gar nicht so viel Sinn, Django
zu verwenden, weil das ist halt der Hauptteil von Django.
Und
wenn man jetzt irgendwie eine MongoDB
verwenden will, oder so, oder irgendeine
andere NoSQL-Geschichte, dann ist das halt mit Django eher so. Das geht auch,
aber muss man halt... Das ist so ein bisschen pain. Das geht nicht über die Modelle.
So ein modularer Teil. Also wenn man jetzt das mit SQL-Model zum Beispiel verändert hat,
genau diese Revision, die man halt hat, die kann man ja vor und
zurück spulen und da kann man sicher alles Mögliche reinhängen.
Naja, NoSQL hat man auch nicht. Ja, Moment, aber was cool ist, du kannst
aus diesen Pydentic-Modellen, die du halt hast, kannst du auch erzeugen aus einer
OpenAPI die du halt hast wenn du eine OpenAPI hast oder sowas Ach so kannst du dir direkt die Pydentik bauen Ach okay Und so hast du dann halt dann die Sachen direkt die du dann auch in eine Datenbank wegschreiben willst
Also, das ist halt auch schon
sehr, sehr nett.
Klar, man muss sich dann halt trotzdem, wenn man das
jetzt nicht relativ ablegen will, dann irgendwie eine andere
Integration nehmen.
Ja, aber sowas geht halt prinzipiell. Während das
mit XAML eigentlich nicht wirklich geht, kannst du
halt in FastAPI, ob du jetzt irgendwie eine
Relationalen Datenbank verwendest oder halt irgendwas
oder MongoDB oder so.
Das geht beides. Und zwar
ist es nicht so, dass man das irgendwie,
dass man dann gegen das Framework arbeitet,
wenn man jetzt irgendwie NoSQL verwendet mit
FASAPI. Ja, das finde ich sehr, sehr
schick.
Genau.
FASAPI selber benutzt
MakeDocs, MKDocs. Das ist auch sehr schick.
Ja, weißt du, von wem das ist?
Nein.
Warte mal. Ich müsste jetzt einen von
den Namen sagen, die wir jetzt gerade eben schon erwähnt haben.
Von Christie ist auch.
Ja, okay.
tatsächlich. Ja, das ist echt erstaunlich.
Ja, genau.
Ja, auch ganz schick. Also ich habe
dazu ein kleines Skeleton tatsächlich mal geschrieben, so für
die kleinen Anfangssachen. Da ist so ein bisschen viel
vielleicht schon drin, ein bisschen rumgespielt.
Können wir vielleicht mal verlinken. Vielleicht mag ja jemand
den direkt benutzen, wenn er es will. Also
ist das nichts Tolles, aber ein bisschen
aus. Ich habe damit noch nicht so viel
gemacht. Ich habe mir aber vorgenommen, dass
ich das mal tun muss, weil
Ich habe so ein bisschen Dango versucht zu enthinken.
Das ist vielleicht nicht immer ganz so cool, aber
Typer ist da auch dabei. Also so Commands.
mäßig.
Was könnte man denn noch so alles erzählen über FastAPI?
Ja, also vielleicht nochmal so ein bisschen, wie das funktioniert
mit den Datentypen und den dependency-injected
Systemen. Man kann ja auch
damit sowas machen wie Permissions oder
sowas. Wie du sagen kannst, bestimmte
Dinge müssen enthalten sein, wie Authentifizierung
oder so. Ja, also diese
Magie, dass halt
irgendwie man einfach nur die
Annotationen hinschreibt und dann die Werte so
richtig bekommt.
Depends on auth.
Nein, ich wollte nur gerade, das sind halt
das funktioniert über diese
Path Operations geschehen
und das ist halt auch irgendwie
über Dependency Injection wird das halt
gemacht. Und du kannst aber auch das selber definieren,
genau, da musst du halt nur irgendwie, schreibst halt
Depends und dann übergibst du halt ein Callable
und das kriegst du dann halt den ganzen Kram.
Dann kannst du halt Code wiederverwenden,
der halt irgendwie, weiß ich nicht, irgendwas
eben ein OAuth-Token irgendwie
validiert oder so.
Oder halt irgendwas anderes macht.
An der Stelle...
Datenbankverbindung anreicht oder so.
Was ist denn ein Dependency?
Oh je, das ist auch so ein Ding.
Genau, in der letzten Episode hat da schon jemand gesagt,
ich weiß nicht, ob man das erklären kann.
Das ist halt auch so ein etwas schwieriges Konzept.
Also im Grunde...
Ist das ein Pattern? Kann man das so sagen?
Ja, das ist irgendwie ein Design-Pattern, kann man sagen.
Also wie man ein Objekt in eine Klasse reingibt, ohne dass man das jetzt mal neu definiert?
Nee, es ist eher so, dass du das halt umdrehst.
sozusagen, also Dependency
Injection ist ein bisschen
sozusagen das Ding, wie man
Dependency Inversion implementiert.
Also du willst halt nicht, also was du halt
nicht machen möchtest vielleicht ist
in deiner Funktion, die
halt irgendwie Request-Response
macht, irgendwie ein Datenbank-Ding
importieren. Und da ist
er folgendes.
Du hängst da mal rein quasi.
Genau. Und dann, was passiert jetzt eigentlich,
wenn du testest? Okay, das heißt, du musst dich mit reingeben,
und er ist dann alles abstrahiert in diesem Ding.
Genau. Und jetzt willst du das aber auch
nicht explizit irgendwie da rein,
weil du rufst ja gar nicht, du bist ja gar nicht
derjenige, der das aufruft,
deine Funktion, die halt irgendwie
Request-Response macht,
sondern das wird ja irgendwie aufgerufen. Das heißt,
du übergibst es nicht wirklich, sondern
du injectest es. Es wird halt irgendwie automatisch
depends on database access oder sowas.
Genau. Und damit sagst du halt eigentlich,
dass du das gerne injectest hättest,
sozusagen an der Stelle.
Und dann kannst du das halt
in Tests halt auch ändern. In Tests kannst du dann
einfach sagen,
in der Applikation, in der
Fast API, also dem Hauptapplikationsobjekt
kann man irgendwie sagen,
Dependency Override.
Und dann kannst du halt definieren,
was da injectet werden soll.
Und sagst halt, Depends on Database bedeutet jetzt,
gib mir einfach ein anderes Objekt
oder eine Testdatenbank. Genau, dann kannst du halt
die Testdatenbank reinreißen oder du reißt halt
irgendein Memory-Repository rein.
Genau, und
ja, das ist halt sozusagen eine Methode,
um diese Sachen
halt voneinander so zu entkoppeln.
Also eingekoppelt
wäre es halt, wenn du von irgendwas erbst oder wenn du
halt irgendwie das importierst oder so,
dann hängst du halt direkt davon ab und wenn
du es halt so indirekt reingereift bekommst,
dann bist du halt so ein bisschen losgelöst.
Ja. Und das ist halt auch in Flask
alles ein bisschen schwieriger, das ist halt
schon elegant gemacht. Wobei, ehrlich gesagt,
also ich habe mir kurz den Code
angeguckt,
also das Konzept
ist relativ elegant, aber die Implementation
ist ein bisschen...
Also da gibt es halt in FASA
wie all diese Dependencies
Modul Package und dann
der Hauptinhalt der Implementation liegt in
Utils.py und das
ist auch schon schwer zu lesen.
Ja.
Aber es funktioniert auch.
Also ich finde das, du hast schon recht,
ich habe es eben mit Def-Friendly oder sowas, also ich finde das
sehr angenehm. Ja, es ist genau, es ist halt darauf optimiert,
dass man...
und kann schnellere Ergebnisse erzeugen. Wenn du irgendwie Jason
rauspowern willst und hast nicht so viel
Aufgaben, dann kannst du vielleicht erst schnell Erfolge
damit erzielen, finde ich. Ja, absolut.
Es ist halt darauf optimiert, dass du als
Entwickler, der das benutzt, um irgendein Ziel zu erreichen,
dass du da gut zum Ziel kommst.
Und ja, diese
anderen Dinge, also das ist schon das ganze drinnen,
wenn du zum Beispiel Starlet Source gut anguckst,
also die Sachen, die Tom Christie so macht, die sind halt
alle super poliert innen
drin, ja. So ein bisschen wie bei
Apple, wenn man Apple-Geräte aufschraubt, die sind auch innen
hübsch. Also da sind auch innen die
und Jochen unterhalten sich über die Programmiersprache Python
oder irgendwie Dinge von der Decke.
Also ich habe zum Beispiel in meinem Computer, wenn ich den aufschraube,
da habe ich auch so ein paar LEDs reingebaut.
Ja, genau, ist halt auch
so ein bisschen Typfrage.
Sind auch nötig, braucht man halt nicht.
Ob man das jetzt hässlich findet oder hübsch ist.
Ja, also wichtig ist halt, dass die Luftzufuhr
vernünftig ist, dass es schön kühl ist und dass es schnell ist.
Ja, genau.
Aber auf der anderen Seite wiederum
zum Beispiel, also auch das
auch da wiederum, es ist halt unterschiedlich.
Auch der Source Code hat kaum Kommentare
oder so.
Docstrings gibt es fast
gar nicht. Ich habe vielleicht zwei, drei Stellen gefunden, wo welche
drin sind und Kommentare gibt es eigentlich auch nicht.
Das bin ich auch schon ein paar Mal
drüber gestolpert, ich muss mal gucken. Aber dafür
sind halt die Type Annotations
so aussagekräftig schon
oft.
Ja, aber auch da, das ist halt so ein bisschen
ja, sie sind aussagekräftig und ja,
wenn du das im Editor mit, der das unterstützt,
benutzt, dann ist das halt
dann ist das für dich halt total cool
ehrlich gesagt, aber den Code einfacher
zu lesen macht das jetzt nicht.
Ich muss auch sagen, den Code selber, wenn ich da reinguckt habe
muss ich ein bisschen suchen, was macht der denn jetzt.
Ja, dann geht das alles über
Keyword-Only
Argumente
was ja auch irgendwie
also es ist klar, dass das halt für jemanden
der eine IDE benutzt, vielleicht besser so ist
wenn er halt Funktionen aufruft oder Dinge
die halt Keyword-Only sind
also das heißt, alle Funktionen und Metaphone fangen an
mit irgendwas Stern,
Komma irgendwie. Aber für jemanden,
der so
von früher hätte man gesagt, oh mein Gott,
was ist das denn? Das ist ja schrecklich hässlich.
Warum nicht einfach hinschreiben?
Aber
es ist halt so ein bisschen
du verbietest ja mit diesem Stern
erstmal, dass es irgendwelche Argumente gibt, außer den
Keyword-Dingern. Auf der anderen Seite ist es
natürlich so, wenn ein IDE dann halt
anbieten kann, was du alles auswählen kannst
an Dingen, die du da reingibst, ist es natürlich für dich
irgendwie angenehmer. Also sozusagen deine
Entwickler Experience, wenn du das in der IDE verwendest, ist halt besser, aber wenn du das jetzt in den Source Code liest, ist es eher so ein bisschen ikidigit.
Ja, so sag ich mal.
Ikidigit.
Ja, vielleicht wird man damit schnell arbeiten.
Ja, also ich meine, heutzutage benutzen die Leute halt alle Idees und gucken halt darüber, was der Code denn macht.
und so. Wenn du dann halt
aber mit einem VI da sitzt und
den Source Code liest, dann denkst du dir so,
was ist das denn? Ich verstehe diese modernen Zeiten nicht mehr.
Ja.
Hängt es. Aber
ja. Der VI kann das ja wahrscheinlich
jetzt auch mit Autocompletion auf den Quarks und so.
Kann man auch alles machen,
wenn man da die entsprechenden Plugins richtig konfiguriert
hat, was ein paar Monate
passen wird.
Ich habe immer zu wenig Zeit, an das neben der Arbeit noch hinzukommen.
Naja, also
ich finde es interessant.
Also es ist auf jeden Fall
ein bisschen was anderes.
Ich mag es sehr gerne.
Zum Benutzen und zum Anfassen,
das gibt einem so ein bisschen Speed auf der Straße.
Ja, das auf jeden Fall.
Also ich meine, Pydentic ist auch sowas.
Das hilft einem enorm.
Ich finde auch, ehrlich gesagt,
immer wenn ich jetzt so
Altklassen im alten Style
verwende, oder ich meine, ich habe auch
schon häufiger mal irgendwie
Atteris verwendet.
Das war ein normaler Episode.
Oder Dataclasses.
und das macht schon
einfach angenehmer, das so hinzuschreiben.
Dass halt die Sachen
als Attribute direkt
in die Klasse reinschreibst und nicht
in Init und dann das nochmal
setzt. Das ist halt immer so ein bisschen umständlich.
Jaja, das ist also ein bisschen
wie
die neue Variante von dem Tubel.
Auf der anderen Seite
muss man, ich habe jetzt nochmal geguckt,
weil es gab jetzt bei DDF,
da war ich,
warst du da?
Ich konnte nicht, da hatte jemand Geburtstag.
Ach ja, richtig.
Genau, ich habe mir das Video
so teilweise angeguckt,
weil mich interessiert hat,
weil Klaus gesprochen hat
über wie schnell
ist eigentlich Data Class im Vergleich zu einem alten...
Genau, er hat herausgefunden, dass Palentik ein bisschen langsamer ist
bei der Umformung von vielen Transaktionen.
Kann das sein?
Nee, der hatte Palentik gar nicht.
Ich hatte mal so ein Video gepostet, wo das verglichen wurde.
Und ja,
also tatsächlich Data Class
auch ein bisschen langsamer. Die waren früher
viel, viel langsamer, sind inzwischen gar nicht mehr
so schrecklich viel langsamer.
Ein bisschen langsamer sind sie aber. Und bei
Pydentic habe ich es jetzt selber nochmal nachgeguckt, weil mich das
interessiert hat, weil ich dachte so, okay, wie schlimm ist
es denn eigentlich?
Gut, ich habe das jetzt in meinem
kleine Objekt genommen,
wo nicht viel Validierung drauf ist,
aber ich dachte, gut,
ehrlich gesagt kann es dann ja nicht mehr besser werden für
Pydentic, sondern es wird eher schlimmer,
aber da war der Unterschied schon relativ
riesig. Also da ist es
halt so beim
Deserialisieren,
also quasi du hast
sowas wie JSON oder Dict. Ich habe immer Dict genommen, nicht JSON,
weil ich wollte jetzt nicht die JSON-Library
branchmarken, sondern einfach nur von Dict
zu irgendwie Objekt.
Es ist so, dass Pydentic ist halt
irgendwie so achtmal langsamer.
Und beim
Serialisieren, also von
Objekt-Technologie zu
Dict, ist es
halt sogar irgendwie 20 mal langsamer.
und das ist natürlich schon, also es kommt drauf an.
Bei wann wird das dann relevant?
Genau, das ist halt die Frage.
Das ist halt, also ich meine,
irgendwie Serialisieren von
100 Objekten, ich weiß
jetzt gar nicht mehr genau, bis ich jetzt nachgucke,
aber es war halt irgendwie so,
für einzelne Objekte so ein paar hundert
Nanosekunden.
Bei Nativ
und Pydentic ist halt dann so, geht in den
Mikrosekundenbereich, also was ich nicht koste,
dann halt irgendwie 4-5 Mikrosekunden.
Das ist alles relativ
und Jochen unterhalten sich über die Programmiersprache Python
kostet halt auch ganz schön. Wobei, ich
weiß es nicht genau. Vielleicht habe ich es auch noch irgendwie falsch bedient.
Das kann auch sein. Und
vielleicht gibt es da auch noch irgendwie
Geschichten, wie man das schneller machen kann,
dass man halt irgendwie noch was...
Ich weiß es nicht. Vielleicht hat das noch
irgendwelche Dinge, wo man das
modellieren kann, wo dann irgendwas zu Zeiten
kompiliert wird oder wo es Zeiten zu zählen...
Ich weiß es nicht genau.
Aber, also, wenn man
das
verwendet, sollte man sich vielleicht schon klar sein, dass es
unter Umständen ein gutes Stückchen langsamer ist,
als die alte Art ist zu machen.
Aber es ist auch viel komfortabler.
Die meisten haben ja auch keine Last
und haben auch nicht viele Objekte.
Insofern ist alles viel besser.
Ja, ich habe gestern noch wieder jemanden gehabt,
der kein Python konnte.
Ja, ich habe gehört, dass es voll langsam war,
weil es die erste Erklärung gibt.
Ja, das hören immer viele.
Aber es ist halt die Frage, was das denn bedeutet
und in welcher Hinsicht langsam.
Das muss man dann halt ein bisschen auseinander dividieren.
Und meine Ansicht dazu ist ja so,
Wenn du mir genau sagen kannst, was du haben willst, dann kann ich dir sagen, wie du es hinkriegst.
Und dann kannst du so schnell sein, wie du sein willst.
Also ich kann mir nicht vorstellen, dass du mit irgendwas anderem sehr viel schneller bist.
Ja, aber das ist halt wahrscheinlich der Punkt, dass die Leute gar nicht den Andenksfall genau verstehen.
Und warum Python dann da vielleicht langsamer ist, wenn man es falsch macht.
Wenn du keine Ahnung hast und irgendwas machst, dann kann es sein, dass es hinterher langsamer ist.
Ja, genau.
Das stimmt halt auch für alles andere.
Ja, so insofern.
Ja.
Genau.
Ja, also schöne Sachen,
also um tatsächlich, wenn du irgendwie einfach sagst,
du willst einen Dick draus geben,
ist das direkt JSON und so, also FASAP ist schon
irgendwie eine schöne Sache für sowas, ich mag das.
Ja, genau.
Ah, vielleicht
die ganze Async-Geschichte.
Genau, normalerweise
sind halt, oder was heißt normalerweise,
aber üblicherweise hast
du ja dann, also wenn
machst du ja dann Async, definierst du dann
Funktionen als Async und so, dann kann das alles schön
sozusagen zumindest IOMäßig parallel gemacht werden.
Jetzt hätte ich mal eine Frage. Ich habe eine ganz fiese, gemeine Frage.
Okay.
Was macht eigentlich...
Du kannst aber auch in FastAPI ja
Normalfunktionen so definieren.
Oder wenn du auf die Datenbank zugreifst, dann ist das ja auch synchron alles.
Mhm.
Und dann kannst du ja eigentlich nicht mehr Async,
deine Funktionen Async definieren und Await sagen,
sondern du musst das halt so aufrufen.
Und das funktioniert ja auch einfach so.
Mhm.
und wie macht, oder was, warum geht das eigentlich?
Oder wie macht FastAPI das eigentlich, dass wenn du jetzt ganz viele,
sagen wir mal so, es kommen ganz viele Requests parallel rein,
sozusagen, und jetzt hast du da diese Funktionen, die synchron sind,
die sind ja nicht als iSync irgendwas definiert,
und die blockieren also, die blockieren ja alles andere.
Wie kann es denn sein, dass FastAPI dann trotzdem nicht viel langsamer wird?
Was es tatsächlich nicht wird.
Gute Frage.
mit der Session. Ich weiß nicht, wie das
regelmäßig für die Dortmunder geht.
Ja, da dachte ich auch so,
als ich das gesehen hatte,
dass FastAPI, dass man
beides verwenden kann und es auch irgendwie magisch funktioniert
und auch nicht schlechter wird von der Performance
her, wenn man das irgendwie synchron definiert.
Hä, wie macht denn der das?
Da musste ich an der FastAPI-Dokumentation ein bisschen
kramen, bis ich das gefunden habe.
Und über zwei, dreimal,
es gibt irgendwie Concurrency, Parallelism
gibt es einen Teil in der Doku
und dann kommt so die erste Warnung jetzt ab,
und Jochen unterhalten sich über die Programmiersprache Python
man das richtig macht und
FastAPI importiert dann das RedPool aus Salad,
dann funktioniert das auch schnell.
Aber wenn man
halt sozusagen wirklich Ressourcen
schonend das machen will, dann
macht es schon Sinn, da async-Geschichten
Funktionen zu verwenden.
Dann ist es halt direkt
nochmal ein Stückchen eleganter.
Noch schicker.
Und dann sind halt Core-Routinen und Nichts-Weiß-Sets
schon immer noch ein bisschen mehr Overhead.
Was auch gut geht,
das hat man ja sonst immer auch
irgendwie
sind so Geschichten
Background-Tasks. Oh ja, Background-Tasks.
Ist ja relativ easy, ne?
Ja. Kannst einfach so eine Queue haben
und dann geht rein und sagst du, was ist das?
Dekorator? Oder ein Dependency
du reingibst, Background-Tasks, und dann
hängst du was rein und das läuft dann einfach?
Du musst da am Anfang einmal initiieren, oder?
Nee, nee, nee. Du sagst, das hier ist
ein Background-Task und dann
waitest du dann. Ah ja, okay.
Also es kann eine beliebige Async-Funktion sein und
genau.
Ich weiß es jetzt aber nicht mehr genau, aber im Grunde ist es auch schon eine Funktion, die installiert drin ist
und damit kannst du halt so Dinge
aber die müssen halt, ich glaube die müssen
dann aber auch, kann die auch synchron sein?
Das weiß ich jetzt gar nicht.
Ich glaube es geht sogar synchron, aber ich bin auch nicht.
Kann auch sein, ja, ich meine es gibt ja diesen Thread-Project, da kannst du auch mal einen Thread machen.
Aber für viele einfache Fälle,
also das Problem ist natürlich, wenn du da jetzt irgendwas
sehr CPU-intensives drin machst,
das geht natürlich eigentlich da nicht.
aber wenn du darin nur irgendwas machst, wo du auf
I.O. wartest, also du machst eigentlich nicht wirklich was, sondern
du wartest nur,
dann ist das natürlich sehr bequem, dass du
das halt direkt integriert hast und nicht wie
also was man in Django und so macht, dann nimmt man halt so
Salary oder sowas oder irgendeine andere Task-Queue
und dann startet man halt, schmeißt man das
irgendwas mal in die Queue, dann gibt es irgendwie andere
Dinge, die holen sich das aus der Queue dann wieder raus.
Ja und dann in die Queue schmeißt man es halt erstmal weg, realisiert
irgendwie ein String-Format
und das überhä.
Ja gut, also es gibt halt Dinge, für die geht es nicht anders,
geht das auch mit First-Paper, ging jetzt nicht. Also wenn du
einen Berechnungsjob machst, dann
das kannst du halt nicht in deinem Web-Server-Prozess machen,
weil wenn du das machst, dann machst du halt sonst nichts mehr.
Dann kannst du nicht mehr auf Requests antworten, was
natürlich... Ja, und irgendwie muss man es ja dann realisieren,
damit es irgendwie abgespeichert werden kann zwischendurch, aber...
Genau, genau.
Und wenn du es in einem anderen Prozess machen willst, dann musst du
irgendwie das realisieren und dann irgendwo anders
aufrufen.
Insofern, es gibt halt
diverse Fälle, in denen kommst du nicht drum rum, aber
für viele kleinere Sachen, du willst eine E-Mail wegschicken
oder du willst halt einfach nur
Kurze Berechnung.
Berechnung ist nicht so gut, aber
du machst halt irgendwas, du machst eine andere API ab
oder du schickst irgendwas irgendwo hin oder so,
dann ist egal, dann kannst du das halt
machen. Und das dürften die allermeisten
Fälle sein eigentlich.
Also das ist halt auch integriert.
Dann, was
auch integriert ist, ist halt statisch false,
auch wieder aus Twilight, aber
genau, den Code habe ich mal
geklaut für diese Django
Async-File-Response-Geschichten.
und
ja, das ist, du kannst halt
dadurch, dass das halt so
effizient geht mit
libuv, uvloop, uvcon
kannst du halt auch Filesorven, was du
normalerweise in einem Applikationsserver nie machen würdest,
aber dadurch, dass jetzt halt nichts
mehr kostet, irgendwie eine Verbindung auf, also
weil das Problem bei
Filesorving ist halt, das sind halt Requests, die lange
laufen. Also normalerweise macht das von außen an der
Webserver, also keine Ahnung, der Nginx oder
ein Apache oder sonst irgendwas
oder dein CDN.
Weil
wenn ein Applikationsserver
lange Zeit
im Request ausliefert, dann ist der halt belegt
und kann sonst nichts mehr machen. Und du hast normalerweise
immer nur so ein paar. Und wenn dann halt
mehrere Leute irgendwie Files runterladen,
dann ist
deine Webseite halt nicht mehr erreichbar.
Das ist halt schlecht. Daher normalerweise
statisch Files ausliefern machst du halt von woanders.
Aber wenn du jetzt irgendwie
das effizient
IO machen kannst, dann
macht das ja nichts.
Dann kann das halt auch dein Applikationsserver machen
und deswegen statisch verhaltsausliefern kannst du
einfach so vom Applikationsserver
aus, was natürlich
total cool ist, weil du kannst nämlich
dann auch die ganzen anderen Sachen machen, die halt man so
vielleicht auch
braucht, die sonst halt sehr schwierig sind, wie sowas
wie Authentifizierung und
Autorisierung und so. Das ist halt,
wenn das ein anderer Server macht als dein Applikationsserver,
eher ätzend
und so geht das halt
relativ einfach.
mit den Dekoratoren, die halt die Routen
verbinden, dass du halt so Router hast, so ein bisschen wie
du es in Flask kennst.
Ja, aber auch tatsächlich ein bisschen, es gibt
sogar dann, ich glaube, das gibt es in Flask
nicht, aber wahrscheinlich erzähle ich jetzt Unsinn, ich habe keine Ahnung von Flask,
aber dass du das
aufbilden kannst in unterschiedliche,
dass du sagen kannst, hier ab die,
unter diesem Pfad,
dafür ist dieser Router zuständig. Genau, du kannst halt die Router
unter dir, der kann da auch unterschiedliche Regeln dann
versetzen oder Authentifizierung für einen Router verlangen
oder sowas alles. Du kannst die Responses
dafür definieren, die du halt haben willst,
für den Router, die da rausgegeben werden und sowas.
Das dient voll vieler Kurzen.
Ja, das ist...
Damit kannst du eigentlich deine ganze Applikation halt irgendwie h aufteilen Genau ja Und etwas was es in Flask gibt was es in FastAPI nicht gibt ist so ein Plug Also ich meine das ist halt die Frage wie teilst du Sachen auf In Django w man das
mit Django-Apps vielleicht machen, in Flask hast du
halt diese Plugins und
in FastAPI hast du wieder noch.
Aber du hast halt einmal die Möglichkeit
über die Router das aufzuteilen und dann noch
die andere Möglichkeit ist halt, über Dependency-Injection
das zu machen.
Ja, man kriegt ja schon irgendwie so eine hübsche Applikationsstruktur
dann damit hin.
Ja.
Also ich finde das
ganz nett, also vielleicht darzustellen nochmal zu Typer,
also das ist auch ein Projekt von Sebastian Ramirez von
Tianjulu, dass das so ähnlich macht,
das setzt auf Click auf und macht halt auch mit
Type Annotation so eine Kommandozeilen
Geschichte, die so ein bisschen ähnlich funktioniert wie
FastAPI. Ja. Und das
in der Kombination ist halt irgendwie sehr, sehr nett, weil man
halt irgendwie damit dann
seine Applikation steuern kann und
Ja, gefällt mir auch sehr gut.
Ja, verwende ich
auch schon ein paar Mal verwendet.
Das ist irgendwie so sehr charmant, falls ihr das kennt, das macht irgendwie Spaß damit zu arbeiten. Das ist diese Developer Experience, mit der ich halt mag, irgendwie so modern zu arbeiten mit den ganzen modernen Tools. Da bin ich auch, also ich muss das nicht schwierig haben. Das ist irgendwie nervig. Also ja, man kann durch den Berg boxen und dann, ja, I'm the Hero, ich habe das Schwert rausgezogen. Ja, ich kann mit meiner Zeit Besseres anfangen.
Ja, naja
Ich meine, die anderen Sachen haben ja auch
so ein bisschen was für sich
Du meinst jetzt einen charmanten
Tatsächlich bist du dann halt eben nicht auf eine Idee angewiesen
zum Beispiel
und du kannst halt schöner allgemeiner
Ja, aber ich weiß nicht, ob das jetzt ein Feature
oder ein Feed ist, dass ich nicht auf eine Idee
angewiesen sein muss, also come on
Ja
Ja, inzwischen bin ich da ja nicht mehr so, aber
Wenn du mit meinem VI gestrandet auf meinem Telefon sitzt, okay, maybe
Nein, aber ich meine, vor ein paar Jahren hätte ich dann auch gesagt, so, Idee ist das, alles Quatsch, auch keiner, VI, ja
Aber inzwischen, ich meine, ich habe ja einfach mir dann vorgenommen, okay, bevor ich dann irgendwie mal so
So Rente
So Rente, muss ich das mal ausprobiert haben und habe dann jetzt mehr Peitschamen gemacht, mehr VS Code und muss sagen, ach ja, ist eigentlich schon ganz okay
Ich probiere es ja gerade den anderen Weg herum.
Ich versuche gerade ein bisschen wie Eis zu lernen nochmal.
Aber ja, das heißt halt, die
Konfiguration ist ein bisschen pain, aber wenn man einmal
durchgestiegen ist, dann geht es ein bisschen. Aber ich sage mal,
das Produktivitätslevel ist schon ganz nett
für bestimmte TAS, aber für bestimmte TAS halt einfach
auch nicht.
Ja, also genau.
Es gibt Gründe, warum es so ist,
wie es ist und das ist auch eigentlich gut.
Aber ach, naja,
vielleicht rumhert die...
Ich glaube, wenn man neu anfängt,
dann macht man das vielleicht
einfach gar nicht.
Die ganzen
was haben wir denn?
Achso, Flask auch
irgendwie gibt
jedenfalls die alte, also Flask
2.0 ist ja auch noch nicht so lange her.
Das kann auch SGI,
aber Flask war sehr stark
an WSGI
dran gebunden und deswegen
ist eigentlich
Flask unter
2, das wird mit SGI nie funktionieren.
Das ist immer fest.
auch. Deswegen nimmt man ja neue Software.
Genau, also insofern, das ist halt so was,
wenn man jetzt irgendwie was mit WebSockets machen
wollen würde.
Ich glaube, WebSockets hat man auch noch nicht so richtig.
Dann ist Flask, also jedenfalls
das alte Flask, nicht unbedingt, ich glaube,
Flask 2.0 geht vielleicht und
Quad geht halt auch.
Vielleicht ist Quad in Flask 2.0
aufgegangen, ich weiß es gar nicht mehr so genau.
Aber
das alte geht auf jeden Fall nicht so richtig.
Genau, FastAPI,
kein Problem, geht einfach so.
und das ist natürlich auch nett, weil für manche Sachen
braucht man das ja vielleicht schon.
Wobei ich da inzwischen so ein bisschen,
ich habe das ja auch benutzt und habe
extra,
gut, wenn man FastAPI
machen möchte, dann kann man natürlich auch
mit allen
Pfeifen und
Whistles und Websocket
und so machen,
dachte ich dann und habe das dann halt auch mal
benutzt.
Du hast auch ein Tutorial dafür gemacht auf YouTube, glaube ich,
wo das ein bisschen gezeigt wird, FastAPI
Habe ich das mal gemacht?
Zumindest das Topic, was du dann wirklich gemacht hast.
Ich glaube, das ist einfach nur gestreamt.
Das Einzige, wo ich
mir mal was geplant habe, war
zu NaiveBase implementieren.
Da habe ich vorher überlegt, was ich dann implementieren will eigentlich.
Die ganzen anderen Streams sind alle
einfach nur so, ja, alle furchtbar.
So kann man es auch umschreiben.
Oder es ist einfach nur so, ich setze mich hin und programmiere irgendwas.
Und das ist natürlich manchmal spannend, häufig
total langweilig. Aber
für mich, der Vorteil dabei ist, wenig
Verbreitungsaufwand.
Man kann das sehen, also wenn ihr Jochen mal sehen wollt, dann könnt ihr mal reingucken.
Ja, vielleicht
sollte ich aber ein bisschen mehr
besser produzierte Geschichten machen, das ist
vielleicht gar nicht so blöd. Ich habe ja sowieso nicht so
viel Zeit mehr, irgendwie Streams zu machen.
Wir haben gehört, du sollst einen Didaktik-Code machen, Jochen, haben wir eine Empfehlung
bekommen. Ja, genau,
die ganzen R's und Ö's.
Ja, das ist schlimm.
Ich wäre eher für Didaktik, also ich finde die R's ein bisschen zu schlimm.
Ja, gut.
Eigentlich am besten alles
austauschen, Didaktik, Rhetorik,
das Gesicht.
Ja, ich verstehe schon
Ja, ein bisschen schminke ich hier und da
Ja, also
jetzt, ich komme sowieso nicht mehr so häufig
zum Streamen daher oder habe das auch noch nicht geschafft
irgendwie ein Schedule hinzukriegen, wo der irgendwie
funktioniert, daher vielleicht
mache ich das einfach so, dann habe ich ja in der Zeit, wo ich
bereite ich vielleicht was vor und dann mache
ich das halt irgendwie mal ein bisschen besser vorbereitet und dann halt
seltener. Einmal die Woche reicht vielleicht
Einmal die Woche oder alle zwei Wochen oder sowas und dann halt
dafür aber vielleicht irgendein Thema ein bisschen fokussierter
und ja
Der kann es auf die Gäste einladen, wie mich.
Ja, gerne.
Aber everyday bin ich raus, wenn du da
anfängst, deine Tests neu zu schreiben
oder irgendwelche Pakete nachzunstallieren.
Ja.
Ist ja auch mal nett zu sehen.
Wir haben jetzt davon 100 Folgen
oder was archiviert auf unserer Podcast-YouTube-Seite.
Ja.
Das war schon einiges.
Ja, schon einiges.
Ja, klar.
Genau.
Was hatte ich noch?
Ach genau, WebSockets.
Dafür hatte ich Websocket so ein bisschen verwendet
und
ich dachte so, okay, wenn man das
verwenden kann, das wäre voll cool, dann machen wir das einfach so
und inzwischen
Das geht tatsächlich ganz gut mit CastApp, gell?
Das geht auch sehr gut, ja, also wenn man so einen Anwendungsteil
dafür hat. Aber in diesem Websocket
ist das prinzipiell auf die Nerven gegangen, habe ich gemerkt.
Nee, prinzipiell, also es war
schwieriger, als ich jetzt gedacht hätte. Ich bin da
auf viele Dinge gestoßen, wo ich
schon das Gefühl habe, so, weia,
das ist gar nicht so einfach und
also fängt halt schon, also und zwar
nicht nur auf der Serverseite, muss man halt aufpassen.
Wenn man da halt irgendwie was verwendet, was halt nicht gut
damit klarkommt, dass man halt
immer eine Verbindung offen halten muss,
dann ist es halt schlecht.
Also wenn man halt irgendwie so
sich darüber keine Gedanken macht,
und benutzt halt einfach WebSockers einfach so,
dann
kriegt man Probleme. Mit FastDTA geht
das, aber naja. Und dann ist halt die Frage,
wie gut kann man das so verwenden?
Das geht mit FastDTA auch ganz gut.
Und
und dann ist aber noch die Client-Seite, das ist auch schwierig.
Das ist halt nicht so richtig einfach, weil was passiert zum Beispiel,
wenn jetzt die Server-Seite sich neu startet?
Du musst eine neue Verbindung bekommen.
Ja, du musst halt retryen, weil ansonsten, wenn du einfach nichts machst,
dann ist die Verbindung halt weg.
Oh, weg, tot.
Genau, du kriegst einfach keine Apps mehr.
Aus die Maus, danke, nein, das war's, tschüss.
Ja, das heißt, du musst reconnecten.
So, jetzt seht ihr das erste Reconnect vielleicht nicht,
dann, okay, vielleicht noch ein zweites.
Dann gibt es halt unterschiedliche Sachen, die auftreten können.
Auf die musst du irgendwie reagieren.
dann und dann
dann
ja
auch auf der Serverseite auch wieder so ein Problem
du musst halt dann die Sachen
du weißt ja nicht unter Umständen wo du dann landest
also entweder du hast nur einen einzigen Prozess
das ist aber vielleicht dann noch ein bisschen wenig
oder du musst halt dafür sorgen, dass die alle gleich sind
irgendwie in gewisser Weise, dass du auf alle
connecten kannst und es immer das gleiche dann passiert
ach ja
aber so wirklich
also was dann wirklich
so ein bisschen so Softwarearchitekturproblem wird
ist halt sowas wie
du kriegst jetzt die unterschiedlichen Informationen
rein, halt einmal über den Websocket, kriegst du halt irgendwelche Events,
dass irgendwas passiert ist, du holst
aber auch manchmal Sachen. Und manchmal sind das ja die gleichen
Informationen. Nur im einen Fall holst du sie halt
über so eine HTTP-JSON-API
und im anderen Fall kriegst du es halt über den Websocket
rein. Und jetzt musst du das halt irgendwie so
chronisieren und darfst halt nicht Sachen doppelt zählen
oder so. Und dann musst du das halt
irgendwie abstrahieren, dass du in dem
Teil,
wo du halt deine Wahrheit
über den Application State halt hältst,
zum Beispiel in Vue, in so einem
Pinia-Store oder sowas,
musst du halt so
Web-Apps installieren, dass es dir an der Stelle egal sein kann,
ob das jetzt über einen Web-Socket kam oder woanders her oder so
und dann musst du halt anfangen so,
musst du halt schon ein Software-Stick vor machen, so ein Frontend.
Frontend!
Oh nein!
Wer macht denn das?
Backend schon nicht so richtig hin und wer macht das denn sauber?
Pinia war ein guter Sighted, das ist nämlich
für einen Superstore, ich finde den auch sehr viel
angenehmer zu schreiben als Vue-X,
die man für VJS nehmen kann, ja.
Ja, gefällt mir auch sehr gut, aber
tatsächlich irgendwie
manchmal habe ich auch so Dinge, wo ich denke, oh okay,
der Zustand ist jetzt aber nicht, warum steht denn da
irgendwas übrig geblieben und da ist irgendwas inkonsistent,
wie ist das denn passiert? Das kann ja jetzt eigentlich gar nicht sein.
Es ist schon so ein bisschen
hakelig und man muss
darüber nachdenken und es ist alles nicht mehr so einfach.
Also das ist, hätte ich jetzt
gar nicht so erwartet, dass das so
kompliziert auch ist irgendwie.
Aber es ist halt tatsächlich...
Ich habe ehrlich gesagt aufs Date immer noch nicht so genau verstanden.
Also es ist irgendwas, irgendeine Wahrheit hat
irgendwer in der Hand und der hat den Ball nicht in die
richtige Stelle geschmissen und die Frage ist, wer
sammelt denn alle Bälle ein, um hinterher die wieder
weiter zu verteilen. Also irgendwie so. Das ist so ein bisschen doof.
Ja, es ist halt
das, woraus quasi dann
das, was du von der Applikation siehst,
gerendert wird. Und wenn sich das ändern sollte,
Ja, das Ding ist, was du sagst.
Wer weiß das denn überhaupt? Manche Leute
erinnern ja irgendwas, obwohl es gar nicht stimmt.
Was auch nicht immer falsch sein muss,
vielleicht. Vielleicht muss man auch manchmal
da gucken, was ist denn wichtiger?
Dass man lange wartet, bis man weiß, was wahr ist?
Nö, man kann ja auch einfach dann so tun, als
man das schon weiß. Genau, ja, ja, ja.
Und das stimmt ja vielleicht oft auch. Vielleicht ja manchmal auch nicht.
Und was macht man denn dann? Und so, und ja.
Ja, aber es wird halt schnell
kompliziert. Und
genau, also das fand ich schon
ja so ein bisschen, also hätte ich jetzt
nicht so erwartet, dass es so schlimm ist. Und dann
eine andere Geschichte, die halt auch dann
irgendwann, ich hätte
nicht erwartet, dass es so leicht ist
irgendwie Polling zu
verwenden. Also jetzt mit
HTMLX zum Beispiel
ist es halt super easy
irgendwie, weil, also was ich
früher halt so gesagt hatte, so oh Pollen, oh mein Gott,
also einmal, das macht viel Last auf dem Server, weil du pollst ja die ganze
Zeit, ne, wenn jetzt viele Leute auf deiner Seite sind,
dann pollen die die ganze Zeit, super,
super toll, irgendwie habe ich irgendwie
viel mehr Requests, als ich eigentlich
bräuchte und so.
Da muss ich dafür sicherstellen,
muss ich irgendwie sicherstellen, dass das JavaScript auch irgendwann aufhört
zu pollen.
Du hast ja auch schon darüber gesprochen,
abholen, also will man überhaupt nicht machen.
Genau, aber habe ich jetzt inzwischen
dann doch, glaube ich, meine Meinung geändert, weil
wenn man das halt so einfach hinschreiben kann wie
in HTMLX, wo man schreibt halt every
two seconds oder so, schreibt man
ein Attribut, das war's. Mehr macht man
gar nicht. Und auf der Serverseite
schickt man halt, also man kontrolliert es
von der Serverseite aus und nicht von der JavaScript-Seite aus
und von der Serverseite aus schickt man halt
so einen Statuscode 286
zurück, so irgendwie, ich weiß nicht,
der heißt irgendwie auch sowas wie Top-Polling oder sowas
und dann hört es einfach auf.
und in dem Startpoint steht dann, wie lange, glaube ich,
sogar, ne? Ja, kann man alles irgendwie
setzen, aber man kann halt auch... Ja, derweil
ich glaube, wenn du einen bestimmten Code machst,
also ich glaube 4.19 kann das auch sein,
dass man dann sagt, hey, hör auf jetzt,
wie lange, sonst wirst du gebannt oder so.
4, wie hieß das, der Client hat irgendwas falsch gemacht,
ich weiß es nicht so genau, keine Ahnung, aber ja, man kann
da auf jeden Fall viel machen und
man kann sogar das halt einfach so machen,
dass man das Element, was halt poilt
oder so einfach austauscht im AutoHTML
und dann kann man einfach
das Poll-Ding wegnehmen. Also 9. ist ja
Authentication Timeout. Und sobald jemand auf irgendwas anderes draufdrückt, kann man out of band
aber das Polling ja wieder aktivieren und so. Das heißt, also eigentlich für ganz
viele Fälle, wo man halt mal eine Zeit lang irgendwie so Live-Updates oder so braucht auf einer Seite,
kann man das mit Polling relativ schmerzfrei machen.
Und das war mir vorher nicht so klar. Da hätte ich gedacht, oh Mann, das ist ja alles ganz furchtbar.
Und da würde ich jetzt sagen, eben aus der HTMX-Erfahrung heraus, würde ich sagen,
also das ist gar nicht so schlimm. Das geht eigentlich relativ gut. Und der Riesenvorteil ist halt,
das ist komplett stateless, es funktioniert mit ganzem Standardkram, den man halt so verwendet, braucht nicht irgendwie SGI oder Django Channels oder sonst irgendwas, es funktioniert mit dem ganz normalen.
Also doch einfach Pollen machen.
Ja, und dann, ja.
Vielleicht doch lifer, als man denkt.
Also da ist jetzt nur die Frage halt, wenn man viele Clients hat, die einen pollen wollen, ist das vielleicht dann doch doof.
Ja, aber man hat das ja unter Kontrolle
Wenn du sagst, okay, das ist mir jetzt zu viel
dann sagst du halt, okay, dann polygale ich nicht jede Sekunde
sondern alle zwei Sekunden hast du schon die Last um die Hälfte gesenkt
Ja gut, aber wenn trotzdem
eine Million Leute alle zwei Sekunden fragen
ist vielleicht doof, weil es so viele auf einmal sind
Du kannst ja dann irgendwann einen Mehrserver kaufen und kannst dir dann überlegen, was du machst
Ja, okay, genau, aber das ist halt dann
man weiß dann an welcher
Linie des Problems, an welcher Achse man sich dann abarbeiten kann
Ja
Also das war schon so ein bisschen
Wenn ich mit dem Wissen von jetzt würde ich das nicht nochmal
mit wegsocken
Aber jetzt habe ich es halt schon gemacht.
Ja, weil ihr könnt ja sehen, wie Jochen es versucht hat.
Das ist ja auch manchmal ganz amüsant.
Dann hast du hoffentlich noch einen Pick.
Ah, Picks. Dann machen wir jetzt Picks.
Ja, gut.
Ja, also mein Pick für diesmal wäre
Honcho.
Honcho, ist das eine Insel?
Nee, das ist...
Hauptinsel.
Ich weiß gar nicht, wo der Name herkommt, ehrlich gesagt.
Jetzt grübel ich da gerade.
Nee, das ist, es gibt in Ruby, in der Ruby-Welt gibt es ein Ding, das nennt sich Formen.
Aha.
Ist da relativ populär und Honshu ist das auf der Python, ist eine Python-Nachimplementation
davon und das benutzt man, um ein Proc-File zu lesen und dann Dinge, die darin stehen,
zu starten und zu stoppen.
Also quasi, wenn man jetzt sowas, man kennt das vielleicht mit Docker-Compose, Docker-Compose
minus f irgendeine Config, YAML-Config
up und down und so, dann passiert auch
sowas, dann werden alle die Dinger hochgefahren oder die runtergefahren
oder so. Also alle Docker-Container in der Composer-Granche
in YAML. Genau, jetzt möchte man aber vielleicht zum Beispiel
mal irgendwie
so wie ich Docker ganz
so, ja,
ich drücke mich das jetzt aus,
wenn man es nicht so gut findet,
nicht so gut, eher so mittel findet,
dann, und das nicht verwenden möchte,
und dann sagt jemand, ja, ich habe ja schon diese Funktion
gerne, dass ich halt mein komplettes System,
sich zu entwickeln, so brauche ich einmal hochfahren und einmal runterfahren
kann und so. Dann kann man das
halt in so ein Proc-File reinschreiben,
was man alles dafür hochfahren muss und runterfahren muss
und dann nimmt man Honshu und sagt Honshu start
und dann passiert halt quasi genau das gleiche wie mit Docker-Corpus
ab. Okay, cool. Und
ja, nur dass es halt nicht Docker ist, sondern
dass dann einfach ganz normale Prozesse gestartet werden
und Proc-File hat halt auch den Format
diverse Hosts, da können das direkt lesen, Heroku kann das direkt lesen
und so.
Und dann kann man sich so eine Konfiguration bauen und dann werden
auf dem Rechner Sachen hoch und runter gefahren.
Ich meine, der Nachteil ist natürlich, es ist nicht isoliert, der Vorteil ist
natürlich ist nicht isoliert.
Ja, zum Beispiel
ein Pattern, was ich halt in letzter Zeit,
wenn ich meine Sachen mache, tatsächlich
viele Dinge, die ich halt so
bezahlt tue,
da ist es eigentlich seit Jahren
immer Docker.
Ist es besser geworden?
Davor war es mal eine Zeit lang Vagrant
und Virtualbox
und so, das war noch schrecklicher als Docker.
Aber Docker
ist auch ziemlich schlimm.
Ist jetzt auch bezahlt übrigens, für Corporates
muss man erst abstehen lassen.
Wobei die Grenzen, wo das dann viele nicht runterfallen.
Nur große Corporates müssen das eigentlich machen.
Ja, und wenn du so groß bist, dass du da runterfallst, dann
genauer dann.
Wenn die Leute halt nicht freiwillig für Open Source dann
bereitstellen, dann ist das vielleicht schon ganz gut, dass sie dazu gezogen werden
über ein Modell, aber ja.
Ja, aber genau, aber tatsächlich
würde ich jetzt mal so sagen, also
es geht schon viel Zeit dabei drauf,
also bei mir jetzt, also
dass ich irgendwie Dinge, also
morgens, wenn ich mich dran setze,
dann so, irgendwie
und Jochen unterhalten sich über die Programmiersprache Python
und anstatt dass auch noch die Idee kommt, wenn es mal komplett
rebuildet ist, das wieder von vorne an.
Und wenn man daran debuggen will, es geht schon,
es ist aber alles irgendwie und alles ist langsam
und in einzelnen Testern ist halt alles lahm,
es fühlt sich alles so an.
Es braucht relativ viele Ressourcen.
Ja, genau. Ich bin
vielleicht besonders gestraft, weil ich halt
auf einer Mac-Plattform bin und da ist es halt
besonders langsam, aber
es ist wirklich
aufwendig.
Es kostet wirklich Zeit,
irgendwie das halt zu verwenden.
und es macht alles ein bisschen schwieriger
und für meine eigenen Sachen mache ich das,
also da habe ich jetzt den Vergleich, da mache ich das halt nicht so.
Ein Pattern, das ich da halt verwende, ist eben,
ich verwende halt sowas, oder ich habe halt auch ganz lange
nicht Honcho verwendet, aber verwende jetzt dann halt
vielleicht Honcho und den einzigen,
den Applikationsverlauf, das Ding, an dem ich gerade entwickle,
das starte ich dann halt in der IDE
mit dem Debugger zum Beispiel und kann halt
dann schön drin debuggen. Ich kann, wenn ich
auf den Test ausführen klicke, dann ist das halt sofort
sofort ausgeführt, ja,
und ich muss halt nicht erstmal 10 Sekunden warten, bis das
irgendwie sich irgendwie in Docker reingetunnelt hat
und dann da irgendwie...
Wenn du erstmal alles wieder bauen musst.
Und das
funktioniert tatsächlich ziemlich gut. Es war eine sehr
angenehme Erfahrung, aber
ja, weiß auch nicht. Aber die Leute,
also in Firmen ist es wohl
offensichtlich inzwischen irgendwie verpflichtend,
Docker zu nehmen.
Klingt gut, also Hontu.
Ich wollte...
Danke an Claudio für den Tipp.
Ah ja, also ich
wollte ein Dango-Projekt
picken. Und zwar
HealthChecks heißt das.
Das ist sehr cool.
Da kann man selber hosten, einfach HealthChecks und da
irgendwie seine Applikationen reinpacken.
Es ist natürlich ganz wichtig, dass der HealthCheck
Server auf dem gleichen Server läuft
wie der Rest.
Ja, ich weiß es nicht.
Wann wird es?
Das ist ja in Dago selber drin.
Ja, genau. Es ist ein Dago-Projekt,
Dago-4-Projekt, wo man halt relativ nett
einfach seinen Server,
die man so überwachen will, rein monitoren kann.
Ganz nettes, kleines Frontend
altes, relativ modern gebaut
und Tynopost-Python
3.8 glaube ich und
hochfahren,
Frontend benutzen, wie man das halt von anderen Tools
kennt, aber es ist help-hosted und light-white
und schick. Ja, cool, cool, cool.
Muss ich mir mal angucken, was das genau macht.
Ich dachte, das wäre jetzt in dem Ding, was man innerhalb
von Django hat, wo man dann von außen fragen kann, ob
da noch alles okay ist. Also einfach so ein
normales Health-Check-Ding, dass du halt einfach
guckst, sind die Server, die du halt haben willst, sind die noch da oder
nicht und was macht das hinterher. Okay, also eher so ein Monitoring-Tool.
Ja, ja, genau.
Mal angucken, weiß ich nicht.
Ja.
Ja, dann
sind wir eigentlich, ne?
Ja, sind wir durch.
Vielen Dank, dass ihr wieder eingeschaltet habt.
Bleibt uns gewogen, trotz Erwärmung.
Hört uns überall, wo ihr uns hören wollt.
Sagt Bescheid, was euch stört, an hallo.at, pythonpodcast.de.
Ja, oder wenn es euch nicht stört und gut
gefällt, dann könnt ihr auch gerne irgendwie
meine Bewertungen hinterlassen bei iTunes oder
irgendwie Spotify geht es jetzt auch über unsere Bewertungen.
und
geben. Letztes Jahr waren wir über 100 Tage, glaube ich, in Top 20 Tech-Podcasts.
Kann das sein?
Top 50, glaube ich eher.
Top 20, weiß ich nicht.
21 oder so.
Ja, aber relativ lang.
Und jetzt, also dieses Jahr, ich weiß nicht,
dieses Jahr eigentlich
schon die ganze Zeit.
Ja,
vielleicht gibt es gar nicht mehr als 50.
Ich weiß es nicht.
Auf Spotify sind es quasi jetzt gerade so
3000 Subscriber.
Ja, und wie viele sind wir
und
Ist ja völlig verprünt, okay.
Nein, hast du das mitgekriegt, diese Joe Rogan-Geschichte?
Diese unsägliche Mail, die der Spotify-CEO geschrieben hat?
Die Mail habe ich nicht gelesen, ich habe nur gehört, dass es irgendeinen Stress gibt mit Joe Rogan, den ich nicht höre.
Und ich dachte mir so, aha, okay, der hat irgendwelchen Scheiß erzählt und ist ein Idiot und einige Leute verlassen das hier in der Plattform.
Ich bin ein bisschen aufgeregt, blablabla.
Weißt du was, ich bin einer der wenigen Leute, die überhaupt kein Spotify haben.
Ach so, okay.
Ich weiß auch nicht, warum unser Podcast da läuft.
Ich glaube, jemand hatte die Idee, dass das unbedingt da laufen muss.
Mir ist das Ding völlig egal.
Ja, ich höre meine Musik tatsächlich auf anderen Quellen.
Also auf Vinyl, falls du genau wissen willst.
Aber, ja.
Ich war da, ja,
aha, der feine Herr
auf Vinyl.
Ich mag das halt, wenn Python-Code gut aussieht,
aber okay, andere Leute hören halt Sachen
auf Vinyl. Ja, also ich habe aber so
ein modernes System, damit kann ich mir auch jede digitale
Flak auf mein
Vinyl schmeißen, wenn ich das muss.
Dann kann ich sogar mit dem Flak
umscratchen. Das muss ich demnächst mit einer
Tonspur von dir aufrufen.
auf der Webseite.
Zeit ist gewogen.
Vielleicht wieder rein. Bis dann.
Tschüss.