Skillbyte Podcast #61: FastAPI - RESTful APIs in Python

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: RESTful APIs in Python

// Inhalt //
00:58 - Vorstellung Christopher Reitemeyer
01:23 - Intro zum Framework FastAPI
02:11 - Hintergrund: RESTful APIs und OpenAPI
04:45 - FastAPI ist schnell
05:38 - API Dokumentation
08:02 - Validierung
09:21 - Authentifizierung & Sicherheit
10:08 - Dependency Injection
11:03 - IDE Unterstützung
11:42 - Tipps & Tricks
13:13 - Asynchrone Request-Entwicklung
14:52 - Fehlerbehandlung
16:48 - Handling von SQL and NoSQL Datenbanken
18:58 - Deployments
21:35 - Verwendung des Debuggers
22:13 - Unit Tests
23:06 - Anwendungslogik
23:40 - Zukünftige Entwicklungen des FastAPI Frameworks
27:04 - Upgrades von FastAPI Versionen
28:44 - Der Blick auf FastAPI lohnt sich!

FastAPI was the third most loved web framework in Stack Overflow 2021 Developer Survey: https://
insights.stackoverflow.com/survey/2021/#section-most-loved-dreaded-and-wanted-web-frameworks

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Wird jedem ans Herz legen, es zumindest einmal auszuprobieren, wenn man tatsächlich in die Richtung arbeitet, als Alternative zum Beispiel wenn man es in Python machen möchte zu class oder condition. Da ich schon finde, dass sie wesentlich verständlicher sind und auch sehr gut arbeitet, vergleichsweise definitiv auf demselben Level, aber auch leichter einfach umzusetzen ist.

Herzlich Willkommen zum Skillbyte Podcast Episode Nummer 61 Fast Epi Rest von APIs in Python Abonniert unseren Podcast für mehr spannende Themen aus dem Technology Umfeld, wenn er die Entscheider oder Fachkraft seid. Wenn ihr eine Hörer Frage habt, schickt sie uns gerne an Podcasts skillbyte. Wir freuen uns immer sehr über Weiterempfehlung an eure Freunde und Kollegen und natürlich über ein Abonnement unseres Podcasts. Ich sitze heute hier mit dem Mitarbeiter Christopher. Hallo Christopher.

Hallo Maurice.

Ich freue mich, dich heute hier zu haben. Zum Thema fast.

Freue mich, dabei zu sein.

Möchtest du dich kurz vorstellen?

Natürlich. Mein Name Christopher Meier. Momentan arbeite ich für einen Kunden und programmiere die ganzen Schnittstellen mit. Fast Epi sind dann mehrere, die miteinander verknüpft sind. Und zwischen diesen Verknüpfung spielt sich dann sage ich mal die Magie ab. Dabei geht es hauptsächlich, dass ich Dateien in Jason Format oder XML bekomme, die auch ganz gut verschachtelt sein können. Diese werden dann in diversen Art und Weisen aufbereitet.

Wie bist du denn zum Thema First API gekommen? Oder an dieses doch recht hippe Framework, was in der letzten Zeit sehr viel Bekanntheit erfahren hat? Wie bist du denn dazu gekommen und musstest du Alternativen evaluieren?

Eigentlich wurde ich da ziemlich ins kalte Wasser geschmissen. Es hieß Schnittstellen machen am besten mit Fast API High Performance mäßig. Vorher wurden wohl sehr viel APIs mit Alternativen wie Class oder Connection gemacht, da fast ein iPhone Benchmark höher schneller ist. Und wenn wir schon dabei sind von der Benchmark ähnlich zu Google oder zu noch jetzt rankommt oder sogar über den steht, wurde das dann verwendet und demnach musste ich das dann relativ kurzfristig mich einlesen und antrainieren.

Okay, das heißt Performance Gründe haben quasi den Ausschlag gegeben und das Framework Fast API war also gesetzt? Genau. Du hast es schon angesprochen, die API steht ja schon im Namen, eignet sich besonders für die Entwicklung von APIs. Schnittstellen werden natürlich immer wichtiger in komplexen IT Systemen, gerade auch wenn man an die Implementierung von Micro Services denkt, die halt viele kleine Dienste miteinander verknüpfen, sodass diese Dienste entweder parallel hochgefahren werden können zwecks besserer Skalierbarkeit oder auch zwecks Ausfallsicherheit eben mehrere Instanzen eines Dienstes vorhanden sind. Schnittstellen, wie der Name schon sagt, verbinden immer mindestens zwei Dienste, das heißt man muss auf zwei Seiten oft Schnittstellen implementieren. Man hat ja so einen Produzenten oder Producer und einen Consumer und die tauschen oft Daten aus. Klassischerweise in den letzten ein, zwei Jahren hat sich diese Open API Spezifikation immer weiter verbreitet und wird häufig eben für die Implementierung von APIs verwendet. Praktisch läuft das so Ich weiß nicht, ob das in einem aktuellen Projekt auch so gelaufen ist. Du kannst eine Jamil Datei schreiben, die eben diese Schnittstelle beschreibt, also die Methoden, die URLs, die Parameter, die angenommen werden, bei Post Requests, den Post Body und die Daten, die darin enthalten sind meistens Jason Dateien.

