Live data from Hacker News

Litestar is worth a look

b-list.org

71–80 of 86 posts

Re: Litestar is worth a look

#71
post #66

Earlier quoted context omitted.

If you're referring to this[0] GitHub project I'd highly disagree. I will never understand the minds of people that structure their apps like this: app ├── controllers │ ├── task.py │ └── user.py ├── models │ ├── task.py │ └── user.py ├── repositories │ ├── task.py │ └── user.py └── schemas ├── extras │ ├── current_user.py │ ├── health.py │ └── token.py ├── requests │ ├── tasks.py │ └── users.py └── responses ├── tas…

The fancy word for that is Vertical Slice Architecture btw and it's the only way for complex apps that doesn't end in chaos.

Bogard's example for a poor fit for VSA, in the famous blogpost, was specifically controllers.

> Sometimes these are still required by our tools (like controllers or ORM units-of-work) but we keep our cross-slice logic sharing to a minimum.

That's exactly where you shouldn't be using it! Relying on it as dogma will result in chaos.

Re: Litestar is worth a look

#72

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?

Litestar looks promising because it has most of the features a Django developer would but in a more modern package. However, since it has so many features, I hope that the project doesn't get abandoned like so many frameworks these days because unlike tiny frameworks, it would be harder to migrate off of.

Re: Litestar is worth a look

#73

Earlier quoted context omitted.

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...

Looking at the docs and trying to figure out what this is for. Is it essentially when you want to break out of the "request lifecycle" and queue something to run after your response has already been returned? It strikes me that I haven't used web frameworks a lot and never even questioned how that may not be an easy thing to do!

They seem to fill the same purpose as django's signals.

Re: Litestar is worth a look

#74

> So if you’re going to be writing a database-backed web application in Python, and you’re not doing Django, you are almost certainly going to be using SQLAlchemy. I've preferred the Django ORM over SQLAlchemy, but I'm curious what others feel. I've gone so far as to use Django ORM for non-web projects as well. It takes a bit of work to extract though. If Django ORM had a better stand-alone story, I think more people…

SQLAlchemy is just a totally different beast to Django, it has a much higher learning curve but gives you so much more power and flexibility. It's a true data mapper ORM rather than the sad Active Record pattern which starts off well and quickly gets annoying.

I'm curious about your experience, I like SQLAlchemy granularity and expressiveness, but after a while I found django fits the "good enough" niche very well, it's quick and not too dirty (the name wrangling for joins is funky but it's ok). What kind of queries or logic did SQLAlchemy allowed you to write that Django would make hell to reach ?

Re: Litestar is worth a look

#75
post #64

Earlier quoted context omitted.

I've been using the Django ORM for 20 years, and it has yet to get annoying. What's your definition of "quickly" — perhaps 25 years?

Obviously it will depend on what you're doing and one's tolerance for things many deem to be annoying. I've encountered people with incredibly high tolerance for slow and awkward workflows but, alas, I am not one of them. If I had to call out one thing it would be that you can't do tests without having a database there. This results in incredibly slow tests for even the simplest things. I don't need to test database…

> IMO a db access layer or web framework should be completely independent of domain logic, but Django makes that really difficult.

That is an issue/features in Django, depending on your view. You really don't get to do things the framework doesn't want. If you're trying to fight the ORM or any of the components in Django really, including the Django REST framework, you're going to lose and have a bad time.

There are certainly reason why you'd want to separate domain logic from the database access, but then Django isn't what you want. You're also going to miss out many of the things that makes Django easy to work with, like getting most CRUD operations for free.

Re: Litestar is worth a look

#76
I agree that FastAPI is not the best but I would not jump to another framework just because of an article.

For FastAPI I know that I can go to [1] and see what a good FastAPI code base looks like. These days even Airflow is on FastAPI but haven't looked at the codebase.

For me to jump on Litestar, I would like to see a reference codebase to learn best practices. Otherwise its one more framework whose quirks I have to get comfortable with.

1 - https://github.com/polarsource/polar

Re: Litestar is worth a look

#77
post #42

Earlier quoted context omitted.

Is there really less documentation? FastAPI mostly has tutorials to get started and is light on deep/reference material. A single person can only do so much.

Documentation-wise I'm mainly comparing to Django, because I agree FastAPI actually quite light on reference docs too. I've actually tried using litestar before and always been keeping an eye on it, but for a full fledged website needing forms, auth, etc. I find it hard to move away from just slightly tweaking Django for my needs - but still I feel drawn to Litestar as it's in between FastAPI and Django but still muc…

For forms and auth style apps, Django will probably always be the better choice.

Re: Litestar is worth a look

#78
post #76

I agree that FastAPI is not the best but I would not jump to another framework just because of an article. For FastAPI I know that I can go to [1] and see what a good FastAPI code base looks like. These days even Airflow is on FastAPI but haven't looked at the codebase. For me to jump on Litestar, I would like to see a reference codebase to learn best practices. Otherwise its one more framework whose quirks I have to…

Ready, set... jump! There's a reference application [0]

[0] https://github.com/litestar-org/litestar-fullstack

Re: Litestar is worth a look

#79

> So if you’re going to be writing a database-backed web application in Python, and you’re not doing Django, you are almost certainly going to be using SQLAlchemy. I've preferred the Django ORM over SQLAlchemy, but I'm curious what others feel. I've gone so far as to use Django ORM for non-web projects as well. It takes a bit of work to extract though. If Django ORM had a better stand-alone story, I think more people…

> I've preferred the Django ORM over SQLAlchemy, but I'm curious what others feel.

Same here... better API IMO, just the right amount of abstraction (ActiveRecord-like has been fine for all the projects I was involved in) and plenty of escape hatches when needed.

Post reply on HN