pulp / pulp/pulpcore

Evaluate django-ninja as a DRF replacement

Open
#3,793 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Task
Dominant language
Python
Stars
598
Forks
168
Avg merge
1d 4h
Merged PRs (30d)
86

Description

Don't freak out or take it too seriously, emphasis on "evaluate". This is probably a pulpcore 3.40 change at the earliest and might not ultimately be realistic.

DRF is verbose and doesn't deal with situations like https://github.com/pulp/pulpcore/issues/2138 well (or some of the optimizations that Gerrod has added). The particular way it separates serializers and viewsets make some optimizations and features which we need very difficult. Additionally the inclusion of type annotations in Python has opened up a lot of new ergonomic approaches which weren't available at the time.

django-ninja is a FastAPI-style framework built on top of Django (instead of Starlette like FastAPI is). In my personal subjective opinion, it is far far nicer than DRF. It works with both async and non-async code, but is designed for async first, whereas DRF has no real roadmap for async except through an entirely new package

https://django-ninja.rest-framework.com/

The main challenges would be:

  • RBAC / access policy
  • Nested Routers (creating them is trivial, I just mean we have a ton of hacks to support this currently that need to be reevaluated)
  • Transition (is there some way to smooth it out for plugin writers?)
  • openapi docs (django-ninja has them, but they're different, need to verify everything would work)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the current DRF approach and the django-ninja documentation, then examine issue #2138 and the listed concerns around RBAC, nested routers, plugin transition, and OpenAPI docs. Done means producing an evaluation of feasibility and migration implications, not necessarily replacing DRF.

Written by the indexing model from the issue text.

Assessment

Tech stack
django, python
Domain
api, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.