Und dann kann man aus dieser Jamil Datei, die diese Schnittstellen beschreibt, mittels Generatoren für unterschiedliche Programmiersprachen und Frameworks automatisch die Schnittstellen Klassen, also die Interfaces generieren lassen. Und diese generierten Klassen, die du jetzt auf beiden Seiten der Schnittstelle hast, wenn du das mal so vor seinem geistigen Auge anschaust, die kannst du dann eben einbinden und das können auch durchaus unterschiedliche Programmiersprachen sein. Also dass man auf der einen Seite ein Python Microsoft hat und auf der anderen Seite ein Java Micro Service, die miteinander sprechen und Open API oder diese Generatoren können eben für beide Welten Bindings bzw diese Interface Klassen erstellen. Das ist ziemlich cool. Ändert man dann was an der Schnittstelle, ändert man das an der Jamil Datei und schmeißt einfach den Generator für eine oder beide Seiten noch mal an und dann passt die API von beiden Seiten wieder zusammen. Das ist so der State of the Art aktuell, wie man Rest voll APIs oder http APIs entwickelt. Da passt natürlich auch fast API rein. Und zwar ist es das Most Loft Framework im Stack Overflow Survey von 20 21.

Ich kann den Link in die Podcast Beschreibung packen und Uber und Netflix nutzen es. Das trägt sicher dazu bei eine gewisse Bekanntheit zu erlangen und dann auch verbreitet zu werden. Fast Apple selber sagt ja, es ist ein modernes, schnelles High Performance Web Framework um APIs mit Python drei, sechs und neuer zu bauen. Du hast auch schon gesagt, dass die Geschwindigkeit einer der Hauptgründe war, sich für Fast API zu entscheiden. Kannst du da genauer drauf eingehen? Also bezieht sich das nur auf Performance im Ablauf oder auch auf die Entwicklungsgeschwindigkeit zum Beispiel.

Also beides. Die Entwicklungsgeschwindigkeit ist laut Test um einiges gestiegen. Also die wurde wirklich praktisch an Entwicklern getestet, die mit verschiedenen Feinberg das gleiche schreiben sollten. Und da war fast API mit wirklich hohen Prozenten weiter vorne. Das liegt einfach zum Teil daran, das wie du es gerade schon angesprochen hattest, normalerweise über eine Email die Schnittstelle beschrieben wird, ist nicht nötig. Das heißt keine jammern so wie in anderen Frameworks, sondern das findet fast LBJ selber mit. Ein Mann beschreibt das anders. Kann ich ja gleich auch noch mal zukommen. Und auch dieses Mega Open API Spezifikation, was man auch im Internet kennt, wo man dann bei Netzwerker Seite selber sich die API anzeigen lassen kann. Die Dokumentation macht fast API von allein, das heißt Fast API hat selber auch zwei Dokumentation. Wenn ich hinten zum Beispiel jetzt über localhost oder auch wenn ich das Display über den linken Slash Dock sind da schreibe, öffnet sich automatisch die GUI und mit Medoc hätte man noch eine andere Dokumentation Seite.

Das kann man. Für jeden Endpunkt kann man das wahrscheinlich machen.

Dieses Docks ist für alle Endpunkte zusammen, also wie man dieses das kennt. Da werden dann alle Endpunkte in dem Format von der Video dargestellt, das heißt auch mit den Text etc. Die gibt man halt alle pro Endpunkt selber an, das heißt, schreibe ich jetzt an einen Point, kann ich selber bestimmen, in welchen Text das reingehört. Kann ich die Sponsored selber deklarieren? Also alles das auf meiner Gammel macht, mache ich im Prinzip im End Point, was es relativ angenehm macht. Wenn ich jetzt irgendwo weiß, ich müsste etwas ändern, brauche ich nicht in der Formel ewig zu suchen, weil wie man es kennt, wenn die relativ groß wird, viele End Points hat, dann sucht man schon mal eine Weile. So ist das angenehm, weil ich natürlich in Python selber beim Schreiben das Ganze über einen Router aufteilen kann, das heißt, ich schreibe das in verschiedene Files, die ich wie auch immer sortiere, ob ich die jetzt nach Geld und Post zum Beispiel sortiere.

Oder nach URL.

Oder so, braucht dann nur noch in die Teil selber reingucken und kann direkt dort genau diese Spezifikation sehen. Und das ganze wird dann von Fast API selber umgewandelt in diese Dokumentation. Das ist sehr angenehm, um ehrlich zu sein, weil ich dieses Sammel Geschreibe tatsächlich immer sehr gut sehr unübersichtlich fand.

