It sounds super interesting, it fits the middle ground between Django Rest Framework and FastAPI taking the best of both. Full support for Django and particularly it’s ORM (hard to do with FastAPI as the Django ORM is not yet async and can’t be used with FastAPI)
I like that it supports both sync and async as I’m personally not convinced about the use of async Python everywhere. I could see this being brilliant for an api where the majority is simple sync code but with a few endpoint with long running responses or where you need multiple concurrent requests to DBS or other APIs.
> Full support for Django and particularly it’s ORM (hard to do with FastAPI as the ORM is not yet async)
I think you may have it backwards. Django's ORM isn't async yet [1], whereas FastAPI doesn't actually have an "included" ORM. However, the docs give an example of an async ORM [2], and SQLAlchemy also has async support [3].
This isn’t exactly true. The Django ORM can be used with care in the async views found in FastAPI and Django (see sync_to_async and run_in_threadpool helpers).
Plans exist to make the Django Queryset async, so it’ll be exciting when that day comes!
So far they are only going down the the queryset level, it then uses a thread pool for the db connector, next job would be to support async db connections.
Whats the deal with they large number of open issues an pull requests on FastAPI and SQLModel?
SQLModel 100 issues, 54 open PRs
FastAPI 903 issues, 448(!!) open PRs
I recently had to choose between Flask and FastAPI for a fresh project and went with Flask in the end, partly due to long term maintenance concerns with FastAPI.
Having given SqlModel a very proper go a few months back, I have to say that it's not worth using it just yet. There are too many outstanding issues and the documentation is also incomplete. Maybe in a year's time, the situation could be different.
The approach for this I have taken lately is this:
1. A custom made serializer. This is the most complicated 150 lines of code in that it can traverse Django ORM objects/query sets and output them to JSON. It supports explicit included and excluded fields and included relationships which it automatically prefetches.
2. Custom middleware that parses any application/json request bodies in request.data.
3. I use Django forms on any data going from client to server for validation. Works great, no reason to make this complicated.
That’s it. Now I can have a REST API written as normal Django views. It is significantly more performant Thant DRF since it doesn’t need to check for a whole lot of different complicated field types when serializing. It’s easy to understand (just call serialize(users, excluded_fields=[“password”], relationships=[“books.chapters”]) to return JSON to the client; you can also annotate your models to include/exclude fields and relationships by default). It has validation errors built in via Django forms. It just works.
Unfortunately no, but I will see if I can at some point open it up. It’s used at $DAYJOB though the original inspiration came from a personal project so I need to untangle that.
Frankly it’s not hard to do: you need a parser for author.books.chapters, then a bit of code to look up fields from a model’s Meta class, and then a recursive function to traverse model instances and include the correct field/value pairs based on the type that each field is (scalar, iterable, dict, model instance). My latest version includes a couple of niceties like the annotation on the models of fields to always include/exclude, support for custom properties, and caching of the above. The output is a dict or a list of dicts that can be serialized by Django’s JSON serializer.
Django actually sort of includes a version of this already for serializing model instances, it’s just not very robust.
On my latest project I went with Starlette (same author DRF/core dep for FastAPI) on it's own using marshmallow for serialization.
Having written years worth of django/drf in the past, it's a breathe of fresh air with minimal dependencies, simple constructs, and good documentation. Def recommend.
> If your needs are simple enough, built-in Django function-based views will do
This is the bit I find not really true.
My needs are simple (10-20 basic get/post/put/delete APIs, many at the business logic layer than true REST) but I still would really like the OpenAPI docs, auto-generated schema definitions, etc etc. If I can get that with just some simple decorators on my existing views and pydantic models for the inputs and outputs .... that would be awesome.
That's something you can get with DRF pretty much out of the box as long as you use its routers, viewsets and serializers. DRF serializers are different than just Python type-hints, but not more complex - it's just different syntax.
DRF was about as good as it got for automatic schema generation and data validation before python static type hints made things like pydantic possible. It also sets up good defaults for stuff like query parameter-based filtering, pagination, and resource relationships (it supports HATOAS by default).
I'd argue that Python type hints are actually a step back. Sure, they may work 80% of the time, but there are times where you need the extra flexibility offered by DRF serializers. Those can go way farther than the basic "map these JSON data types to this Python representation" which would then be difficult to represent using basic Pydantic-style hints (you'd have to the rest in procedural Python within your endpoint, which can't easily be reused when it comes to function-based views, where as DRF abstracts that away within the serializer which not only can be reused, but itself can be composed of multiple classes/mixins).
My argument about the "complexity" of DRF is that you need to use its serializers (frankly if you're just returning raw dicts then you're already not far off from built-in, generic Django function-based views) which I guess some people may consider complex especially if the data you're representing doesn't originate from models.
I like DRF, especially when I have to come back after some time or get in a new project and looking for where things happen. But ya, boilerplate city. It really feels wrong typing out the serializers, the views, repeating the same steps over and over. It's too much.
I'm excited to try this out, been looking at FastAPI.
I like the idea of DRF, but when I only dive into it occasionally, I find it has much too much magic for my liking. "Just defined this class w/ this property and then it `just works`!" is really hard to follow if you're not familiar with it.
This project is very clever, because as a Django developer, when I tried to use. FastAPI, I didn't get the faith to learn another ORM.
I've been using django ninja for months and I can say that it's a very good replacement to DRF. It's way simpler to use and less bloated, thanks to pydantic.
However I would not use it for important projects in production, because of a lack of support and documentation, and the fact that it relies almost entirely on a single developer (like many other projects, right).
When I read the tutorial and run on uvicorn with my lack of experience in Python language, it's significantly slow (3,000+ rps using this framework manage.py vs <500 rps on uvicorn)?
https://django-ninja.rest-framework.com/motivation/
It sounds super interesting, it fits the middle ground between Django Rest Framework and FastAPI taking the best of both. Full support for Django and particularly it’s ORM (hard to do with FastAPI as the Django ORM is not yet async and can’t be used with FastAPI)
I like that it supports both sync and async as I’m personally not convinced about the use of async Python everywhere. I could see this being brilliant for an api where the majority is simple sync code but with a few endpoint with long running responses or where you need multiple concurrent requests to DBS or other APIs.
(Edited for clarity, thanks vladvasiliu)