Cool to see this here, using Litestar for a new project having selected and used Django/DRF company-wide in the past. I find it provides a modern "batteries-included" stack for Python, not quite as comprehensive as Django, but also not as minimal as Flask or FastAPI. For me, the advantages over Django include typing, async-first, websocket-support, along with integrations with existing projects (including Pydantic, SQLAlchemy, Jinja, OpenAPI). The higher bus-factor and release cadence was also a factor in choosing it over FastAPI.
ASGI (Asynchronous Server Gateway Interface) is a spiritual successor to WSGI, intended to provide a standard interface between async-capable Python web servers, frameworks, and applications.Where WSGI provided a standard for synchronous Python apps, ASGI provides one for both asynchronous and synchronous apps, with a WSGI backwards-compatibility implementation and multiple servers and application frameworks. [1]
And WSGI:
The Web Server Gateway Interface (WSGI, pronounced whiskey or WIZ-ghee) is a simple calling convention for web servers to forward requests to web applications or frameworks written in the Python programming language. [2]
I love their docs, I sometimes read them when I'm working on other projects because the design and or suggestions are great. Afaik there's no great connectors for OIDC which is why we can't use it at $work but I'd like to try it more in depth in a personal project.
I need to think a bit more about what I want exactly. In short, I'm trying to manage auth through Keycloak but I also need a way to manage user sessions so there needs to be a way to store tokens generated by Keycloak in a DB in the backend and properly sync token invalidation/refresh with Keycloak.
It’s been my experience that async Python frameworks tend to turn IO bound problems into CPU bound problems with a high enough request rate, because due to their nature they act as unbounded queues.
This ends up made worse if you’re using sync routes.
If you’re constrained on a resource such as a database connection pool, your framework will continue to pull http requests off the wire that a sane client will cancel and retry due to timeouts because it takes too long to get a connection out of the pool. Since there isn’t a straightforward way to cancel the execution of a route handler in every Python http framework I’ve seen exhibit this problem, the problem quickly snowballs.
I’ve used and quite like it. We switched because it has better documentation and is designed in a more extensible way, common patterns weren’t supported in FastAPI are here, unfortunately it’s been a few years so I can’t remember details beyond things like lifecycle events being missing, etc.
In Flask applications (and I suppose, Quart) you can use the `current_app` object to hold onto a service container that itself can register/retrieve services.
It's very manual, and is annoying because you have to retrieve the container and then all of your services in your handler/controller, but there's no convention nor magic (and can give you type info), so I've rolled with it.
That's an interesting take! As one of the maintainers, I like the featureset we have and use it in multiple production apps at work, but think that our documentation is one sore spot compared to e.g., Django and FastAPI. Not to say it isn't good, but I think FastAPI and Django's docs are pretty great.
Currently using with the following,
- [SAQ](https://saq-py.readthedocs.io/en/latest/) for background workers
- [Nginx Unit](https://unit.nginx.org/) for deployment
- [Orval](https://orval.dev/) to generate FE definitions based on the API spec.
For non-API/SPA use-cases, there are Jinja and HTMX integrations. The docs (https://docs.litestar.dev/latest/) are solid - not quite Django-tier but that's the gold standard, however the reference example is too complex imo (https://github.com/litestar-org/litestar-fullstack).
https://github.com/litestar-org/awesome-litestar has a list of useful extensions - highly recommend trying it out if you are starting a new Python web project.