Das heißt du kannst direkt im Code deine API schreiben oder deine Methoden schreiben, aber verlierst natürlich die Möglichkeit dieser Generatoren, das dann auch für andere Umgebungen sozusagen der Gegend Punkt für deine API direkt mit generiert wird. Ja.

Das stimmt.

Okay, ne, das doch gut, aber dir gefällt es auf jeden.

Ich finds super. Ich muss sagen wie gesagt bekam da ja gerade über die Entwicklungsgeschwindigkeit drauf. Es war wirklich sehr angenehm, weil es wirklich sehr schnell ging. Auch das Lernen. Es war wirklich super einfach zu lernen auf der offiziellen Seite. Von dem wird man auch wie in einem Tutorial durchgeführt durch alles. Da ich jetzt gerade das Thema, weil es mir gerade wieder einfällt, ein bisschen übersprungen habe und ich das jetzt auch nicht weglassen wollte. Diese Performance Frage bezieht sich tatsächlich allgemein auf die Entwicklungsgeschwindigkeit, aber auch die Performance von wie das ganze abläuft und berechnet wird. Auch weil man von fast API im Prinzip benutzt. Das ist einer der schnellsten Libraries für Speisen und diese ist dafür gestaltet, Datentypen automatisch zu überprüfen. Das heißt, ich kann viel schreiben über dieses Base Modul, dem kann ich jetzt sage ich mir mal, ein User besteht aus dem Namen, aus dem Nachnamen, aus dem Passwort, Login Name, wie auch immer und diese bestehen ja alle aus Strings. Sind meinetwegen Emailadresse, das heißt wir hatten Emailadressen mit drin und dadurch wird diese Typen Abfrage oder Typen Validierung sehr sehr schnell generiert und dadurch das fast ab und an auch auf STANDARD beruht, was ja auch nochmal ein wichtiges Framework ist.

Für A sind Webservices ist dieses im Prinzip 100 % vererbt, also fast API hat alles was da lädt hat.

Okay. Starlet Codes können direkt in Nepal verwendet werden und bei Copy Paste drüber kopiert werden und funktionieren. Das heißt wenn man keine Sammel Datei hat um beide Seiten einer API zu generieren, dann eignet sich wahrscheinlich fast insbesondere wenn man zum Beispiel APIs von Cloud Providern oder bestehende APIs abruft und selber nur Micro Services implementiert, die diese konsumieren sollen oder damit interagieren sollen. Also wenn man gewissermaßen nur eine Seite einer API implementieren muss und nicht beide Seiten.

Ja.

Wie ist das mit Authentifizierung und Sicherheit? Da habe ich gelesen, dass Fasst API Framework bringt da auch einige Punkte mit.

Ja, ich hatte tatsächlich mit der Sicherheit, bis jetzt habe ich die nicht benötigt. Ich habe mir das natürlich aber trotzdem nebenbei auch mal angeguckt und da unterstützt Fast API einige Security Methoden, ob Sie jetzt zuerst HTTP Basics oder die Applikationen Header Query Parameter nur Cookies. Ist wohl auch sehr leicht umzusetzen. Ich sage mal für OS zwei möchte man in der API Ihnen potente Begleiter mit Priorität Token haben. Ist das tatsächlich nun Einzeiler?

Okay, das heißt die Integration, wobei sich also auf zwei und per API Keyser ist quasi schon eingebaut, man muss sie nur noch konfigurieren. Genau jetzt hattest du mir von einem Konzept erzählt, was Dependency Injection genannt wird in der Phase. Was hat es damit auf sich und wie wird das verwendet?

Ähnelt sind Reaktion wird von API sehr leicht verwendet. Dafür bringen API die Methode die Pentz mit. Ob ich die jetzt in einem End Point bei der Variablen übergebe? Sagen wir mal, wir haben mehrere Query Parameter. Können wir diese auch einfach, damit wir die häufiger benutzen können, in eine Methode schreiben? Jetzt ganz simpel vielleicht nicht der nützlichste Use case, aber sehr leicht damit zu beschreiben, reinschreiben und formatieren. Was wir auch immer mit diesen Variablen machen möchten und können mittels Dispens und dann dieser Methode oder Funktion direkt das Ganze an diesen Endpunkt übergeben. Das heißt, diese Abhängigkeit API ist sehr leicht gestaltet und bildet im Prinzip einen riesengroßen Baum. Man oder man kann damit einen riesengroßen Baum bilden.

Das heißt, Abstraktionen, Schichten von Datenbanken, Frontend und soweiter sind kein Problem. Kann man fertig.

Werden? Genau.

Wie ist das mit Editor Support? Also gibt es irgendwie AutoCAD? Welche Editoren unterstützen fast API.

