[HN Gopher] Django Ninja - Fast Django REST Framework for Buildi...
___________________________________________________________________
Django Ninja - Fast Django REST Framework for Building APIs
Author : watchdogtimer
Score : 101 points
Date : 2022-02-05 13:58 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nesarkvechnep wrote:
| Unfortunately, it doesn't enforce usage of hypertext.
| dplgk wrote:
| Nice to have a simpler option than DRF which has grown into a
| quite complicated mound of code.
| Nextgrid wrote:
| 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 wrote:
| But is DRFs complexity worth it compared to Ninja?
| leowoo91 wrote:
| DRF isn't necessarily complex, you can still use its
| generic views.
| dangerbird2 wrote:
| 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).
| zmmmmm wrote:
| > 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.
| mythrwy wrote:
| 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 wrote:
| 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.
| samwillis wrote:
| 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 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 wrote:
| > 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 support for the ORM_
|
| [2] https://fastapi.tiangolo.com/advanced/async-sql-databases/
|
| [3]
| https://docs.sqlalchemy.org/en/14/orm/extensions/asyncio.htm...
| etimberg wrote:
| A good Django like ORM for FastAPI is Ormar [1]. I've got PG
| specific extensions to Ormar in [2].
|
| 1. https://github.com/collerek/ormar 2.
| https://github.com/tophat/ormar-postgres-extensions/
| cmclaughlin wrote:
| The author of FastApi wrote an ORM too:
|
| https://github.com/tiangolo/sqlmodel
|
| I have not yet used it, but I think that's the best approach
| now
| codingkev wrote:
| 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.
| zeppelin101 wrote:
| 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.
| samwillis wrote:
| There was a recent discussion about it here including a
| reply from the FastAPI creator explaining the situation:
|
| https://news.ycombinator.com/item?id=29471609
| samwillis wrote:
| 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 wrote:
| 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!
| samwillis wrote:
| Very true, and I have been following this pull request
| implementing Async Queryset with interest:
|
| https://github.com/django/django/pull/14843
|
| 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.
| fredrikholm wrote:
| > 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".
| IgorPartola wrote:
| 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 wrote:
| Yes but it doesn't have auto generated documentation, API
| testing UI, standardize output format, non-cookie auth,
| pagination, throttling...
___________________________________________________________________
(page generated 2022-02-05 23:00 UTC)