I’m working on a project where I use Django with templates and Django Rest Framework to serve an API that is consumed by a frontend.
So far, the hardest part hasn’t been the business logic, but how to organize the code without it becoming messy: separating template-based views from the API, keeping apps clean, etc.
Is this a common approach in the Django world, or does it usually turn into a hack?
Is there any structure or pattern people usually follow for this?
If you’ve done something similar, did it work well in the long run?
Like most other style-related questions in Django, it’s a matter of choice and sizes.
Two things to keep in mind -
Django places very few demands on file names. Almost every file name used by Django is named by convention, and not by requirement. (The models.py is the most significant exception to that that I can think of off-hand. There are also some directory names that tend to be key, such as templates in an app. These all can be overridden, but require more work.) What that means is that there’s no requirement that your views reside in a file named views.py, or that your forms be in files named forms.py, etc. Now, I don’t recommend arbitrarily going against those conventions - it’s very helpful to know where to look for things. But, if you have a reason to do so, make whatever changes are helpful for you.
I have found it a lot easier over time to refactor and relocate Python (and Django) code than in other languages and frameworks I’ve used in the past. This means you can start out with a simple and straight-forward organization, and alter it over time as the system evolves. Do not think that you have “one chance” to get it right and you must get it right now.
Being flexible has been the most advantageous approach for me. Start simple and evolve. Don’t worry about addressing issues you haven’t encountered yet.
Yes, I’m really exploring Django’s flexibility.
So far, I’ve adopted a structure where I have a dedicated “api” app that centralizes all routes for different API versions, as well as a proper place for things that are specific to DRF and API-related concerns.
Each app also has its own /api folder, where API views, viewsets, etc. live, and a /web folder for everything related to regular Django views, templaKKL.
In /core (where settings.py lives), I follow the same convention by separating /web and /api, which helps keep API routes and “normal” routes well organized.
So far, this approach has been working really well.
I do think this solution is somewhat redundant, though, so I’m still making adjustments.
So far, it has been working really well.
That is one thing I would never do. I’m strongly in the “One app until more is necessary”. A separate app (or even directory) is not required for segregating URLs.
Again, my opinion is to keep it as simple as possible when you’re starting out. Don’t try to “over-organize” things until you need to. Don’t create unnecessary structures that just create a larger mental model for what you need to track.
You can always separate things out later, after you’ve seen where that’s needed. Odds are, you’re not going to see what the ideal organization is until you’re well into your project.
Ken,
I really like this “one app until more is necessary” philosophy. Even though I didn’t follow it at first in this case, it’s my first time dealing with an API inside an already existing vanilla Django codebase.
After your reply, one of my tasks today became thinking through how to remove the API app and better organize the routes, because I realized it really wasn’t necessary in the first place.