# Seeking feedback on improving Django REST Framework initial project setup **URL:** \ **Category:** Packages\ **Created:** [January 23, 2026, 12:13am UTC](https://forum.djangoproject.com/t/seeking-feedback-on-improving-django-rest-framework-initial-project-setup/44006 "2026-01-23T00:13:42Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![irshadirshu0722](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/irshadirshu0722/32/31216_2.png) [@irshadirshu0722](https://forum.djangoproject.com/u/irshadirshu0722)\ **Post date:** [January 23, 2026, 12:13am UTC](https://forum.djangoproject.com/t/seeking-feedback-on-improving-django-rest-framework-initial-project-setup/44006/1 "2026-01-23T00:13:42Z")
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. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [January 23, 2026, 1:44am UTC](https://forum.djangoproject.com/t/seeking-feedback-on-improving-django-rest-framework-initial-project-setup/44006/2 "2026-01-23T01:44:57Z")
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. > [@irshadirshu0722](#): > > - some optional tooling or helper outside of core, > - or a small opt-in helper/command provided separately? I’m interested in hearing more details on these ideas! It’s not clear to me what exactly is being proposed. ---
**Author:** ![irshadirshu0722](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/irshadirshu0722/32/31216_2.png) [@irshadirshu0722](https://forum.djangoproject.com/u/irshadirshu0722)\ **Post date:** [January 24, 2026, 1:23am UTC](https://forum.djangoproject.com/t/seeking-feedback-on-improving-django-rest-framework-initial-project-setup/44006/3 "2026-01-24T01:23:24Z")
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: ```auto 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. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [January 24, 2026, 1:25pm UTC](https://forum.djangoproject.com/t/seeking-feedback-on-improving-django-rest-framework-initial-project-setup/44006/4 "2026-01-24T13:25:48Z")
Ah gotcha. Have you looked into creating a [cookiecutter](https://www.cookiecutter.io/) 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](https://github.com/agconti/cookiecutter-django-rest) ---
**Author:** ![browniebroke](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/browniebroke/32/2506_2.png) [@browniebroke](https://forum.djangoproject.com/u/browniebroke)\ **Post date:** [January 24, 2026, 3:06pm UTC](https://forum.djangoproject.com/t/seeking-feedback-on-improving-django-rest-framework-initial-project-setup/44006/5 "2026-01-24T15:06:51Z")
Hey, I maintain both DRF and [cookiecutter-django](https://github.com/cookiecutter/cookiecutter-django) 😃 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](https://github.com/cookiecutter/cookiecutter-django/pull/6088). > [@CodenameTim](#): > > 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](https://github.com/agconti/cookiecutter-django-rest) 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](https://copier.readthedocs.io/en/stable/) is also worth a mention as an alternative to cookiecutter. It’s less popular because it’s newer, but it supports updating generated projects. ---
**Author:** ![irshadirshu0722](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/irshadirshu0722/32/31216_2.png) [@irshadirshu0722](https://forum.djangoproject.com/u/irshadirshu0722)\ **Post date:** [January 26, 2026, 7:20pm UTC](https://forum.djangoproject.com/t/seeking-feedback-on-improving-django-rest-framework-initial-project-setup/44006/6 "2026-01-26T19:20:00Z")
Thank you for the wonderful feedback. Oh, I just explored [cookiecutter-django](https://github.com/cookiecutter/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!