I’m building my first Django project and would like to make sure I’m getting the structure right before I get stuck in. Currently I have three app directories. One is the ‘parent’ app or whatever you’d call it, which has my app settings and manages the ‘root’ urls for the other apps, another is an app for a CRUD webpage (I’ve made these two as per the tutorial, which has the ‘parent’ mysite and then a polls application). The third one is the one I’m not sure about, which is a DRF api app.
I’m currently serving all my data to the CRUD app by referencing the serializers and models in the api app. I like the api app being separate, as it has its own url path ‘api’ which I can use for requests in my other non-django projects, which I prefer from a style point of view. This means that I’m essentially building two sets of views, one set in the api app for requests external to this project, and one set in the CRUD app to render the serialized data in HTML. This leaves me with a CRUD app that has no models or migrations of its own, which I don’t see an issue with, but seems a little unusual maybe? Is this setup fairly standard, or am I not using Django ‘as intended’ and there unforeseen issues that I could run into here?
<opinion>
I’m a member of the “One app until proven otherwise” camp. My criteria for dividing a project into separate apps primarily revolve around the question of whether or not some functionality will be reusable across different projects. (I’ve written about this in a number of places here - see Structuring external service integrations in Django as one example, there are others you could find.) </opinion>
It is not necessary to separate code into separate apps solely to provide URL organization. You can create the same URL structure within a single app as you do in a multiple-app project.
There’s nothing wrong with creating an app that doesn’t have any models of its own - there are many third-party apps that do exactly that. (DRF, Channels and Crispy Forms are three that come to mind right off-hand.)
Django is very flexible in that regard. Also, Django puts very few requirements on file names. (For example, your settings file does not need to be named “settings.py” and your urls do not need to be in files named “urls.py”.)
Likewise, there’s no requirement that your views be stored in a file named “views”. You can easily have some views in a file named “views.py”, and other views in a file named “api.py”.
So there are a lot of thing you can do to organize your code that don’t require you to go so far as to create separate apps to do it.