Soweit ich weiß getestet mit dem üblichen Editor, das heißt die werden komplett alle unterstützt und Auto Competition ist wirklich wunderbar, aber diesen Traum müsste man einfach so sagen. Komplett egal um was es geht, wo man erbt, alles ist komplett mit AutoCAD vom.

Dritten Editor benutzen persönlich.

Aber ich weiß auch, dass Visual Studio oder etc. alles unterstützt wird.

Visual Studio Code wahrscheinlich ja.

Visual Studio Code? Genau.

Das heißt, du bist sehr schnell produktiv geworden. Mit Fast API gibt es Dinge, worauf unsere Zuhörer achten sollten, wenn sie selber Fast API einsetzen möchten, wo du zum Beispiel jetzt sagst Oh, da habe ich lange gebraucht, um das herauszufinden, aber das ist total praktisch. Also Tricks und Kniffe.

Ja, es gibt eine Sache, ich weiß nicht, wieso. Vielleicht, dass es mir so schwer gefallen, aber ich habe ewig lange gesucht, um auf das Open API extra zu kommen. Und zwar gab es unter Tobi anfangs noch gar nicht gefunden beim Durchgehen. Ich habe es auch im Internet nie so gefunden. Und zwar hatte ich den Fall, dass ich unterscheiden musste vom Content Typ, ob ich jetzt nur Jason oder ein Exemplar übergebe. Dabei kann ich ja, weil ich das ganze auch noch validieren musste. Da wollte ich im Prinzip in einem Scroll Down Menü auswählen, ob ich jetzt nichts im EL oder Jason hochlade oder weiter gebe. Das Format an das zu implementieren war dann doch sehr schwierig, aber dafür gibt es diese Funktion oder besser gesagt dem Open API extra als Variablen ein Open API Extra kann man einfach ein Jason Format dann so wie man es in der Vega macht. Also wenn man es in der Annahme macht, sehr einfach über Jason Format beschreiben, dass man jetzt zwei verschiedene Applications hat, zum Beispiel einmal Application Applikation, einmal Jason, welcher Content da drin ist.

Über dieses Open Extra lassen sich auch sehr leicht diese Example einbringen, das heißt vielleicht kennt man das und das wäre wie wenn man oder wenn man dann in die mail diese example reinschreibt, die dann automatisch angezeigt werden als standard typ. Das ganze kann man über open api extra machen. Bei dem Punkt hat dann doch sehr lange gedauert, bis ich spezifisch genau das rausgefunden habe. Aber ansonsten glaube ich, ist alles ziemlich selbsterklärend.

Das heißt, du hast wahrscheinlich jetzt, wenn du die API abgefragt hast, du wahrscheinlich synchrone Calls gemacht oder hast du auch mit der Sync Funktionalität gearbeitet?

Tatsächlich habe ich nur mit asynchron gearbeitet. Das liegt zum Teil an der Datenbank. Dadurch, dass ich Mongo DB verwende, die ja selber auch schon asynchron ist und dadurch dann halt über die ganzen Sachen abwarten kann. Allerdings auch für Apple selber sind manche asynchrone Sachen wichtig, weil man muss sich über Arbeit und dann je nachdem wie die Variable für den Body genannt werden sollte, sagen wir mal Data Data. Punkt Body machen und dieser muss auch erweitert werden. Und da ich zum Beispiel die Post mit fast ein Request Buddy drin habe, muss ich alleine schon immer eine asynchrone Methode raus machen. So wie jede Datenbank Funktion oder ein Point auch asynchron sein muss.

Das heißt was aber einen sehr hohen Durchsatz, weil du alle Calls asynchron machst und dann im Grunde per Callback benachrichtigt wirst, wenn die Datenbank wieder fertig ist. Wahrscheinlich kommt daher der Name Fast API oder ist das das STANDARD Vorgehen oder sind da wahrscheinlich im STANDARD sind schon eher synchrone Kreuz angedacht, oder?

Also ich sag mal so, im Tutorial ist es komplett glaube ich mit asynchron tatsächlich beschrieben. Also ich finde es halt schwierig auch synchrone zu machen. Ich glaube ich habe vielleicht ein zwei Points, die ich synchron machen könnte, wenn ich die ein bisschen umschreibe. Aber dadurch wie gesagt durch den Buddy, dass asynchron unnötig kann natürlich die Performance mäßig auch ein bisschen einschränken, weil man natürlich die Geschwindigkeit einschränken dadurch, dass man unter anderem immer warten muss. Man wird, sagen wir mal, die Datenbank sehr voll haben und wir wirklich auf den Datensatz warten müssen. Aber an sich ist ja dieses, dass es asynchron ist, ein großer Vorteil.

Wie ist das mit der Fehlerbehandlung? Wenn so ein asynchrone Call zum Beispiel nicht zurückkommt oder abbricht, so Connect bewusst, wird das auch schon fast abgedeckt.

