Live data from Hacker News

Litestar is worth a look

b-list.org

51–60 of 86 posts

Re: Litestar is worth a look

#51
Connexion is also worth a look IMO. It uses spec-first development (a major benefit in larger orgs and for public APIs), and can plug into different server frameworks.

(I used to be a maintainer, but it has been years since I worked on it).

Re: Litestar is worth a look

#52
> 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 would use it.

Re: Litestar is worth a look

#54

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.

Me too! Switched from FastAPI on a new project and never looked back. I really like how complete Litestar feels and the base will get you quite far and very reliably.

Re: Litestar is worth a look

#55

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…

I haven’t ever used Litestar, but it seems like it would be possible to write your own decorator `@postform` that handles all of form-related stuff.

Re: Litestar is worth a look

#56
When will people understand that those very opinionated frameworks with enticing tutorials just ruin your life in the long term?

I see someone citing Spring(yikes) elsewhere, that falls in the same category as FastAPI. You don't need Spring most of the times, a simple dependency injection library and small frameworks to handle the web routing or specific features you need are often enough (recent contenders to the throne of default app framework have the same issues).

Re: Litestar is worth a look

#57

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…

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.

Iam-abbas has a good FastAPI boilerplate

Re: Litestar is worth a look

#58
post #10

Earlier quoted context omitted.

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.

Mind elaborating a bit on why you migrated away from django ninja? Just curious, I’ve been using it for some small side projects and have enjoyed it.

Djangi-ninja is excellent, but it's still Django and when you aren't using a lot of the "batteries included" then you're not really using Django. I mentioned SQLAlchemy which is already "fighting Django" compared to using Django Orm as an example. We picked Litestar because it's natively async, makes it easy to use dataclasses rather than Pydantic, has really fast cold start and it has great interoperability with Advanced Alchemy.

I think Django is great, and by extension that Django-Ninja is too. Considering it runs Instagram it certainly scales as well, but unlike Instagram we aren't enough engineers to be able of ripping out more and more batteries while replacing them with our own specialized batteries.

Re: Litestar is worth a look

#59

Earlier quoted context omitted.

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.

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’v…

> you have to reinvent the wheel if you want to build something serious [...] guess I’m the only one to blame.

The main benefit from micro frameworks like FastAPI/Flask/Express.js is that you must build your own framework! You can pick the building blocks that will make your life easier, instead of relying on choices that made the maintainer life in full-fledged frameworks like Django/Laravel/RoR bearable. Of course, you'd need to be comfortable building frameworks and doing that work additionally to the domain modeling - pick the right tool for the job and all.

Re: Litestar is worth a look

#60

Earlier quoted context omitted.

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.

Iam-abbas has a good FastAPI boilerplate

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
          ├── tasks.py
          └── users.py
A structure around mini apps always turns out to be more beneficial for keeping boundaries intact in the long run:

  apps
  ├── tasks
  │   ├── controller.py
  │   ├── models.py
  │   ├── repository.py
  │   ├── schemas.py
  │   └── service.py
  └── users
      ├── controller.py
      ├── models.py
      ├── repository.py
      ├── schemas.py
      └── service.py
[0]: https://github.com/iam-abbas/FastAPI-Production-Boilerplate
Post reply on HN