[Python] Making Headless Website backend in Django, files are becoming lengthy and unreadable,...

I am working on a headless website project, where I am implementing the backend through django using django-rest-frameworks, till now I was using this structure

my_project/
├── manage.py
├── my_project/
│ ├── __init__.py
│ ├── asgi.py
│ ├─ settings.py
│ ├─ urls.py
│ ├── wsgi.py
├── auth/
├── migrations/
│ └── __init__.py
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── tests.py
├── urls.py
├── signals.py
├── serializers.py
├── utils.py
└── views.py


But the problem I felt here is, after having so many APIView classes for login, registration, authentications, Googleauth etc.. the views.py file is getting lengthy and unreadable.

So I am thinking to switch to this architecture (inspired from react js, where we can have all html, tailwind and js inside one component.jsx).

my_project/
├── manage.py
├── my_project/
│ ├── __init__.py
│ ├── asgi.py
│ ├─ settings.py
│ ├─ urls.py
│ ├── wsgi.py
├── auth/
├── migrations/
│ └── __init__.py
├── api/
│ └── views/
├── __init__.py
│ ├── login.py
│ └── register.py
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── tests.py
└── urls.py


Where for login API functionality, I will have login.py, and inside it I will store:

• Its serializer class for verifications.
• Its util class for extra functions.
• Its Authentication class for making jwt access and refresh tokens.
• and its APIView class.

and similarly in register.py, I will have separate serializers, utils and api view in same file.

This way, I can have all required functionalities of one feature in one file (or even if it gets larger, then I can divide it again in a package itself), so that in future if some feature gives error, then I only have to read that feature's file, instead of searching its utils and serializers in different files

Will this be Okay to implement this structure? And if no, then can anyone provide me an approach that can solve this problem (and accepted by django community)?

Thanks

Continue reading...