Ja, das wird komplett abgedeckt. Also allgemein habe ich das Gefühl, dass die Errors, die man selber macht, aber auch die man nicht unbedingt selber macht, sondern die vom Programm durch zum Beispiel wie du gesagt hattest, durch die Datenbank passieren können, dass die komplett alle abgedeckt werden. Also man kriegt wirklich eine sehr spezifische Fehler Beschreibung und kann das extrem gut nachvollziehen. Die Fehler Beschreibung ist schon ziemlich genau.

Okay, das heißt man bekommt eine aussagekräftige Log Ausgabe oder Lock Meldung und hat einen relativ guten Eindruck, was da fehlgeschlagen ist, welcher Request fehlgeschlagen ist und wo man einfach nachgucken kann, um diesen Fehler zu korrigieren.

Genau. Also das hatte ich schon stark das Gefühl, das Programm bricht tatsächlich auch nicht komplett ab. Also mache das ganze bei Unicorn, wenn ich local das ausprobiere um die API im Prinzip am laufen zu bringen oder am laufen zu halten. Die Rubicon ist da zum Glück auch relativ schnell, ist unglaublich schnell getestet mit Rubicon und dann hintendran gehangen. Halt Minuten minus Reload bleibt immer offen, selbst bei Veränderung. Das heißt, wenn ich nebenbei schreibe, wird das aktualisiert und selbst das bricht nicht ab, wenn ich ein Abo habe, sondern nur dann URL beheben und die dann direkt auf einmal die Fehlermeldung weiterhin sehr angenehm macht. Dazu vielleicht noch, weil mir das jetzt einfällt, dazu zu den vielleicht was knifflig ist, wenn man mit API etwas, die Plain möchte, also irgendwo hochladen möchte, zum Laufen bringen möchte, sollte man nicht Rubicon verwenden, bei Rubicon nicht die Platte fertig ist. Das heißt man muss das ganze dann über zu Figuren machen und dort dann ein Rubicon Worker machen, was aber auch nicht so schlecht ist.

Man nimmt die Sachen von Unicorn mit, das asynchrone zum Beispiel auch, aber verliert nicht wirklich an Geschwindigkeit.

Okay, das heißt Production ready ist deine Entwicklungsumgebung nicht, das ist ja klar, sondern man muss sie sozusagen noch einpacken, damit man sie ja irgendwo auf dem Server leben kann, wo sie dann produktiv betrieben wird. Genau jetzt hast du eben schon von Mongo DB gesprochen. Das ist ja ein No Sequel Kataster oder eine Schema freie Datenbank. Hast du auch SQL Queries entwickeln müssen oder SQL Datenbanken anbinden müssen? Schon in einem Projekt.

Nehmen passt API noch gar nicht. Also das war auch eher Vorgabe von Mongo DB, da haben wir alles.

Ist ja auch vollkommen okay, ist nur interessant gewesen, weil bei Fast API ist glaube ich ein SQL Zugriff gibt der synchron ist und eben auch einen asynchronen SQL Zugriff. Da hätte mich interessiert, wenn du da Erfahrungen gesammelt hättest, wie sich das unterscheidet oder was deine Erfahrungen sind bei der Implementierung von synchronen oder asynchronen Queries.

Ja, so ist das wohl wirklich viele Datenbanken alles abgedeckt sind und standardmäßig von Fast API sogar SQL Alchemy vorgegeben wird. Natürlich kam ich leider noch nie zu, wollte ich tatsächlich privat, weil ich was damit probieren wollte, noch ausprobieren, aber bis jetzt noch die Zeit gibt.

Es wäre auch interessant zu wissen, wie zum Beispiel Schema Updates bei SQL Datenbanken Opfer API da Hilfe anbietet. Es gibt zum Beispiel so ein Tool, das heißt Cubase. Damit kann man so Migrationen von Datenbank, SQL Datenbank Schemata organisieren. Weiß ich nicht. Ob das auch mal so ein Mechanismus mitbringt.

Kann ich leider nicht sagen. Das weiß ich auch.

Nicht bei local Datenbanken, also not only SQL Datenbanken wie Mongo DB, da ist es ja egal, da kannst du einfach das neue Dokument hat halt neue Properties und die werden einfach geschluckt und können dann angesteuert oder gefiltert werden, entsteht dieses Problem eben nicht. Gibt es noch Themen Fast API, die wir jetzt nicht auf der Agenda haben, über die du einfach noch gerne sprechen möchtest? Erfahrungen, die du gemacht hast, vielleicht Sachen, wo du lange gebraucht hast, Probleme besonderer Erfolge und.

