Litestar sollte man sich einmal ansehen

• Litestar ist ein unter den asynchronen Python-Web-Frameworks weniger bekannter Geheimtipp
• Dank schneller Skalierbarkeit und flexibler Architektur lässt es sich leicht in verschiedensten Projekten einsetzen
• Es bietet Datenmodellierung ohne Abhängigkeit von bestimmten Bibliotheken wie Pydantic
• Die SQLAlchemy-Integration ist hervorragend und bietet Stärken bei Datenbankanbindung und -verwaltung
• Mit praktischen eingebauten Funktionen für Authentifizierung, Caching, Logging, Monitoring usw. ist es sofort in der Praxis einsetzbar

---

Überblick über Litestar

• In den letzten Jahren haben async-first, auf Type Hints basierende Python-Web-Frameworks viel Aufmerksamkeit erhalten; unter ihnen wurde Litestar ausgewählt, um praktische Erfahrung damit zu sammeln
• Da Litestar in mehreren realen Projekten als Haupt-Framework eingesetzt wurde, ist die Überzeugung von dieser Entscheidung immer weiter gewachsen
• Viele Python-Webentwickler kennen Litestar noch nicht, daher stellt dieser Artikel seine wichtigsten Vorteile und Besonderheiten vor

Beispiele und Framework-Vergleich

• Mit Litestar lässt sich auch eine sehr einfache Single-File-Webanwendung problemlos schreiben

  • Ein Route-Decorator ist eine unabhängige Funktion, die nicht an ein App-Objekt gebunden ist
  • Im Beispielcode wird bei einem Aufruf von /greet?name=Bob „Hi, Bob!“ zurückgegeben
  • Fehlt ein Pflichtparameter, wird automatisch eine 400-Antwort geliefert

• Anders als bestehende Python-Mikroframeworks wie Flask oder FastAPI hat Litestar strukturelle Eigenschaften, die sich bei Projekten unterschiedlichster Größen ganz natürlich erweitern lassen

  • Bei Flask oder FastAPI sind Routing-Decoratoren an das App-Objekt gebunden, wodurch bei der Aufteilung auf mehrere Dateien Probleme mit zirkulären Imports entstehen können
  • Meist muss man untergeordnete Route-Registries nutzen (bei Flask/Quart etwa Blueprints, bei FastAPI APIRouter usw.), was die Einstiegshürde erhöhen oder strukturelle Änderungen erforderlich machen kann
  • Bei Litestar ist der Decorator jedoch eine unabhängige Funktion, sodass der Wechsel zwischen einer Ein-Datei-App und einer großen verteilten Struktur sehr schlank ausfällt

• Dank der grundlegenden Architektur und Art der Dokumentation von Litestar lassen sich Konzepte wie Router und Funktionsgruppen schon sehr früh einführen, wodurch sich auch bei komplexen API-Strukturen leicht Konsistenz wahren lässt

  • Dependency Injection, Berechtigungen und gemeinsam genutzte pfadbezogene Konfiguration sind Stärken seiner Composability
  • Dieselbe Route kann mehrfach registriert werden, sodass sich je nach Umgebung Authentifizierung oder Abhängigkeiten unterschiedlich anwenden lassen

Datenmodellierung ohne Pydantic-Abhängigkeit

• FastAPI und ähnliche Frameworks hängen bei Daten stark von Pydantic ab

  • Pydantic ist stark bei typbasierter Datenvalidierung und Serialisierung, jedoch ist eine direkte Anbindung an ORMs (SQLAlchemy) schwierig
  • In der Praxis ist es oft umständlich, SQLAlchemy-Modelle und Pydantic-Modelle jeweils getrennt zu schreiben

• Litestar unterstützt nicht nur Pydantic, sondern allgemein verschiedene Typen wie dataclasses, msgspec, attrs, SQLAlchemy model

  • Mit einem Serialization-Plugin-Protokoll ist die Erweiterbarkeit hoch
  • Eine Funktion zur automatischen Extraktion von Datenübertragungsobjekten (DTOs) ist integriert, sodass Änderungen an der ursprünglichen Datenklasse automatisch im DTO berücksichtigt werden
  • Auch das Ausschließen oder Einschließen einzelner Felder, Namenszuordnungen und DTOs für partielle Updates lassen sich einfach deklarieren
  • Dadurch lassen sich doppelte Deklarationen von Modellfeldern und häufige Fehler bei manueller Synchronisierung vermeiden

