I am new to learning Django and I know how important setting up an application directory structure can be for future additions.
At the moment, I am creating an API using the Django REST Framework and have a few questions on how to structure a Django project for future success.
I want the API to feed out possibly in the future to other outside sources that may need to grab data. I also will be building a front-end CRUD like system to display and update data.
How would you suggest structuring the directories in the future possibility of adding more front-end like systems that are all powered by the Data API? Doing some research already, it seems like these are possibilities I have seen.
project
manage.py
project
settings.py
urls.py
api
models.py
serializers.py
views.py
crudapp
files here...
project
manage.py
project
settings.py
urls.py
api
models.py
serializers.py
views.py
crudapp
files here...
project
manage.py
project
settings.py
urls.py
crudapp
api
models.py
serializers.py
views.py
files here...
futureapp
api
models.py
serializers.py
views.py
files here...
I am really trying to understand how Django and Python should have these modules setup. If I have separate modules/apps setup, they can all access the models in the API app for any sort of app I build in the future?
Any clarification or experience on this would be greatly appreciated. The main goal is to have an API for the data in the database, and to then be able to build a front-end CRUD to update and pull that data, with the possibility that more front-end type apps could be built in the future as the data set grows.
For example, I am building a corporate data CRUD system to store important corporate information that will be accessible by a front-end and also an API that can feed to other non DJANGO websites. In the future, I may be adding an entirely different front-end/back-end CMS type system for a single page application. However, some of the data in the database from the corporate data set may be used to populate the website data.
i would take structure like this:
project
manage.py
apps
crudapp
futureapp1
futureapp2
so you can add as many apps as you wish and main project folder doesnot grow
and one more advantage is, your imports will be more beautiful and less name clashing in APPS:
from project.apps.crudapp.models import OneModel
# settings
INSTALLED_APPS = (
'project.apps.crudapp',
)
Related
Almost every video which I saw about Django (for beginners), people who create applications using the startapp command and add their urls.py file manually in their application. My question is, if urls.py is so important for views and for our app why it's not creating automatically when we run startapp command!
Not every app directly serves the end user
URLs.py is only useful for routing users to pages which primarily have to do with that app. However, many apps may only do internal things. I have an app in one of my projects that handles badges and rewards, but there is no page which corresponds to any of that because it all shows exclusively as part of the profile pages (and the routing is handled within the profile app).
It just isn't always needed and that is why it is not always included.
Simply you don't have to serve each of your app to the end-users. You may have apps responsible for only your inner interactions. So it is not logical to put urls.py in each and every app.
It vary on how you use your routing.
django give project wide urls.py by default when you create the project using django-admin startproject command. so you can create all your project's urls on this file.
And not all app intended to server user directly using urls.
Whether i also prefer to create separate urls.py and api-urls.py routers for every app and include in main urls.py
Given the following architecture of django projects apps and database schemas:
There is a django app which I want to share between several django projects.
Each project has it's own postgresql schema in behind. All schemas live in the same postgresql database.
One project is owner of the apps data, this project is responsible to run migrations and the data should live in its schema.
All other projects may access the data from the other projects schema, because they have a proper postgresql search path set.
We already use this concept with an app that has all models set to unmanaged, which works. But database changes always needs to be done manually. I'd like to benefit from django migrations and therefore I want my models either managed or unmanaged.
Do you think app config is good place to change the models meta? Any other suggestions and approaches on how to solve the requirement are also welcome.
The in the comments mentioned setting MIGRATION_MODULES works very well. In those projects which should only access the data and which should not be responsible for the migrations you can easily disable the migrations like that:
MIGRATION_MODULES = {
'yoursharedapp': None
}
Note that you need to configure the postgresql role used in the those projects with proper grants and search path.
I want some clarity. I want to learn more about django and use it as replacement for php/laravel. But the default structure and convention of django confuses me a bit.
My PHP/Laravel project has 3 parts:
- Administration
- Core (Web app for regular users)
- API Service (REST-API for mobile apps)
However all of controllers, models and views are contained in a single Laravel application. I separated Auth, Admin, Api controllers into their own folders/namespaces.
One thing that confuses me is the default Django structure 1 view 1 model file. How should i go about reworking this application in Django should each of my controllers be a separate app in my django project or should I have same approach as in Laravel. 3 Django apps in one project one for admin one for core and one for api ? Where should I keep my models than since in Laravel all models are used by all 3 parts ?
My current structure:
./
./controllers/
./auth/
LoginController.php
RegistrationController.php
...
./admin/
ReportsController.php
UserController.php (Admins overview of all users)
...
./api/
HealthController.php (API CRUD for Health resource)
ExerciseController.php
HomeController.php
UserController.php (Regular users profile page CRUD)
...
./models/
User.php
Health.php
Exercise.php
...
One thing to remember about Django is that an app in Laravel doens't necessary translate to an app in Django. In Django, there are projects, and each project can have any number of apps. For example, I have a "Backup Admin" project where I manage a lot of the day-to-day issues of managing a tape backup environment. I have an app for media (that has 3 models, one for regular media, one for cleaning media, and one for media that we want to exclude from tape ejections). I have an app that represents the backup images, and another for backup jobs (to check status codes). Each sub-piece of my project goes into another app.
If I wanted to do another Django project that had nothing to do with backups, I'd make that a completely separate project, which would have a separate directory structure from my backup project. It'd have it's own urls.py, settings.py, etc.
Regarding the models piece, I put all of one app's models in the same file. For example, in my media app, I have models.py, which contains all three models that I mentioned above. This is completely optional, but I do it just so while importing these models into other parts of the project, I don't have to remember what the file names are, instead I can just do this:
from media.models import CleaningMedia,Media,EjectExclusions
Otherwise I'd have to have 3 different import statements if they were in different files. It's completely possible, but based on your preferences.
Regarding the controller, Django lets you do it either way. You have a project-wide urls.py file that you can use to control all of the traffic, or you can have separate urls.py files in each app to control that app's traffic. I prefer a single file, but that's just me. Personally if you have a lot of controller entries, you should probably split them up into app-specific urls.py files, just to keep it clean, but again, either method would work. I think of maintainability (especially with respect to teammates having to support it) when I make these types of decisions.
The admin interface is built-in, so there's not really an app for that, but you can decide which models and which apps have entries on the admin interface quite easily. Each app has an admin.py file that controls this.
A side note, for a RESTful API, you also might want to consider Django Rest Framework. It's a great piece of software, and the documentation (and tutorials) are very helpful.
Edit:
The 1 view/1 model thing again is just preference. You can have as many files as you want. The only trade off is when you import them into other files, you have to specify the file you're importing it from. That's really all there is to it. I know people who have a views/ directory, and inside there, have separate files for each view, keeping each class/function separate. Totally a matter of preference.
The basic Django app contains models and views, however, this structure seems not enough for a complex web app. How can a designer accomplish a certain level of modulation with Django?
A complex web app can consist of many different Django apps. A Django app is basically a module centered around a set of URLs and/or models.
Besides that, it's all just Python. You can split off business logic code to any Python modules you want, put views in any modules you want, and turn models.py into a models/ package with submodules (as long as the package's __init__.py imports * from all the submodules, I think).
A Django project will often consist of many Django apps
When you start to build a "web app" with Django you are creating a project... inside this you will structure your code into one or more Django apps specific to your project. You will likely make use of a number of 3rd party reusable Django apps as well.
See the tutorial:
https://docs.djangoproject.com/en/dev/intro/tutorial01/#creating-a-project
I want to add Django Sessions to my Django Admin, and I am following an SO post about this, but it is unclear where I store this code. Do I put it in an admin.py file? Under what directory?
In short, it doesn't matter. You can put the code into any of your apps' admin.py files. However, in situations like these I tend to use a generic app in my project, usually named something like utils, that exists for the sole purpose of housing code that doesn't belong to one specific app or could be used by multiple apps.
If you want to be more specific, you can create a sessions app in your project specifically devoted to this code and any other code related to session management for your project, or perhaps an existing app that is somewhat related. For example, I put customizations to the User admin in my accounts app that holds the UserProfile model.