Sagen, der Erfolg war schon, wie schnell ich fertig war mit dem Einstieg, sage ich mal, dadurch, dass ich das Tutorial, wie ich gesagt habe, durchgegangen bin, war sehr leicht, es zu verstehen. Angewendet auf den Pfeil, den wir brauchten, war ich dann wirklich halben Tag und dann stand die erste API natürlich komplett erst mal nur von den Endpunkt alle. Natürlich die Einzelheiten noch nicht exakt, aber das geht einem schon das Herz auf.

Es war sehr schnell eingearbeitet.

Ja, genau.

Hast du auch schon Productions Deployment gemacht? Also du hast ja eben gesagt, dass man Unicorn benutzen muss oder sollte und wie halt die lokale Entwicklung in Zusammenhang steht. Also mit Unicorn und dann mit Unicorn wird es dann in Produktion betrieben? Hast du diese Sie City Kette schon durchlaufen?

Ja, komplett. Also in mehreren Fällen sind jetzt alle von den AB. Als ich geschrieben habe sind die blöd und handeln doppelt was mit sehr leicht war. Im Prinzip habe ich ein HP zweimal geschrieben, einmal Smaug, einmal so, aber einfach nur mit einem einzigen Unterschied, dass ich die Deployment, weil man Variable im Prinzip gesetzt habe, ob ich jetzt Makro oder nicht, demnach das war relativ leicht, weil die End Points dann nur durch diese Variable veränderbar waren. Vielleicht auch noch ein Pluspunkt, aber ich denke, das kann man an anderen Sachen auch gut regeln in anderen Frameworks. Aber ja, die sind komplett alle die Zeit und sind auch miteinander verbunden.

Welche Schritte muss man durchlaufen, um ich sage mal von dieser lokalen Entwicklungsumgebung, man möchte das jetzt Deployment, um dieses Paket zu schnüren und zu betreiben, was dann in der Produktion ausgerollt wird.

Als erstes Mal, ich habe mit einer Docker Pfeil gemacht, das heißt, ich habe in die Docker reingeschrieben, im Prinzip dem Ablauf, das heißt einmal kurz alle Paketen von Preisen und was API etc. alles kurz, einmal mit PIP installieren lassen, dann das Ganze über Rubicon über den Worker loslaufen lassen und die Leute haben das dann in einer Plattform, dort dann eine URI im Prinzip erstellen lassen für dieses, so dass man dann, wenn ich jetzt lokal arbeite, arbeite ich ein und aus. Das würde natürlich jetzt nicht funktionieren und diese URI muss ich dann nur noch in meinem Code selber auch implementieren als Server Adresse. Da ich jetzt zum Beispiel das API ein Server mit angebe und über die URI oder mehrere, da muss man sich nur ein Menü zwischen allen dieser auswählen. Und wenn ich jetzt über die Doku Seite direkt schon am Ausprobieren bin, das funktioniert auch wenn ich Diplomat bin, dann wird dieser Server im Prinzip immer wieder angesprochen. Das heißt sagen wir mal, wir haben jetzt Server mit test API, punkt de Slash und auf der Dock Seite kann ich das dann direkt ansprechen.

Habe ich jetzt ein Endpunkt der über Slash läuft, zum Beispiel sollst du tun Liste und mir alle ausgeben möchte, dann weiß der automatisch okay, er nimmt diese Server URI, die ich mit rein gebe und setzt automatisch dann diesen Input dahinter, so dass ich dann das direkt das Ergebnis in dieser Seite bekomme und nichts mehr anderes machen muss.

Und dann kannst du direkt betreiben. Den Docker Container kannst du dann einfach in die Produktion überführen, ganz normal starten.

Genau der wird ja wie man, wenn man es in Cloud Umgebung einbringt, ob es jetzt Google Cloud ist oder welche oder eine andere Cloud ist. Wenn man es dann natürlich hochlädt, genau, kann man das sehr direkt dort eingeben.

Wie ist das jetzt? Um auf die Entwicklung ein stückweit zurückzukommen, wenn man diese APIs entwickelt, hast du einen Debugger benutzt?

Hab selber so jetzt kein Debugger benutzt, weil das meiste von API selber gemacht wird.

Okay, du bist nicht so durch die Debugger Breakpoint gesetzt, sondern durch die einzelnen Zeilen durchgegangen.

Nee, also überleg gerade. Ich glaub das kam einmal vor, aber das war ein Fehler, auf den ich nicht gestoßen bin, weil der so ist. Selber habe ich kein Breakpoint gesetzt, weil ich genau wusste, ja, welche Methode probier ich oder welchen Input probier ich gerade aus. Das heißt, ich muss, der muss ich irgendwo darin befinden.

Bei kleinen Komponenten geht das noch. Hast du Unit Tests geschrieben?

