Seeking feedback on improving Django REST Framework initial project setup

Packages
1

Hi everyone,

I have been working with Django for some time now and built quite a few projects
using Django REST Framework.

One thing I keep noticing when starting a new DRF project is that I usually repeat
the same REST_FRAMEWORK settings again and again in settings.py (authentication,
permissions, renderers, pagination, etc.).

I do understand that Django and DRF prefers explicit configuration and tries to avoid
any kind of magic, so I’m not really suggesting changing any defaults in the core.

Before trying to work on anything, I just wanted to ask for some opinions from the
community and maintainers.

Do you think there is any scope to improve the initial DRF setup experience in some
non-intrusive way, like:

  • some optional tooling or helper outside of core,
  • or a small opt-in helper/command provided separately?

Before making this request . I spent small time on asking about this feeature or option in DRF with my dev groups then i got positive response from it . That actually led to ask this question in this forum

I just want to understand what direction would align better with Django/DRF philosophy,
or if this repetition is intentionally left to each project.

Thanks a lot for your time and guidance.

1 Like
2

Hey, I think this is a fine place to get feedback from the broader community, but DRF maintainers may prefer to discuss this in an issue on the repo.

I’m interested in hearing more details on these ideas! It’s not clear to me what exactly is being proposed.

3

Hi, thanks for the reply and for being open to hearing more details.

Let me try to explain the idea a bit better, maybe with a more practical example.

I’m not thinking about changing anything inside DRF core or its defaults. I understand and actually like the idea that Django/DRF prefers explicit configuration and avoids magic.

This is more about an optional, opt-in helper or tool, probably outside core, that helps with the initial setup phase when starting a new DRF project.

From my experience, when I start a new project, I almost always repeat the same things:

  • adding REST_FRAMEWORK settings (auth, permissions, pagination, renderers, etc.)

  • deciding between JWT or session auth

  • creating apps and then manually adding the same basic files (views.py, serializers.py, urls.py, etc.)

  • wiring everything together before I can actually start working on features

After doing this many times, it feels like something that could be automated without hiding anything.

What I had in mind is something command-line based, a bit similar in spirit to create-next-app, but much simpler and very explicit.

For example, running something like:

django-admin drf-init

And then it just asks a few questions, like:

  • app names (comma separated, e.g. accounts, products)

  • authentication type (JWT or session)

  • default permission class

  • pagination (yes/no, page size)

  • and more options if we need

Based on that, it would:

  • create the apps with basic DRF-ready files

  • add the selected REST_FRAMEWORK settings into settings.py

  • only generate what the user explicitly chose

So there’s no magic defaults — it just saves time on boilerplate that many of us already write manually.

I’m not fixed on how or where this should live. It could be:

  • a small external package

  • or some kind of officially suggested helper, but still separate from core

Mainly I wanted to understand if this kind of tooling fits the Django/DRF philosophy, or if this repetition is intentionally left fully to each project.

Happy to hear thoughts or suggestions, and thanks again for taking the time to respond.

4

Ah gotcha. Have you looked into creating a cookiecutter template? I pulled the first one that mentioned DRF so you could see how that gets set up: GitHub - agconti/cookiecutter-django-rest: Build best practiced apis fast with Python3

5

Hey, I maintain both DRF and cookiecutter-django :smiley:

If you have suggestion on better defaults for DRF, I would suggest opening a discussion on the repo. At this point in the project lifespan, it’s unlikely to be changed, but who knows…

The cookiecutter-django DRF integration might or might not be what you’re after, and was added fairly late in the project. The rendering of most pages is still done via Django template, and the APIs are there “on the side” but not really used by default. It also provides a lot of options so you might find it bloated for your needs. There is also a piece to add django-ninja as an option.

At first glance, this feels more like a DRF-first project template, where the Django project is primarily used as API (no template-rendered views).

Finally, if you want to go down the route of creating your own project template, Copier is also worth a mention as an alternative to cookiecutter. It’s less popular because it’s newer, but it supports updating generated projects.

1 Like
6

Thank you for the wonderful feedback.

Oh, I just explored cookiecutter-django. It impressed me with the default setup. Anyway, let me explore it more in detail. If I find anything to add, I will definitely try to contribute!

1 Like