Litestar – powerful, flexible, and highly performant Python ASGI framework | Hacker News Reader

Litestar – powerful, flexible, and highly performant Python ASGI framework

litestar.dev

68 pointsrob17 comments

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.

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.

That's a very interesting stack, thanks for sharing!

For others that are immune to acronyms:

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]

[1] https://asgi.readthedocs.io/en/latest/

[2] https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface

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.

What would you like to see here? Could you perhaps open an issue at https://github.com/litestar-org/litestar so we can track and implement this?

If you are just needing a client what you need should be available OOTB, unless you want more hands off.

Here is also a good article for example: https://dev.to/pbaletkeman/secure-python-litestar-site-with-...

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.

Looks like it fits in a nice space between FastAPI and Django, with some batteries included and an async-first approach.

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.

This is an issue with fastapi, too- https://github.com/tiangolo/fastapi/issues/5759

The solution mentioned in the issue is the same one I use, `run_in_threadpool`. Does that not work for you?

Threadpools incur high overhead but that should work mostly.

Also, in Litestar Sync is a first class citizen just as much as async is.

You can see in benchmarks (that shouldnt be taken as gospel) how frameworks drop off in sync perf., where Litestar maintains both well.

https://docs.litestar.dev/latest/benchmarks.html

Here is a real world use case review from a company that has products serving the NCAA/NFL

https://www.reddit.com/r/starlite/comments/10xo6ra/user_show...

Can it be used synchronously (no async, gevent)?

Litestar supports synchronous as well as asynchronous callables in almost all places where it’s possible to do so.

https://docs.litestar.dev/latest/topics/sync-vs-async.html

Who uses this and can compare against FastAPI?

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.

Do you like the dependency injection?

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.

Reply on news.ycombinator.com