Ja, ich habe hier Test geschrieben und Low Cost Test. Aber zu Python der Betty auf Unit Run, das ist ganz angenehm gewesen, weil ich brauchte tatsächlich die Test nicht komplett bei der ersten CPR selber schreiben. Weil die noch sehr leicht gehalten wurde, habe ich von Fast Abschied Test benutzt. Der beruht auf PTS, das heißt ich starte Patienten, der von meinem Server abhängig ist und braucht dann im Prinzip nur noch die Methoden schreiben, die automatisch da wissen, wo sie hin müssen. Das ist relativ angenehm. Für andere habe ich dann ein bisschen ausführlicher auch wirklich mit United gearbeitet, weil ich dieses bei Test Fixer brauchte, weil es dann ein bisschen komplizierter wurde. Aber auch das konnte ich zur Hälfte, sage ich mal, mit dem Test machen und dann ein bisschen erweitern mit dem Fixer. Also das war ganz angenehm. Ansonsten Lukas Test, um zu gucken, wie sehr der Server belastet wird und die API, da war das auch standardmäßig ganz normal einfach gewesen.

Und in deinem Projekt ist es so, musst du sehr viel Programm Logik integrieren oder ist die API wirklich eine ganz schmale API, die einfach Daten aus der Datenbank holt, Daten weg speichert und gar nicht viel Logik enthält? Vielleicht auserwählte Stations?

Doch ich würde schon sagen, also die verwendet jetzt nicht ultra viel Logik, aber definitiv schon ein Stück weit. Also es geht schon darum, dass sich Datenverarbeitung oder abändern.

Also Transformation weglassen, anreichern, mehrere Datenbank Calls mache, um dann ein Objekt zurück zu liefern. Okay. Hast du eine Einschätzung zur zukünftigen Entwicklung der Fast API? Also sind dir Dinge aufgefallen? Wurde das. Ah, das ist. Nicht ganz so schön. Das kann man noch besser machen. Oder hast du dich in Foren getummelt, wo Leute verschiedene Anfragen gestellt haben, dass du absehen kannst? Ja, wahrscheinlich wird sich das in diese oder jene Richtung weiterentwickeln. Wo immer.

Man tummelt. Ich sag mal so Ich habe natürlich viel gegoogelt und wenn ich auf irgendwas gestoßen bin, wo ich jetzt nicht direkt weiter wusste. Ich hab das Gefühl, dass es schon gut verbreitet ist, aber bei weitem nicht so viel verbreitet, wie wenn ich noch in einer Lösung bin, dann wird mir häufig plus angezeigt und las halt schon älter ist und wesentlich mehr benutzt wurde. So oder so wie den oben ja extra. Ich habe es gegooglet. Überall wurde mir gesagt das ist nicht möglich mit fast elf Jahren. Ich habe natürlich nicht losgelassen. Es wäre jetzt blöd wenn. Ich hab's dann auch irgendwann rausgefunden, aber das würde dann halt schon nicht irgendwie erläutert in den Foren. Ich denke aber, so wie mir das vorkommt, dass die Beiträge auch alle ziemlich neu sind, viele gewesen, dass das schon sehr im Kommen ist. Wenn man mal überlegt, wie sehr Python allgemein im Kommen ist, das heißt, ob es jetzt für Data Science ist oder es Machine Learning, es ist arbeiten ja schon sehr groß im Kommen und aber ist nun mal momentan die beste Framework oder beste möchte ich jetzt nicht mehr sagen.

Es gibt immer irgendwie Sonderfälle, aber schon ein sehr sehr guter Framework. Ich denke mal, da noch in Entwicklung ist, natürlich auch noch einiges leicht verändert werden wird. Meines Erachtens nach müsste vielleicht ein bisschen was verändert werden, weil wie ich schon gesagt habe, ich brauche zwar keine Sammel schreiben, ich muss aber das ganze in den Deckel packen, was JS mäßig aufgebaut ist. Das heißt na ja mal, habe ich ja jobmäßig aufgebaut, sage ich jetzt mal Jason mäßig mit den ganzen und so erinnert dann doch eher wieder ein bisschen, aber das verschachteln sich dann schon sehr und wird ein bisschen übersichtlich, wodurch ich zum Beispiel einen Imprint habe, wo ich mehr weitergeschrieben habe als wirklich Funktion, das heißt der Dekorateur übernimmt 50 Zeilen, während meine Funktion selber nur fünf Zeilen abdeckt. Das heißt, dass man dann vielleicht guckt, dass man es ein bisschen simpler macht. Aber ansonsten bin ich super zufrieden damit. Und ich glaube demnach auch, das ist wirklich groß im Kommen.

Ja, dieser Stack Overflow Developer Survey ist ja keine kleine Umfrage. Und wenn es das wird Most Loft Web Framework ist der 2021 Ausgabe denke ich auch, dass da noch viel Entwicklung stattfindet. Ich habe gerade mal nachgeschaut, es wurde erst im Dezember 2018 initial veröffentlicht, also das Fast Epi Framework. Das ist gerade drei Jahre her und das aktuelle stabile Release 77.1 oder ist null 77.1, das heißt, es ist noch nicht mal eine Version 1.0 erschienen, was normalerweise ein Hinweis darauf ist, dass man es nicht produktiv einsetzen sollte.

