5 ms·

Django Ninja – Fast Django REST Framework for Building APIs

169 points by watchdogtimer 5y ago

bluewalt 5y ago
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).
dplgk 5y ago
Nice to have a simpler option than DRF which has grown into a quite complicated mound of code.
- Nextgrid 5y ago
  If your needs are simple enough, built-in Django function-based views will do. When you outgrow those, DRF's complexity is often warranted.
  - throwaway_4ever 5y ago
    But is DRFs complexity worth it compared to Ninja?
    - dangerbird2 5y ago
      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).
      - Nextgrid 5y ago
        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).
    - leowoo91 5y ago
      DRF isn't necessarily complex, you can still use its generic views.
      - Nextgrid 5y ago
        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.
  - zmmmmm 5y ago
    > 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.
    - Nextgrid 5y ago
      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.
- mythrwy 5y ago
  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.
- holler 5y ago
  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.
  - paiute 5y ago
    starlette is amazing. Django just gets in the way.
- Xavdidtheshadow 5y ago
  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.
samwillis 5y ago
This has an explanation of the motivation for this project: https://django-ninja.rest-framework.com/motivation/ 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)
- vladvasiliu 5y ago
  > 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/ https://docs.djangoproject.com/en/4.0/topics/async/: We’re still working on async support for the ORM [2] https://fastapi.tiangolo.com/advanced/async-sql-databases/ https://fastapi.tiangolo.com/advanced/async-sql-databases/ [3] https://docs.sqlalchemy.org/en/14/orm/extensions/asyncio.html https://docs.sqlalchemy.org/en/14/orm/extensions/asyncio.htm...
  - samwillis 5y ago
    No, sorry, did have it right but wasn't clear in my sentence: 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) Will edit to make clear.
    - bryanh 5y ago
      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!
IgorPartola 5y ago
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.
- BiteCode_dev 5y ago
  Yes but it doesn't have auto generated documentation, API testing UI, standardize output format, non-cookie auth, pagination, throttling...
  - IgorPartola 5y ago
    If I am writing the client and server code, the server code is quicker to check than documentation. 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.
- pphysch 5y ago
  Do you have a public repo with examples of this in action?
nesarkvechnep 5y ago
Unfortunately, it doesn't enforce usage of hypertext.
fredrikholm 5y ago
> FAST execution: Very high performance thanks to Pydantic and async support. > 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".
- vital1k 5y ago
  @fredrikholm this is pure CPU-heavy single core synthetic test - this is just to give an idea how it compares the speed to flask/drf on the same environment
frays 5y ago
Will check this out. Thanks for sharing.
todotask 5y ago
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)?

169 points by watchdogtimer 5y ago

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

dplgk 5y ago

Nice to have a simpler option than DRF which has grown into a quite complicated mound of code.

Nextgrid 5y ago
If your needs are simple enough, built-in Django function-based views will do. When you outgrow those, DRF's complexity is often warranted.
- throwaway_4ever 5y ago
  But is DRFs complexity worth it compared to Ninja?
  - dangerbird2 5y ago
    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).
    - Nextgrid 5y ago
      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).
  - leowoo91 5y ago
    DRF isn't necessarily complex, you can still use its generic views.
    - Nextgrid 5y ago
      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.
- zmmmmm 5y ago
  > 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.
  - Nextgrid 5y ago
    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.
mythrwy 5y ago
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.
holler 5y ago
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.
- paiute 5y ago
  starlette is amazing. Django just gets in the way.
Xavdidtheshadow 5y ago
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.

samwillis 5y ago

This has an explanation of the motivation for this project: https://django-ninja.rest-framework.com/motivation/ 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)

vladvasiliu 5y ago
> 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/ https://docs.djangoproject.com/en/4.0/topics/async/: We’re still working on async support for the ORM [2] https://fastapi.tiangolo.com/advanced/async-sql-databases/ https://fastapi.tiangolo.com/advanced/async-sql-databases/ [3] https://docs.sqlalchemy.org/en/14/orm/extensions/asyncio.html https://docs.sqlalchemy.org/en/14/orm/extensions/asyncio.htm...
- samwillis 5y ago
  No, sorry, did have it right but wasn't clear in my sentence: 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) Will edit to make clear.
  - bryanh 5y ago
    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!

IgorPartola 5y ago

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.

BiteCode_dev 5y ago
Yes but it doesn't have auto generated documentation, API testing UI, standardize output format, non-cookie auth, pagination, throttling...
- IgorPartola 5y ago
  If I am writing the client and server code, the server code is quicker to check than documentation. 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.
pphysch 5y ago
Do you have a public repo with examples of this in action?

nesarkvechnep 5y ago

Unfortunately, it doesn't enforce usage of hypertext.

fredrikholm 5y ago

> FAST execution: Very high performance thanks to Pydantic and async support. > 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".

vital1k 5y ago
@fredrikholm this is pure CPU-heavy single core synthetic test - this is just to give an idea how it compares the speed to flask/drf on the same environment

frays 5y ago

Will check this out. Thanks for sharing.

todotask 5y ago

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)?