[HN Gopher] Litestar is worth a look
___________________________________________________________________
Litestar is worth a look
Author : todsacerdoti
Score : 120 points
Date : 2025-08-06 19:43 UTC (3 hours ago)
(HTM) web link (www.b-list.org)
(TXT) w3m dump (www.b-list.org)
| monadoid wrote:
| This is well written, thanks!
| cr125rider wrote:
| Litestar is awesome. It's great it's got more than a single
| maintainer too.
| ddejohn wrote:
| Excellent post that actually gets into important details for
| real-world applications. I'm a huge fan of the design of
| Litestar.
|
| > I also still think there are a lot of bad use cases for
| repositories and service layers that people should avoid, but
| that's a digression which should probably become its own post
|
| As a huge proponent of the repository pattern, I'll be looking
| forward to this post.
| punnerud wrote:
| Good to see it using port 8000 as default, and not Flasks 5000
| (does not work on Mac anymore)
| femtozer wrote:
| I wasted a couple of hours recently before realizing that
| AirPlay was using port 5000...
| hnuser123456 wrote:
| It's a python web framework, for those curious to know more
| before clicking through.
| LigmaBaulls wrote:
| thanks, saved me some time.
| NeutralForest wrote:
| Pretty cool post! I'm not sure how I feel about SQLAlchemy (not
| the star of the post but mentioned quite a bit); it's such a big
| ball of state that has so many surprises, I wonder if some people
| build entirely without it.
| devjab wrote:
| There is a rather big difference between traditional SQLAlchemy
| and Advanced Alchemy which is also made by Litestar. We've
| build with pure SQL and with SQLAlchemy in the past, but since
| we transitioned from django ninja to Litestar, we've not used
| SQLAlchemy and are slowly moving away from it. Well I guess
| Advanced Alchemy is still SQLAlchemy under the hood.
| sambaumann wrote:
| I recently built a personal project using peewee and it doesn't
| have a ton of bells and whistles but it works well for what it
| does do.
| jessekv wrote:
| I usually just use asyncpg.
| MitPitt wrote:
| You can use asyncpg in SQLAlchemy
| jessekv wrote:
| Yep! But I don't.
| WD-42 wrote:
| The most interesting thing about this project to me is that it
| appears to alleviate some of the warts of working with
| SqlAlchemy.
|
| Pretty much every time I start a project that needs a DB I just
| use Django. SqlAlchemy and Alembic are usually not worth
| dealing with.
| hariwb wrote:
| Thanks for writing this. I have similar gripes about FastAPI
| having developed an application over the past few years; I'm also
| continually surprised at how prevalent the attitude is that
| FastAPI has excellent docs, given how divorced the tutorial / toy
| examples in the docs are from real-world development and
| measurement of an API.
| rtpg wrote:
| I am really disappointed at the new generation of Python
| frameworks' documentation, which seem to have the same "docs
| are tutorials + chatty blog posts which imprecisely describe
| the APIs" attitude of Javascript libs.
|
| Two words: API Reference.
|
| Have the clinical explanation of methods exposed, with actual
| breakdowns of what method parameters do. List them all, don't
| surround it by prose. List out the options! Don't make me dive
| into the source to find out what I can or can't pass into a
| parameter!
|
| Having to play this game of "alright I want to know how to use
| this API, so first I need to figure out what tutorial page
| _might_ use this" to find the tiny examples that should just be
| next to the methods I care about in the reference is really
| frustrating.
| rmonvfer wrote:
| This, I've already said it in another reply but FastAPI is
| 10x harder to use because of this. I've had to read FastAPI
| code many times to literally reverse engineer features
| because they are not documented in any way.
|
| Documentation is for reference, tutorials are for learning, I
| just don't even understand how maintainers don't go crazy
| with the absolute lack of references...
|
| And SQL Model is even worse in that regard.
| cbzbc wrote:
| How do people deploy this framework typically - speaking for
| myself, I found NGINX Unit somewhat fiddly.
| devjab wrote:
| With uvicorn.
| intalentive wrote:
| uvicorn systemd service behind nginx reverse proxy
| indigodaddy wrote:
| Or just docker/uvicorn
| intalentive wrote:
| I've been using Litestar for over a year now, serving both JSON
| and templated HTML. Great all-around Python async framework that
| manages to be fast (faster than FastAPI), lightweight, and still
| has enough batteries included to host a website with auth,
| sessions, etc. I'm a fan of first-class msgspec support and the
| Controller class for nested routing.
|
| Highly recommend.
| icedchai wrote:
| It definitely seems worth checking out. I've been using FastAPI
| for a few years now.
| thewisenerd wrote:
| love litestar.. working on migrating a couple of internal
| consoles to it from fastAPI.
|
| the docs could use some love though.
|
| i feel most of it is references [1], the "how to"s could be
| better.
|
| inb4, "where pull request", i don't grok asgi or the framework
| nuances to be able to say how to improve on it.
|
| [1] https://diataxis.fr/
| rmonvfer wrote:
| Thank you for writing this, I've been building a large backend
| with FastAPI for the last year or so and I've gone through all
| the levels of the purgatory.
|
| I began using the standard "tutorial" style and started cringing
| when I saw the official template [1] place all CRUD operations in
| a single file (I've been doing Rails and Spring for a while
| before) and the way dependencies where managed... let's just say
| I wasn't feeling very comfortable.
|
| Then came the SQLModel problems. The author pushes it very hard
| in the FastAPI docs (which imho are terrible because when I'm
| looking for docs I want that, documentation, not a fancy
| tutorial) but as an ORM (yes I know its a layer on top of
| SQLAlchemy) it doesn't even support polymorphic models and the
| community even has contributed PRs that have gone months without
| any review (is it even maintained anymore? I honestly can't
| tell).
|
| I guess I'm the only one to blame for choosing FastAPI to build a
| big project but after having used it quite a lot (and also read
| its code because again, docs are extremely poor) I wouldn't
| recommend it for anything serious. Sure, if you want to build a
| quick CRUD then go ahead and use SQLModel and FastAPI, but keep
| in mind that its not built for complex applications (at least not
| without requiring you to write a framework on top, like I've
| unfortunately done).
|
| So yeah, a big thank you to the author of this post because I
| will migrate to Litestar as soon as I wake up tomorrow.
| rmonvfer wrote:
| edit: reading the litestar docs, it even has a built-in event
| system! I spent a couple weeks building something I could use
| with FastAPI...
| miki123211 wrote:
| TBH, the FastAPI "docs" are at
| https://github.com/polarsource/polar/tree/main/server
|
| If you want to actually figure out how to scale FastAPI for a
| large-ish app, including auth, testing and all that stuff, all
| with modern practices, "how they do it in that repo" is
| probably a good way to start with.
| ilumanty wrote:
| FastAPI used to have an emoji-ridden docs page for
| concurrency. Criticism was not handled well.
|
| This made it clear to me that something about the project is
| off.
|
| https://github.com/fastapi/fastapi/discussions/6656
| rmonvfer wrote:
| Thank you! I'm actually pretty happy with what I've built tbh
| and how far has FastAPI taken us but this repo is proof that
| you have to reinvent the wheel if you want to build something
| serious.
|
| In any case, that's a treasure trove right there!, I actually
| had no idea Polar was open source, much less that it's built
| on FastAPI!
|
| It's such a shame that the actual documentation doesn't even
| scratch the surface, I would've saved so much time if they
| just included a disclaimer along the lines of "Hey, this
| architecture we are showing here it's only valid for toy
| projects, you will need much more work to build a real
| production system" but again, I guess I'm the only one to
| blame.
| no_carrier wrote:
| > Then came the SQLModel problems. The author pushes it very
| hard in the FastAPI docs
|
| No it doesn't? The front page for FastAPI contains a pretty
| lengthy tutorial with no mention of SQLModel. The only time
| SQLModel gets a significant mention is on a page explaining
| connecting a relational DB, but it makes it clear that any DB
| at all can be used. _Something_ has to be chosen for the
| tutorial, so it makes sense the author would choose their own.
|
| If SQLModel isn't right for you then you're the only person to
| blame. I've been through that tutorial before and settled on
| plain old SQLAlchemy.
| andrewstuart wrote:
| I love Starlette but not a fan of FastAPI and do not use it.
|
| I read this article but didn't really get the sense there was
| anything sufficiently compelling to switch from Starlette.
| zokier wrote:
| I know fastapi gets the hype, but I have found plain starlette
| quite usable by itself. Sure, it doesn't have the whole kitchen
| sink, but if you just need something small and simple then it
| fits the bill. In comparison Litestar seems closer to
| fastapi/django in scope
| rick1290 wrote:
| How does this compare to Django? I see you have quite a bit of
| Django content. How would you decide to use Litestar vs Django on
| a new greenfield project?
| davepeck wrote:
| I think Litestar is _superb_ for building API backends. Love it;
| use it; only good things to say. Their Advanced Alchemy is coming
| along nicely, too.
|
| Litestar of course supports old-school server-template-rendered
| sites, too; it even has a plugin for HTMX requests and responses.
| In practice, I find that the patterns that serve API endpoints so
| well sometimes get in the way of old-school "validate form and
| redirect, or re-render with errors" endpoints. In particular,
| Litestar has no "true" form support of its own; validation is
| really intended to flag inbound schema mismatch on API calls, not
| flag multiple individual error fields. Using `@post("/route",
| exception_handlers={...})` is pretty awkward for these endpoints.
| I'd be excited to see some better tools/DX in-the-box here.
| androiddrew wrote:
| When I look at a litestar all it feels a lot more planned out and
| patterned. I wish I was better at async.
|
| I've recently converted to Golang, but I'd love to come back and
| do a litestar app in the future.
___________________________________________________________________
(page generated 2025-08-06 23:00 UTC)