21–30 of 35 posts
Nice to have a simpler option than DRF which has grown into a quite complicated mound of code.
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.
> Benchmark: 750 requests per second.
Think we're gonna need a couple of zeroes on that number to throw around words like "very high performance".
This has an explanation of the motivation for this project: 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…
> 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]. --- [1] https://docs.djangoproject.com/en/4.0/topics/async/ : We’re still working on async…
1. https://github.com/collerek/ormar 2. https://github.com/tophat/ormar-postgres-extensions/
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…
Yes but it doesn't have auto generated documentation, API testing UI, standardize output format, non-cookie auth, pagination, throttling...
Never saw the need for API testing if I am the user of the API.
It does indeed have a standardized format.
Non-cookie auth is actually handled in some of my projects with about a dozen lines of a header parser that then passes it to Django sessions.
Pagination in my latest project is handled as date filters or done client side. Way faster for the user that way and removes a lot of PITA.
Throttling is handled by other bits of infrastructure. If you do that inside a Django view or middleware you are likely doing it wrong.
Nice to have a simpler option than DRF which has grown into a quite complicated mound of code.
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.
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…
Earlier quoted context omitted.
But is DRFs complexity worth it compared to Ninja?
DRF isn't necessarily complex, you can still use its generic views.
Earlier quoted context omitted.
If your needs are simple enough, built-in Django function-based views will do. When you outgrow those, DRF's complexity is often warranted.
> 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…
Earlier quoted context omitted.
But is DRFs complexity worth it compared to Ninja?
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).