Ist Flask tot? Ist FastAPI die Zukunft?

Während meiner Recherchen ist mir aufgefallen, dass selbst im Jahr 2024 noch eine beträchtliche Anzahl von Leuten Flask als Python-Webframework empfehlen. Meiner Meinung nach befindet sich Flask jedoch "auf dem absteigenden Ast, und FastAPI repräsentiert die Zukunft". Aus diesem Grund verfasse ich diesen Artikel. Ich lade jeden ein, sich an der Diskussion zu beteiligen und Gegenargumente vorzubringen.

Flask vs FastAPI

Flask hat einen bedeutenden Platz in den Herzen der Python-Entwickler. Wenn Sie ein Webentwickler sind, wette ich, dass Sie höchstwahrscheinlich Flask verwendet haben, aber vielleicht haben Sie sich noch nie mit FastAPI beschäftigt.

Hier sind zwei Beweise:

In den prominenten neuen Python-Projekten im Zusammenhang mit der Webentwicklung der letzten ein bis zwei Jahre haben fast alle, die Webentwicklung beinhalten, FastAPI übernommen.
Am 25. Dezember 2024 hat die Anzahl der Sterne für FastAPI (78,9k) auf GitHub bereits die von Flask (68,4k) übertroffen.

Werfen wir nun einen Blick auf die Veränderungen des Anteils der Webframeworks in den offiziellen Python Entwicklerumfragen:

Es ist offensichtlich, dass FastAPI im Jahr 2019 nicht einmal als Option aufgeführt war, aber bis 2022 hatte sein Anteil 25 % erreicht. (Derzeit haben wir nur Daten bis 2022.)

Es ist zu beachten, dass diese Anteilsdaten bestehende Systeme umfassen, sodass die Anteile von Django und Flask nicht schnell sinken werden. Dennoch ist der Trend klar.

Wir alle wissen, dass der Bereich der Webframeworks sehr produktiv ist, da fast jedes Jahr neue Frameworks entstehen. Die meisten dieser Frameworks sind kurzlebig, während es einigen gelingt, zu bestehen. FastAPI wurde Ende 2018 geboren und begann um das Ende des Jahres 2019, sich einen Namen zu machen. Wie konnte es also Flask, das Ende 2010 geboren wurde, innerhalb von nur fünf Jahren in Bezug auf die Popularität überholen? Als Nächstes wollen wir die Entwicklung der Python-Webframeworks und verwandten Lösungen entlang der Zeitachse verfolgen, um ein besseres Verständnis zu erlangen.

Die Entwicklung von Webframeworks (Plugins, Tools)

Der Autor von FastAPI ist ein Entwickler, der die Entwicklung des Python-Ökosystems sehr aufmerksam verfolgt. Der Link zur erweiterten Lektüre 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 bezogen hat. Der Abschnitt über die Entwicklungsgeschichte dieses Artikels bezieht sich ebenfalls auf dieses Stück. Ich würde empfehlen, den Originaltext zu lesen, da er die Gründe für das Aufkommen von FastAPI sowie einige der Designkonzepte des Autors enthält.

Flask

Flask ist ein "Mikro"-Framework, das Welten von Django entfernt ist. Es behält nur eine Handvoll Kernfunktionen und teilt, um zu entkoppeln, andere Funktionen in mehrere Bibliotheken auf (wie Jinja2, Werkzeug usw.). Dies gibt den Entwicklern viel Freiheit und ermöglicht es ihnen, mühelos Plugins von Drittanbietern für verwandte Funktionen zu schreiben. Seine internen Designs wie Blueprints, Kontexte und Dekorateure zur Darstellung von Routen, Signalen usw. waren zu dieser Zeit recht fortschrittlich. Gepaart mit umfassender Dokumentation ist es extrem anfängerfreundlich.

Flask REST Frameworks

Dank seiner Einfachheit ist Flask sehr gut geeignet, um APIs zu erstellen. Da Flask selbst jedoch keine eingebauten Funktionen mitbringt, benötigen wir spezialisierte REST-Frameworks. Folglich sind Frameworks wie flask-restful, Flask-RESTPlus und flask-api nacheinander entstanden. Darüber hinaus gibt es in REST-Diensten Anforderungen an Datenvalidierung, Parsing und Spezifikation, was zur Entstehung von Marshmallow, Webargs und APISpec führte, bis Flask-apispec hinzukam. Während dieses gesamten Entwicklungsprozesses hat sich jedoch nie ein Flask REST Framework materialisiert, das mit DRF vergleichbar wäre.

In dieser Phase sind die Schwächen von Flask allmählich in den Vordergrund getreten.