Integration mit SQLAlchemy und Einführung in Advanced Alchemy

• Das SQLAlchemy ORM ist faktisch der Standard für die Python-Datenbankanbindung

  • Litestar bietet eine sehr starke Integration mit automatischer Serialisierung von SQLAlchemy-Schemata, DTO-Automatisierung, Session-Management-Plugins und kombinierten Plugins

• Über die Bibliothek Advanced Alchemy (vom Litestar-Team gepflegt) werden die SQLAlchemy-Funktionen erweitert

  • Sie bietet zahlreiche Funktionen zur Qualitätsverbesserung, darunter datenbankagnostische große Primärschlüssel, automatische Zeitstempel, UUID-Schlüssel, JSON-Typen, Alembic-Migrationsintegration sowie Seed/Export
  • Besonders bemerkenswert ist die Unterstützung für Abstraktionen von Repository- und Service-Layern, die CRUD, Paginierung und weitere Repository-Funktionen automatisch bereitstellt
  • In Frameworks, die anders als Django nur schwache strukturelle Leitlinien bieten, schafft dies eine Organisationsform, in der sich die Einführung eines Repository-/Service-Layers empfiehlt

Weitere Merkmale und eingebaute Unterstützungsfunktionen

• Litestar bietet intern auch ein Authentifizierungssystem (Guard-Funktionen, Middleware), Caching (stores), Logging, standardisierte Problemantworten, auf Prometheus/OpenTelemetry basierende Metriken sowie htmx-Unterstützung
• Anders als bei anderen Mikroframeworks ist es für bestimmte Funktionen nicht nötig, erst separate externe Bibliotheken zu suchen oder eigenes Glue Code zu schreiben
• Es bewahrt die Einfachheit eines „Mikroframeworks“, erlaubt aber zugleich, Erweiterungen oder Zusatzfunktionen bei Bedarf sofort zu nutzen
• Es ist weniger ein Ersatz für Django/Flask, sondern eher ein Konzept, das die Stärken von Frameworks anderer Sprachen wie Java Spring Boot (frühe Struktur, Komfort usw.) auf Pythonic-Art übernimmt
• Insgesamt ist es für praktische Python-Webentwicklung eine Option mit hoher Produktivität und strukturellen Vorteilen

Fazit

• Dank Asynchronität, typbasierter Entwicklung, flexibler Erweiterbarkeit, lockerer Datenmodellierung sowie hervorragendem ORM und eingebauten Funktionen entwickelt sich Litestar zu einem Framework, das sich Python-Webentwickler unbedingt einmal ansehen sollten
• Die wiederholte Nutzung in realen Projekten hat gezeigt, dass es auch in unterschiedlichen Projektumgebungen wie Startups eine hohe Produktivität und Wartbarkeit bietet
• Es bleibt zu hoffen, dass Entwickler Litestar bei der Planung ihres nächsten Python-Webprojekts als eine der Optionen in Betracht ziehen

[minhoryang]

Gibt es für das „zirkuläre Importproblem“ in Python nicht ohnehin eine recht klare Lösung? Es wirkt etwas schade, das als gravierendes Problem zu betrachten.

[GN⁺]

Hacker-News-Kommentare

