6đź‘Ť
Usually, for projects that are going to be used by only one installation, I usually name my projects as “who will be using the system” (e.g. the organization’s name) and the apps as “major features of the system”.
However, if your app is really that simple that you don’t expect to be using multiple apps, then django might be too heavyweight and you might actually be better served by using something simpler.
1đź‘Ť
I’m very new to Django, but in what I’ve read of the documentation I haven’t found any naming conventions for projects as they depend on too many factors. Instead, use general names for projects and more specific names for apps:
project = humanresource
apps = salaries, badge, whatelse...
Remember that projects come first, and apps can be reused in different projects.
- What is the difference between the create and perform_create methods in Django rest-auth
- How to use select_related with GenericForeignKey in django?
- Django annotate specific keys in json fields
-1đź‘Ť
With django, you need a project – that is what holds the settings, urls modules. And a project needs a minimum of one app.
Most projects consist of a lot of apps. Organization is necessary and this is the preferred method. However, if it is a very simple app, for which you think all of this boilerplate is overkill and like to keep it in a single file, you can do so using some of the other micro frameworks like Flask.
- Django + Pydev/Eclipse + Google App Engine – possible?
- How to write unit tests for django-rest-framework api's?