Wobei man ja das Gegenteil gemerkt hat. Auch bei Netflix.

Wenn Netflix und Uber es Mission Critical einsetzen, würde ich auch sagen, hat es zumindest eine hinreichende Reife. Hast du irgendwie bemerkt, dass Punkte noch nicht so ausgereift sind in fast epi überlegt?

Also ich glaube, außer dem Geek weiter, den ich gerade schon genannt habe, der wirklich zwar wesentlich übersichtlicher ist als ein Jammer, also jetzt, weil ich weiß, wo ich suchen muss, aber selber geschrieben unübersichtlicher ist eigentlich nicht. Ich find die ausgereift heit über die datentypen, die auch bei tick beruhen, wodurch ich direkt example schreiben kann, direkt Validierung. Also das macht schon den Code sehr klein, also fast ab, erwirbt ja auch zum Teil damit, dass die Minimierung von Code duplizieren ist, so wie minimal Code allgemein für größere Sachen.

Wenn Fast API noch nicht die Version 1.0 erreicht hat, dann vermute ich, dass es sehr oft kleinere Releases gibt. Hast du die dann auch immer ohne Probleme upgraden können, also von einer auf die nächste Version? Oder gab es da durchaus auch mal inkompatible Versions Sprünge sozusagen?

Ich habe tatsächlich so direkt gar nicht mitbekommen, ob ich zum Beispiel schon einen versions wechsel hatte oder während ich geschrieben habe, weil ich finde, dass also mir kam so rüber, dass das versucht wird im Hintergrund laufen zu lassen, so dass man das gar nicht direkt bemerkt. Das heißt, wenn du jetzt natürlich, wenn jetzt neue Sachen rauskommt, die du zufällig brauchst, kriegt man das natürlich mit. Aber dadurch, dass die Sachen, die ich benutzt habe, zum Beispiel, wenn die irgendwie leicht verändert wurden, die wurden nicht vom Sinn her verändert oder vom Inhalt her verändert.

Das heißt, du hattest keine Bauchschmerzen bei versions sprüngen, dass es einfach im Hintergrund passiert und diese keine größere probleme aufgefallen. Ja, gibt es noch etwas, was du sagen möchtest? Unbedingt zum Thema fast Epi eigentlich nicht.

Wird jedem am Herzen liegen, es zumindest einmal auszuprobieren oder sich da vielleicht mal einzulesen oder es in Betracht zu ziehen, wenn man tatsächlich in die Richtung arbeitet als Alternative zum Beispiel wenn man es mit Python machen möchte zu class oder condition. Da ich schon finde, dass sie wesentlich verständlicher sind und auch sehr gut arbeitet, vergleichsweise definitiv auf demselben Level aber auch recht einfach umzusetzen ist. Und vor allem für Neueinsteiger würde ich sagen, dass sie damit sehr gut testen können und ausprobieren können. Dadurch, dass man durch die Dokumentation Seite die automatisch generierte und dadurch, dass man keine JA schreiben muss, wenn man noch nicht so viel mit APIs gemacht hat, sehr schnell den Überblick bekommt. Was schreibe ich gerade? Das heißt kleine Veränderung kann ich direkt sehen.

Wahrscheinlich sehr schnell dann auch mal der Developer Run Trip auf Geschwindigkeit ausgelegt ist.

Genau.

Also du würdest jedem Python Entwickler der. Können muss oder möchte empfehlen, sich mit fast Epi zumindest kurz zu beschäftigen, um dann abzuschätzen, ob das was fürs eigene Projekt sein kann.

Genau. Also ich muss sagen, für kleine Projekte würde ich definitiv ans Herz legen. Für größere, weil ich nicht weiß, wie krass die Auslastung im sehr hohen Bereich einschätzen kann. Aber eher für kleinere oder mittelmäßige. Definitiv zumindest angucken. Einmal durch den Kopf gehen lassen, ob es vielleicht genau das ist, was man gesucht hat, wenn man im anderen nicht mehr weiterkam.

Ja, vielen Dank, Christopher, für die Einsichten zum Thema Fast Epi. Wenn unsere Zuhörer Fragen haben, schickt uns gerne eine Email an et skillbyte. Wir freuen uns immer über Bewertung und vor allem Weiterempfehlung unseres Podcasts an Freunde und Kollegen. Lasst uns ein Abo da und schaut auch auf Skillbyte vorbei für mehr Information zu uns. Vielen Dank Christopher, es hat Spaß gemacht. Danke für das Teilen deiner Einsichten zum Thema Fast Epi.

Kein Problem. Vielen Dank, dass ich da sein durfte.