• Ich habe im vergangenen Jahr mit FastAPI ein großes Backend-Projekt entwickelt. Angefangen habe ich im Stil des offiziellen Tutorials, aber sowohl die offizielle FastAPI-Vorlage, die dazu anhält, sämtliches CRUD in eine Datei zu packen, als auch die Art des Dependency-Managements fand ich unpraktisch. Bei der Verwendung von SQLModel stieß ich zudem auf mehrere Einschränkungen, etwa fehlende Unterstützung für polymorphe Modelle, und selbst Verbesserungs-PRs aus der Community wurden monatelang nicht einmal begutachtet, sodass ich am Wartungszustand zu zweifeln begann. Auch die Dokumentation bot zu wenig wirklich brauchbare Referenzinformationen, sodass ich am Ende sogar den Quellcode durchsuchen musste. Für schnelles CRUD ist es in Ordnung, aber für komplexe Systeme würde ich es nicht empfehlen, weil es sich anfühlt, als würde man noch ein Framework auf das Framework draufsetzen. Ab morgen plane ich die Migration zu Litestar
  • Wenn man sich mit praxisnahen Beispielen großer FastAPI-Anwendungen beschäftigen will, dürfte der Server-Code des polarsource/polar-Repos hilfreich sein. Authentifizierung, Tests und andere reale Skalierungsbeispiele sind dort gut gesammelt, daher möchte ich lernen, indem ich die Implementierungsweise dieses Repos nachvollziehe
  • Ich arbeite mich gerade in API-zentriertes App-Design ein und habe aus diesem Beitrag viele Architektur- und Tooling-Punkte gelernt, an die ich vorher nicht gedacht hatte. Ich denke auch darüber nach, Litestar auszuprobieren. Danke für den nützlichen Kommentar und den Beitrag
  • Ich stimme nicht zu, dass SQLModel im offiziellen FastAPI-Tutorial überbetont wird. Auf der Startseite wird SQLModel gar nicht erwähnt, und behandelt wird es nur auf der Seite zur Anbindung relationaler Datenbanken. Dass ein Tutorial ein bestimmtes ORM verwendet, ist eine natürliche Wahl, und wenn SQLModel nicht passt, sollte der Nutzer eben eine andere Option wählen. Ich selbst habe mich nach dem Tutorial für plain SQLAlchemy entschieden
  • Beim Lesen der Litestar-Dokumentation habe ich gesehen, dass auch ein Event-System eingebaut ist. Das ist eine Funktion, die ich in FastAPI über mehrere Wochen separat gebaut und genutzt habe, während sie in Litestar von Anfang an vorhanden ist
  • Ich frage mich allerdings, ob Litestar nicht ebenfalls gewisse Grenzen hat. Community, Dokumentation und Diskussionen sind kleiner als bei FastAPI; mich würde interessieren, ob ihr es trotzdem für besser geeignet für komplexe Anwendungen haltet
• Litestar ist hervorragend für den Aufbau von API-Backends. Ich nutze es selbst und empfehle es sehr. Auch Advanced Alchemy wird zunehmend besser. Sogar altmodische Websites mit serverseitigem Template-Rendering lassen sich mit Litestar gut bauen, und ein Plugin für HTMX ist ebenfalls integriert. Allerdings wirken die Muster für das Design von API-Endpunkten bei traditionellen serverseitig gerenderten Endpunkten mit Formularvalidierung, Redirects usw. teils etwas unbeholfen. Litestar selbst hat keine echte Formularverarbeitung im eigentlichen Sinne, wodurch sich Fehler pro Formularfeld nur schwer sauber behandeln lassen. Das Muster mit @post("/route", exception_handlers={...}) fühlt sich etwas sperrig an. Ich hoffe künftig auf bessere eingebaute Tools und Verbesserungen der Developer Experience
  • Ich habe Litestar selbst nie benutzt, aber wäre es nicht möglich, einen eigenen Decorator wie @postform zu bauen, der die komplette Formularbehandlung übernimmt?
• Litestar ist ein Python-Web-Framework. Nur zur Info für alle, die neugierig sind
  • Es gab auch Leute, die meinten, dass ihnen das Zeit gespart habe
• Ich betreibe seit über einem Jahr mit Litestar gleichzeitig JSON- und templatebasiertes HTML-Serving. Es ist schneller als FastAPI und ein leichtgewichtiges Python-Async-Framework, das dennoch wesentliche Funktionen wie Authentifizierung und Sessions gut mitbringt. Besonders gefallen mir die Unterstützung für msgspec und verschachteltes Routing auf Controller-Basis. Klare Empfehlung
  • Ich bin in einem neuen Projekt ebenfalls von FastAPI auf Litestar umgestiegen und nutze es ohne Reue sehr zufrieden. Schon die Basis von Litestar vermittelt deutlich mehr Reife und Vertrauen
  • Ich nutze FastAPI seit einigen Jahren, aber Litestar scheint auf jeden Fall einen Versuch wert zu sein
