The main purpose of this post is to motivate why to choose Starlite over the most popular API framework in Python – FastAPI:
Real world demands force Na’am Hirschfield to drop FastAPI
In this article Na’am describes why he had to drop FastAPI and start using Starlite. There were this comments in the reddit thread on his article.
FastAPI dependency injection is severely lacking
Na’am has found the way dependency injection has been implemented – as a default value to a function argument, to be quite bad. It (a) leads to an inflation in args. (b) it doesn’t support named dependencies from outside the argument. (c) it requires a lot of redeclaration.
Now, this is really a personal view, but to me the decision to use functions, done in Starlette, really isn’t very good. Python is a great OOP language, and this just misses the point of it. I come from Django and DRF – class based views are great.
Starlite has Class-based controllers. FastAPI does not.
FastAPI facilitates a “top down” architecture, which can become quite messy. You always need to add routes directly to the app or a router (which you then need to add to the app). With class based controllers, you are completely free to decide where and when you define your routes. This way, the routing logic doesn’t need to be concerned with any top level object.
Another benefit of the layered architecture is that you can easily define dependencies and various parameters on each layer, and have fine grained control over possible override behaviour. Since in FastAPI, everything gets merged into one router in the end (“including” routers does nothing more than re-reacting and adding all routes of that router to the top-level router), this distinction gets lost at that level, and therefore doesn’t allow for such control.
Starlite is considerably Faster?
What explains the drastic difference in serialization performance?
use msgspec for serialization. This is way faster than the stdlib’s json module. The most significant difference you’re seeing is dataclasses. The reason there is that msgspec natively supports dataclasses, while the json module does not.
Adding to that, FastAPI has some (known) memory issues, which leads to it dropping requests when serializing larger/more objects concurrently.
Especially surprising since the pydantic integration is one of fastapi’s main selling points.
The thing with Pydantic is, that it’s really slow. A good demonstration of that is when comparing the graphs for dataclasses vs. Pydantic serialization. It is expected to be more performant in Pydantic 2.0, since they moved a lot of the core logic to rust, but it will still be quite slow compared to other method, simply because of what it does.
We are currently in the process of evaluating what of our internal parsing and validation logic we can move away from Pydantic and to msgspec, for performance reasons.
msgspec’s idea of combining the parsing/validation and (de)serialization step is genius. This is not only great for performance, but also results in cleaner code in many cases!
Parsing of form data and query parameters
One key difference between Starlite and Starlette/FastAPI is in parsing of form data and query parameters- Starlite supports mixed form data and has faster and better query parameter parsing.
FastAPI has one developer who ignores pull requests that fix issues
Starlite has Rigorous typing
Starlite is rigorously typed, and it enforces typing.
Completed Starlite Applications
- Paaster – https://github.com/WardPearce/paaster
- User Showcase: Telemetry Sports x Starlite
Django REST Framework? If you want to fly second class, go ahead
DRF is not async , Starlite is Async .DRF get in the way of developer , it needs to develop in its own way.Starlite can write the way you code normally (with focused on type annotations) and will bring you full swagger/redoc based OpenAPI schema .DRF do not come with OpenAPI viewer like Swagger or Redoc by default.
DRF Generates forms automatically IF you follow their pattern (Viewsets , Models , Seralizers APIViews ) But when it needs to do things to customize you need to fight with the framework. It geerates APiForm views for CRUD which I Found weird and limited. You need extra plugins for Swagger.While Starlite do not comes with such generations currently , You can plug in any of your favourite (preferally async ) ORM frameworks . Starlite by default comes with SQLALchemy Plugin , TortoiseORM plugin , Picollo ORM plugin.
in upcoming 2.0 + Repository+Service pattern based Contrib , controllers that can do CRUD capability easily will be available too.
0xPark