Bei meinen einschlägigen Recherchen ist mir aufgefallen, dass auch im Jahr 2024 immer noch etliche Leute Flask als Python-Webframework empfehlen. Allerdings ist meiner Meinung nach „Flask auf dem Weg nach draußen und FastAPI stellt die Zukunft dar.“ Deshalb schreibe ich diesen Artikel. Ich lade jeden ein, sich an der Diskussion zu beteiligen und Gegenargumente vorzubringen.
Flask nimmt einen wichtigen Platz im Herzen der Python-Entwickler ein. Wenn Sie ein Webentwickler sind, haben Sie höchstwahrscheinlich Flask verwendet, aber vielleicht haben Sie sich noch nie mit FastAPI beschäftigt.
Hier sind zwei Beweisstücke:
Werfen wir nun einen Blick auf die Veränderungen im Anteil von Web-Frameworks in den offiziellen Python-Entwicklerumfragen.
Es ist offensichtlich, dass FastAPI im Jahr 2019 noch nicht einmal als Option aufgeführt war, sein Anteil jedoch im Jahr 2023 bereits 25 % erreicht hatte. (Derzeit liegen uns nur Daten bis 2023 vor.)
Es ist zu beachten, dass diese Anteilsdaten bestehende Systeme umfassen, sodass die Anteile von Django und Flask nicht schnell sinken. Dennoch ist der Trend klar.
Wir alle wissen, dass der Web-Framework-Bereich sehr produktiv ist und fast jedes Jahr neue Frameworks auf den Markt kommen. Die meisten dieser Frameworks sind nur von kurzer Dauer, während einige Bestand haben. FastAPI wurde Ende 2018 geboren und begann sich etwa Ende 2019 einen Namen zu machen. Wie konnte es also Flask, das Ende 2010 geboren wurde, in Bezug auf die Popularität innerhalb von nur fünf Jahren überholen? Als Nächstes verfolgen wir zum besseren Verständnis die Entwicklungsgeschichte von Python-Web-Frameworks und verwandten Lösungen entlang der Zeitachse.
Der Autor von FastAPI ist ein Entwickler, der der Entwicklung des Python-Ökosystems große Aufmerksamkeit schenkt. Der erweiterte Leselink 2 ist „Alternativen, Inspirationen und Vergleiche“, geschrieben vom Autor (https://fastapi.tiangolo.com/alternatives/), der detailliert auf die Referenzen oder Inspirationen eingeht, die FastAPI aus verschiedenen Bibliotheken gezogen hat. Der Abschnitt zur Entwicklungsgeschichte dieses Artikels bezieht sich auch auf diesen Artikel. Ich würde empfehlen, den Originaltext zu lesen, da er die Gründe für die Entstehung von FastAPI sowie einige Designkonzepte des Autors enthält.
Flask ist ein „Mikro“-Framework, das Welten von Django unterscheidet. Es behält nur eine Handvoll Kernfunktionen bei und teilt andere Funktionen zur Entkopplung in mehrere Bibliotheken auf (z. B. Jinja2, Werkzeug usw.). Dies gibt Entwicklern reichlich Freiheit und ermöglicht es ihnen, mühelos Plugins von Drittanbietern für verwandte Funktionen zu schreiben. Seine internen Designs wie Blaupausen, Kontexte und Dekorateure zur Darstellung von Routen, Signalen usw. waren zu dieser Zeit recht fortschrittlich. In Verbindung mit einer umfassenden Dokumentation ist es äußerst einsteigerfreundlich.
Dank seiner Einfachheit eignet sich Flask hervorragend zum Erstellen von APIs. Da Flask selbst jedoch über keine integrierten Funktionen verfügt, benötigen wir spezielle REST-Frameworks. Infolgedessen sind nach und nach Frameworks wie flask-restful, Flask-RESTPlus und flask-api entstanden. Darüber hinaus gibt es in REST-Diensten Anforderungen an die Datenvalidierung, -analyse und -spezifikation, die zur Entstehung von Marshmallow, Webargs und APISpec führten, bis Flask-apispec auf den Markt kam. Während dieses Entwicklungsprozesses ist jedoch nie ein mit DRF vergleichbares Flask REST Framework entstanden.
In diesem Stadium sind die Mängel von Flask allmählich in den Vordergrund gerückt.
Die ursprünglichen Stärken von Flask liegen in seiner Flexibilität und seinem Minimalismus, was aber auch bedeutet, dass eine Vielzahl von Komponenten selbst entwickelt werden müssen. Dies erfordert entweder ein großes Unternehmen mit engagierten Entwicklern für Entwicklung und Wartung oder äußerst fähige Einzelentwickler. Andernfalls ist es für Plugins schwierig, die Produktionsqualität zu erreichen, was zu einer gemischten Mischung von Drittanbieter-Plugins für Flask führt, ohne Garantie für eine langfristige Wartung. Wie bereits erwähnt, werden viele dieser Bibliotheken bereits nicht mehr gepflegt.
Wenn Sie also mit Flask einen API-Dienst aufbauen möchten, müssen Sie auch heute noch verschiedene Komponenten zusammensetzen. Bei einigen Komponenten, die nicht zeitnah aktualisiert wurden, müssen Sie die Fehlerbehebung selbst durchführen. Veteranen kommen vielleicht damit zurecht, aber für Anfänger ist es ziemlich entmutigend, vor allem, wenn sie die neuesten Praktiken und Konzepte anwenden wollen.
Seit Python 3.5 ist Asyncio der Zukunftstrend. Infolgedessen sind einige Web-Frameworks entstanden, die Asyncio nativ unterstützen, wie zum Beispiel aiohttp, Starlette und sanic.
Zu diesem Zeitpunkt zögerte Flask, sich anzupassen. Die Community hat die Unterstützung für Asyncio nur langsam hinzugefügt, und der ursprüngliche Autor von Flask ist dazu übergegangen, Rust zu schreiben und das Projekt in den Händen von zwei Betreuern zu lassen (jetzt ist nur noch einer übrig).
Projekte zum Aufbau von API-Diensten, wie apistar und molten, haben allesamt Design-Inspirationen für die Geburt von FastAPI geliefert.
Dann wurde FastAPI geboren. Der Autor suchte ursprünglich nach einer guten Lösung, aber die oben genannten Situationen hatten jeweils ihre eigenen Probleme oder Einschränkungen. Also hat der Autor dieses neue Framework erstellt.
Dies ist der Kernteil des Artikels. Die folgenden Gründe sind genau der Grund, warum FastAPI Flask ersetzen kann.
Im Prozess der API-Entwicklung sind die Validierung, Analyse und Serialisierung des Datenformats Routinevorgänge. Im Laufe der Jahre sind mehrere Lösungen entstanden, und derzeit ist Pydantic die erste Wahl:
from fastapi import FastAPI
from pydantic import BaseModel
class Item(BaseModel):
name: str
description: str | None = None
price: float
tax: float | None = None
app = FastAPI()
@app.post("/items/")
async def create_item(item: Item):
return item
Auf den ersten Blick mag dieser Code wie die Art und Weise erscheinen, ORM oder Datenklassen zu schreiben, aber tatsächlich verwendet er die native Type Hints-Syntax von Python, um Feldtypen mit Anmerkungen zu versehen. Im obigen Beispiel wurde beispielsweise das Schema des Elements in der /items/-Anfrage klar definiert und die Werttypen jedes Felds sind explizit. Im Vergleich zu den alten Methoden zur Verwendung von Schemabeschreibungen oder sogar Hard-Codierung ist dieser Ansatz prägnanter, entspricht eher dem Python-Stil und bietet eine bessere IDE-Unterstützung.
Derzeit dominiert Pydantic den Bereich der Benutzerdatenvalidierung. Da es in FastAPI integriert ist, wird der Validierungsprozess erheblich vereinfacht und Fehler reduziert. Aus diesem Grund wird auf der offiziellen FastAPI-Website erwähnt, dass diese Lösung die Fehler von Entwicklern um bis zu 40 % reduzieren kann. Für eine dynamische Sprache wie Python ist die Anwendung von Pydantic unerlässlich, wenn Sie mypy nicht zur Typprüfung verwenden.
Dank der Integration von Pydantic wird außerdem das Hinzufügen eines ORM (wie SQLAlchemy) zum Projekt extrem einfach. Aus Anfragen erhaltene Objekte können direkt an die Datenbank übergeben werden, da die Datenvalidierung bereits abgeschlossen ist. Umgekehrt können aus der Datenbank abgerufene Objekte auch direkt zurückgegeben werden.
Im Gegensatz dazu mangelt es Flask in dieser Hinsicht.
In der Ära von Flask erfolgte die Codeausführung Single-Threaded und synchron. Dies bedeutete, dass Anfragen einzeln verarbeitet werden mussten und andere Anfragen Zeit damit verschwendeten, auf E/A-Vorgänge zu warten, bevor die vorherige abgeschlossen war. Asyncio hingegen ist die optimale Lösung. Es kann E/A-Vorgänge asynchron gestalten, sodass Sie Aufgabenergebnisse erhalten können, ohne auf den Abschluss der Aufgaben warten zu müssen, und dann mit der Bearbeitung anderer Aufgabenanforderungen fortfahren können.
FastAPI unterstützt nativ gleichzeitigen und asynchronen Code. Solange der Code korrekt geschrieben ist, kann er höchste Effizienz erzielen. Daher gilt es derzeit als das schnellste Python-Framework mit einer ähnlichen Effizienz wie NodeJS oder Go. Wenn Geschwindigkeit und Leistung von entscheidender Bedeutung sind, ist FastAPI zweifellos die beste Wahl.
Erwähnen wir zunächst WSGI. Der vollständige Name lautet „Python Web Server Gateway Interface“, auf den in „PEP 3333“ verwiesen werden kann (https://peps.python.org/pep-3333/). Es handelt sich um einen Python-Standard, der speziell für die Interaktion zwischen Webanwendungen und Servern geschrieben wurde. Wenn Sie PHP oder Ruby verwendet haben, ist es möglicherweise einfacher zu verstehen. Flask hängt von Werkzeug ab, einer WSGI-Suite, daher unterstützt Flask diesen alten WSGI-Standard und nicht ASGI.
Das Problem mit WSGI besteht darin, dass es Asynchronität nicht nutzen kann, um Leistung und Effizienz zu steigern. Der Django-Kanal war also Vorreiter bei ASGI. Der vollständige Name lautet „Asynchronous Server Gateway Interface“ und ist ein iterativer und nahezu komplett neu gestalteter Standard. Es bietet asynchrone Server-/Anwendungsschnittstellen und unterstützt HTTP, HTTP/2 und WebSocket. Im Gegensatz zu WSGI ermöglicht ASGI, dass jede Anwendung mehrere asynchrone Ereignisse hat. Darüber hinaus unterstützt ASGI sowohl synchrone als auch asynchrone Anwendungen. Sie können entweder alte synchrone WSGI-Webanwendungen zu ASGI migrieren oder ASGI verwenden, um neue asynchrone Webanwendungen zu erstellen.
Bevor wir Schlussfolgerungen ziehen, fügen wir fünf Begriffserklärungen hinzu:
In der Vergangenheit war die Produktionsumgebungslösung für WSGI normalerweise Nginx Gunicorn Flask (Django), während heutzutage die Produktionsumgebungslösung für ASGI Nginx Uvicorn FastAPI ist.
Noch etwas. Dem Namen und der Einführung von FastAPI nach zu urteilen, ist es offensichtlich, dass es für die Erstellung von API-Diensten konzipiert ist. Tatsächlich ist sein Kerncode genau so. Man kann sagen, dass es sich nicht um ein traditionelles, vollständig selbst implementiertes Framework handelt, sondern eher um ein Framework, das die Stärken verschiedener Frameworks vereint. Ausgehend von einer leeren Hülle setzt es die notwendigen und passenden Komponenten zusammen. Es verfügt beispielsweise nicht über eine Template-Engine. Wenn Sie es wirklich zum Erstellen einer Webanwendung verwenden müssen, die Vorlagenrendering erfordert, können Sie die benötigte Vorlagen-Engine auswählen und kombinieren. Natürlich können Sie auch den in Starlette integrierten Jinja2 verwenden (ja, er ist auch in Flask integriert).
Die oben genannten Vorteile von FastAPI reichen nicht aus, um den Schluss zu ziehen, dass Flask tot ist. Warum vertrete ich also diese Ansicht? Es kommt vor allem auf die Beliebtheit bei Entwicklern und Benutzern an.
Die „Beliebtheit“ ist hier eher subjektiv. Folgende Indikatoren fallen mir ein:
All diese Situationen deuten meiner Meinung nach darauf hin, dass die Blütezeit von Flask vorbei ist und FastAPI der aufstrebende Stern ist.
Lassen Sie mich abschließend die ideale Plattform für die Bereitstellung von Flask/FastAPI vorstellen: Leapcell.
Leapcell ist eine Cloud-Computing-Plattform, die speziell für moderne verteilte Anwendungen entwickelt wurde. Das Pay-as-you-go-Preismodell stellt sicher, dass keine Leerlaufkosten anfallen, d. h. Benutzer zahlen nur für die Ressourcen, die sie tatsächlich nutzen.
Die einzigartigen Vorteile von Leapcell für WSGI/ASGI-Anwendungen:
Erfahren Sie mehr in der Dokumentation!
Leapcell Twitter: https://x.com/LeapcellHQ
Das obige ist der detaillierte Inhalt vonIst die Flasche tot? Ist FastAPI die Zukunft?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