Die ursprünglichen Stärken von Flask liegen in seiner Flexibilität und seinem Minimalismus, aber dies bedeutet auch, dass eine grosse Anzahl von Komponenten intern entwickelt werden müssen. Dies erfordert entweder ein grosses Unternehmen mit engagierten Entwicklern für Entwicklung und Wartung oder äusserst fähige einzelne Entwickler. Andernfalls ist es schwierig für Plugins, Produktionsqualität zu erreichen, was zu einer gemischten Tüte von Drittanbieter-Plugins für Flask führt, ohne Garantie für langfristige Wartung. Wie bereits erwähnt, werden viele dieser Bibliotheken bereits nicht mehr gewartet.

Selbst heute noch müssen Sie, wenn Sie einen API-Dienst mit Flask erstellen möchten, verschiedene Komponenten zusammensetzen. Für einige Komponenten, die nicht zeitnah aktualisiert wurden, müssen Sie selbst Fehler beheben. Veteranen können es vielleicht bewältigen, aber für Anfänger ist es eher entmutigend, besonders wenn sie die neuesten Praktiken und Konzepte anwenden wollen.

Das Asyncio-Ökosystem

Seit Python 3.5 ist Asyncio der zukünftige Trend. Infolgedessen sind einige Webframeworks entstanden, die Asyncio nativ unterstützen, wie aiohttp, Starlette und Sanic.

Zu diesem Zeitpunkt war Flask widerwillig, sich anzupassen. Die Community hat nur langsam Unterstützung für Asyncio hinzugefügt, und der ursprüngliche Autor von Flask hat zum Schreiben von Rust gewechselt und das Projekt in die Hände von zwei Betreuern gegeben (jetzt ist nur noch einer übrig).

Projekte zum Erstellen von API-Diensten wie apistar und molten haben die Entstehung von FastAPI alle mit Designinspiration versorgt.

FastAPI

Dann wurde FastAPI geboren. Der Autor war ursprünglich auf der Suche nach einer guten Lösung, aber die oben genannten Situationen hatten jeweils ihre eigenen Probleme oder Einschränkungen. Also schuf der Autor dieses neue Framework.

Warum FastAPI herausragt

Dies ist der Kernteil des Artikels. Die folgenden Gründe sind genau die, warum FastAPI Flask ersetzen kann.

Benutzerdatenvalidierung mit Pydantic

Im Prozess der API-Entwicklung sind Datenformatvalidierung, Parsing und Serialisierung Routineoperationen. 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 des Schreibens von ORM oder Dataclass erscheinen, aber tatsächlich verwendet er die native Type Hints-Syntax von Python, um Feldtypen zu annotieren. Im obigen Beispiel wurde beispielsweise das Schema des Item in der /items/-Anfrage klar definiert, und die Werttypen jedes Feldes sind explizit. Verglichen mit den alten Methoden der Verwendung von Schema-Beschreibungen oder sogar Hardcoding ist dieser Ansatz prägnanter, entspricht eher dem Python-Stil und hat eine bessere IDE-Unterstützung.

Derzeit dominiert Pydantic den Bereich der Benutzerdatenvalidierung. Da FastAPI es eingebaut hat, wird der Validierungsprozess erheblich vereinfacht und Fehler werden reduziert. Aus diesem Grund erwähnt die offizielle FastAPI-Website, dass diese Lösung die Fehler der Entwickler 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 Typüberprüfung verwenden.

Darüber hinaus wird das Hinzufügen eines ORM (z. B. SQLAlchemy) zum Projekt dank der Integration von Pydantic äusserst einfach. Objekte, die aus Anfragen abgerufen werden, können direkt an die Datenbank übergeben werden, da die Datenvalidierung bereits abgeschlossen ist. Umgekehrt können auch Objekte, die aus der Datenbank abgerufen werden, direkt zurückgegeben werden.

Im Gegensatz dazu mangelt es Flask in dieser Hinsicht.

Asynchrones Design

In der Ära von Flask war die Codeausführung Single-Threaded und synchron. Dies bedeutete, dass Anfragen nacheinander verarbeitet werden mussten und andere Anfragen Zeit mit dem Warten auf E/A-Operationen verschwendeten, bevor die vorherige abgeschlossen war. Asyncio hingegen ist die optimale Lösung. Es kann E/A-Operationen asynchron machen, sodass Sie Aufgabenergebnisse erhalten können, ohne auf den Abschluss der Aufgaben zu warten, und dann mit der Bearbeitung anderer Aufgabenanfragen fortfahren können.