• Ich habe über mehrere Jahre Anwendungen mit FastAPI entwickelt und ähnliche Unzufriedenheit verspürt. Viele sagen, dass die FastAPI-Dokumentation mit ihrem Fokus auf Tutorials und Beispiele in realer Entwicklung und bei echter API-Qualitätsbewertung an der Praxis vorbeigeht. Es überrascht mich, wie oft genau dieser Punkt angesprochen wird
  • Es ist eine große Enttäuschung, dass sich die Dokumentation aktueller Python-Frameworks insgesamt wie bei JavaScript-Bibliotheken anfühlt – eher wie „Tutorial + plaudernder Blog“ – und dass echte Referenzen mit API-Details und Parameterbeschreibungen fehlen. Was gebraucht wird, ist eine echte API-Referenzdokumentation: detaillierte Optionen pro Methode, sauber aufgelistete Parameter, und statt bloßer Kommentarsätze sollten die Optionen korrekt dokumentiert werden. Dass man den Quellcode durchsuchen muss, um endlich klare Informationen zu finden, ist extrem unpraktisch
• FastAPI ist zwar brauchbar, hat aber beim Bau komplexer Apps einige Grenzen. Manchmal wundert es mich, wie das Python-Mikroframework-Ökosystem Themen verspätet wiederentdeckt, mit denen JavaEE schon vor 15 Jahren zu kämpfen hatte. Litestar wirkt ziemlich gut. Mich interessiert auch, wie dort Streaming-Fehlerfälle gehandhabt werden
• FastAPI ist populär, aber für kleine Projekte war ich auch mit starlette allein sehr zufrieden. Es hat zwar nicht alles, aber für einfache Services fehlt es an nichts. Litestar scheint vom Umfang her eher in Richtung FastAPI oder Django zu gehen
  • In letzter Zeit baue ich APIs nur noch direkt mit starlette. Es ist sauber, schlank, die offizielle Dokumentation ist gut, und es skaliert unabhängig von der Projektgröße gut
• Ich hatte schon immer Interesse an Litestar, habe es aber noch nicht selbst benutzt. Ich nutze FastAPI schon ziemlich lange, und die Behauptung, große Codebasen ließen sich damit schwer verwalten, scheint mir etwas übertrieben. Wenn man Routen auf mehrere Dateien verteilt, importiert und als großen Baum strukturiert, ist genug Skalierbarkeit da. Ich stimme allerdings zu, dass offizielle Leitfäden zur Strukturierung größerer Projekte fehlen. Mit Best Practices und einer Aufteilung der Dateien nach Modulen je nach persönlicher Präferenz ließ sich aus meiner Sicht ausreichend Skalierbarkeit erreichen. SQLAlchemy habe ich in FastAPI allerdings nicht direkt verwendet, daher kann ich den damit verbundenen Schmerz wohl nicht ganz nachvollziehen
• Das ist ein Beitrag, der wichtige Punkte für die Entwicklung realer Anwendungen gut trifft. Das Design von Litestar ist wirklich attraktiv. Ich bin auch auf die Sichtweise zum Repository-Pattern gespannt. Es wäre schön, das in einem eigenen Beitrag ausführlicher zu behandeln
• Der Beitrag war ziemlich gut. SQLAlchemy ist schwer zu handhaben und hat einen komplexen Zustand mit vielen überraschenden Aspekten, daher frage ich mich, ob manche Leute komplett ohne dessen Einsatz entwickeln
  • Ich habe kürzlich in einem privaten Projekt mit peewee entwickelt; es hat zwar nicht viele Zusatzfunktionen, erledigt seine Aufgabe aber gut
  • Zwischen traditionellem SQLAlchemy und Litestars Advanced Alchemy, das zwar ebenfalls auf SQLAlchemy basiert, gibt es einen deutlichen Unterschied. Früher habe ich reines SQL oder SQLAlchemy verwendet, aber seit dem Wechsel von django ninja zu Litestar versuche ich den Einsatz von SQLAlchemy immer weiter zu reduzieren
  • Das Interessanteste an diesem Projekt ist, dass es einige der Schwächen von SqlAlchemy abzufedern scheint. Wann immer ich ein Projekt beginne, das eine Datenbank braucht, lande ich am Ende doch wieder bei Django. SqlAlchemy und Alembic sind Schmerzen, die ich nicht unbedingt ertragen möchte
  • Die realistischste Art, SQLAlchemy zu verwenden, besteht meiner Meinung nach darin, Modelle und Alembic nur für Schemadefinition und Migrationen zu nutzen und tatsächliche Queries oder Transaktionsverwaltung direkt in SQL zu schreiben. Der Zeitaufwand für das Umformen von Queries mit dem ORM ist zu groß
  • Ich verwende meist asyncpg