FastAPI unterstützt nativ gleichzeitigen und asynchronen Code. Solange der Code korrekt geschrieben ist, kann er Spitzeneffizienz erreichen. Daher gilt es als das schnellste Python-Framework derzeit, mit einer ähnlichen Effizienz wie NodeJS oder Go. Wenn Geschwindigkeit und Leistung von entscheidender Bedeutung sind, ist FastAPI zweifellos die beste Wahl.

Native Unterstützung für ASGI

Erwähnen wir zunächst WSGI. Sein vollständiger Name ist "Python Web Server Gateway Interface", auf das in "PEP 3333" verwiesen werden kann (https://peps.python.org/pep-3333/). Es ist ein Python-Standard, der speziell für die Interaktion zwischen Webanwendungen und Servern geschrieben wurde. Wenn Sie PHP oder Ruby verwendet haben, fällt es Ihnen möglicherweise leichter, dies zu verstehen. Flask ist von Werkzeug abhängig, das eine WSGI-Suite ist, sodass Flask diesen alten WSGI-Standard und nicht ASGI unterstützt.

Das Problem mit WSGI ist, dass es Asynchronie nicht nutzen kann, um Leistung und Effizienz zu steigern. Also hat Django Channel ASGI entwickelt. Sein vollständiger Name ist "Asynchronous Server Gateway Interface", das ein iterativer und fast vollständig neu gestalteter Standard ist. Es bietet asynchrone Server-/Anwendungsschnittstellen und unterstützt HTTP, HTTP/2 und WebSocket. Im Gegensatz zu WSGI ermöglicht ASGI jeder Anwendung mehrere asynchrone Ereignisse. 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:

ASGI Toolkit: Bibliotheken, die ASGI-bezogene Funktionen implementieren (z. B. URL-Routing, Request/Response-Objekte, Template-Engines usw.). In diesem Artikel bezieht es sich hauptsächlich auf Starlette, was der Abhängigkeit von Flask, Werkzeug, entspricht.
ASGI Web Framework: Webframeworks, die die ASGI-Spezifikation implementieren (z. B. FastAPI), während Flask und Django Webframeworks sind, die WSGI implementieren. Diese Frameworks sind für Entwickler konzipiert, um Anwendungen mit einfach zu bedienenden Schnittstellen zu schreiben. Entwickler müssen nur die Geschäftslogik nach ihren Bedürfnissen ausfüllen. Frühe Frameworks implementierten meist ASGI-Toolkits intern, während spätere Frameworks in der Regel geeignete Toolkits kombinieren. Zum Beispiel verwendet Flask Werkzeug (sein eigenes), und FastAPI verwendet Starlette (von anderen).
Webanwendung: Eine Anwendung, die mit einem Webframework erstellt wurde, ist eine Webanwendung. In der Regel verfügen Webframeworks über einen Testserver, der für Entwicklung und Debugging gestartet werden kann. Wenn Leistung und Stabilität kein Problem sind, können Sie bereits über die Entwicklungsadresse im Browser auf diese Anwendung zugreifen.
Webserver: Die reale Welt ist komplexer als erwartet. Nachdem eine Webanwendung in der Produktionsumgebung bereitgestellt wurde, müssen Anforderungen wie Anforderungslastausgleich, Bereitstellung statischer Dateien, Zugriffskontrolle und Reverse Proxy berücksichtigt werden, und es gibt auch hohe Leistungsanforderungen. Die eingebauten Webserver von Webframeworks können diese Anforderungen überhaupt nicht erfüllen, daher werden spezielle Webserver benötigt. Derzeit ist Nginx die Mainstream-Wahl.
ASGI Server: Der ASGI-Server fungiert als Brücke zwischen dem Webserver und der Webanwendung. Der ASGI-Server hält sich auch an die ASGI-Spezifikation, aber seine Hauptaufgabe ist es, die Leistungsanforderungen der Weiterleitung von Anfragen zu erfüllen, sodass er sich hauptsächlich um den "G"-Teil (Gateway) von ASGI kümmert. Sein Code ist für Entwickler nicht benutzerfreundlich, um Webanwendungsgeschäft und Routing-Logik zu schreiben. Derzeit ist der bekannteste ASGI-Server Uvicorn, und die uvicorn.workers.UvicornWorker, die ursprünglich vom WSGI-Server Gunicorn stammt, ist ebenfalls eine Option. Dies sind die empfohlenen Verwendungen in der Produktionsumgebung.

In der Vergangenheit war die Produktionsumgebungslösung für WSGI in der Regel Nginx + Gunicorn + Flask(Django), während heutzutage die Produktionsumgebungslösung für ASGI Nginx + Uvicorn + FastAPI ist.

Noch eine Sache. Betrachtet man den Namen und die Einführung von FastAPI, so ist es offensichtlich, dass es für die Erstellung von API-Diensten entwickelt wurde. 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 kombiniert. Ausgehend von einer leeren Hülle werden die notwendigen und geeigneten Komponenten zusammengesetzt. Es hat zum Beispiel keine Template-Engine. Wenn Sie es wirklich verwenden müssen, um eine Webanwendung zu erstellen, die Template-Rendering erfordert, können Sie die Template-Engine auswählen und kombinieren, die Sie benötigen. Natürlich können Sie auch Jinja2 verwenden, das in Starlette eingebaut ist (ja, es ist auch in Flask eingebaut).

Warum gesagt wird, dass Flask tot ist

Die oben genannten Vorteile von FastAPI reichen nicht aus, um zu dem Schluss zu kommen, dass Flask tot ist. Warum vertrete ich also diese Ansicht? Es läuft hauptsächlich auf die Popularität bei Entwicklern und Anwendern hinaus.

Die "Popularität" ist hier eher subjektiv. Die Indikatoren, die mir einfallen, sind wie folgt:

Community-Aktivität(https://github.com/pallets/flask/issues): Nehmen Sie zum Beispiel die Anzahl der Probleme und Pull-Requests des Projekts. Flask hat nur einstellige Zahlen, was im Vergleich zu FastAPI völlig anders ist. Dies spiegelt eigentlich von der Seite wider, dass das Projekt nicht mehr aktiv ist. Wenn das Projekt aktiv ist, haben alte Benutzer mehr Bedürfnisse. Wenn sie aufhören, Fragen zu stellen, bedeutet das, dass sie gegangen sind. Und neue Benutzer werden sicherlich alle Arten von Problemen haben. Selbst bei detaillierter Dokumentation sollte es immer noch viele Benutzer geben, die Fragen stellen und Code beisteuern. Das Fehlen solcher Situationen deutet auf weniger Benutzer hin.
Diskussionshitze: Das heisst, die Popularität von Anfragen und Diskussionen auf Blogbeiträgen, Stack Overflow und anderen Websites. Es ist ganz offensichtlich, dass es heutzutage nur sehr wenige Leute gibt, die über Flask schreiben.
Entwicklungsiterationsfrequenz(https://github.com/pallets/flask/pulls): Betrachtet man die Commit-Protokolle, so können wir sehen, dass Flask nur einen Betreuer hat, der gelegentlich einige Fehler behebt, ohne dass es eine grössere Funktionsentwicklung gibt.
Einfluss der Schlüsselfigur: Die Schlüsselfigur hinter Flask, der Projektinitiator, hat die Teilnahme an dem Projekt längst eingestellt. Laut den Projektbeitragsaufzeichnungen hat Armin Ronacher vor sechs Jahren zum letzten Mal zur Entwicklung beigetragen.

All diese Situationen deuten meiner Meinung nach darauf hin, dass Flasks Blütezeit vorbei ist und FastAPI der aufsteigende Stern ist.

Lassen Sie mich abschliessend 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 nutzungsabhängige Preismodell stellt sicher, dass keine Leerlaufkosten entstehen, was bedeutet, dass Benutzer nur für die Ressourcen bezahlen, die sie tatsächlich nutzen.

Die einzigartigen Vorteile von Leapcell für WSGI/ASGI-Anwendungen:

1. Mehrsprachige Unterstützung

Unterstützt die Entwicklung in JavaScript, Python, Go oder Rust.

Kostenlose Bereitstellung von unbegrenzten Projekten

Die Gebühren werden nur nutzungsabhängig erhoben. Keine Gebühren, wenn keine Anfragen vorliegen.

2. Unübertroffene Kosteneffizienz

Pay-as-you-go, ohne Leerlaufgebühren.
Zum Beispiel können 25 $ 6,94 Millionen Anfragen unterstützen, mit einer durchschnittlichen Antwortzeit von 60 Millisekunden.

3. Vereinfachte Entwicklererfahrung

Intuitive Benutzeroberfläche für einfache Einrichtung.
Vollautomatische CI/CD-Pipelines und GitOps-Integration.
Echtzeitmetriken und -protokolle, die umsetzbare Erkenntnisse liefern.

4. Mühelose Skalierbarkeit und hohe Leistung

Automatische Skalierung zur einfachen Bewältigung hoher Parallelität.
Null Betriebsaufwand, sodass sich Entwickler auf die Entwicklung konzentrieren können.

Erfahren Sie mehr in der Dokumentation!

Leapcell Twitter: https://x.com/LeapcellHQ