MNPC/RasadDam_Backend
9
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

test deployment

Browse Source
This commit is contained in:
Mojtaba-z
2025-11-18 12:01:56 +03:30
parent 0a4eb5c731
commit 72c9f3ada6
1 changed files with 40 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

75
README.md
View File

@@ -7,8 +7,8 @@
![Postgres](https://img.shields.io/badge/postgres-%23316192.svg?style=for-the-badge&logo=postgresql&logoColor=white)
![Swagger](https://img.shields.io/badge/-Swagger-%23Clojure?style=for-the-badge&logo=swagger&logoColor=white)
# Django Project Structure
This is a template/project structure for developing django-based applications -
using `django-rest-framework` along with `django`.
@@ -16,26 +16,26 @@ The project is meant to be easily clone-able, and used as the starter template
for the next big thing you develop. Note, this is a folder structure only, not
“best practices”.
## Some batteries included:
* [Django Storages](https://django-storages.readthedocs.io/en/stable/) - To integrate with different types of storages
* [Django Rest Framework](https://www.django-rest-framework.org/) - For API development
* [Django CORS Headers](https://github.com/adamchainz/django-cors-headers) - To allow requests from other origins
* [Sentry](https://docs.sentry.io/platforms/python/) - For crashes
* [Gunicorn](https://gunicorn.org/) - As a web server
## Getting Started
1. Since this is a template repository, simply hit "Use this template" on GitHub
and follow the instructions. Otherwise, you can just clone the repo, remove/add
anything you see fit.
and follow the instructions. Otherwise, you can just clone the repo, remove/add
anything you see fit.
1. Run the project using `python manage.py runserver` and you should see the
default success page provided by Django at
[http://127.0.0.1:8000/](http://127.0.0.1:8000/).
default success page provided by Django at
[http://127.0.0.1:8000/](http://127.0.0.1:8000/).
1. [Optional] If you want to configure database, in the `DATABASE` section of
`settings.py` we have added `postgresql` as the default `DATABASE` (As most of
the application are using it). You can roll back to the `sqlite` by adding the
following code snippet, removing the current one.
`settings.py` we have added `postgresql` as the default `DATABASE` (As most of
the application are using it). You can roll back to the `sqlite` by adding the
following code snippet, removing the current one.
```bash
DATABASES = {
@@ -46,14 +46,14 @@ DATABASES = {
}
```
### Creating an App
1. Create a folder with the app name in `apps`. For example: `poll`
1. Run `python manage.py startapp poll apps/poll` from the root directory of the
project
project
## Project Tree
``` bash
.
├── apps/
@@ -114,33 +114,35 @@ project
└── README.md
```
## Rationale
Each `app` should be designed in way to be plug-able, that is, dragged and dropped
into any other project and it’ll work independently.
### `apps` Folder
* A mother-folder containing all apps for our project. Congruent to any
JS-framework's `src` folder. If you really wanted to, you could even call it the
`src` folder. Again, it's up to you.
JS-framework's `src` folder. If you really wanted to, you could even call it the
`src` folder. Again, it's up to you.
* An app can be a django template project, or a rest framework API.
### `services`
* We’ll be writing business logic in services instead of anywhere else.
* There's a common argument: "Why not just use model managers?", and honestly,
that's a fair point. However, for our use case, we've often noticed that a single
service can leverage more zero to many models. Either way, managers or services,
both work towards the same goal - isolating business logic away from views, and
brings it closer to the data.
that's a fair point. However, for our use case, we've often noticed that a single
service can leverage more zero to many models. Either way, managers or services,
both work towards the same goal - isolating business logic away from views, and
brings it closer to the data.
### `api` Folder
* We like to place all our API components into a package within an app called
`api`. For example, in this repository it's the `example/api` folder. That
allows us to isolate our API components in a consistent location. If
we were to put it in the root of our app, then we would end up with a huge list
of API-specific modules in the general area of the app. That's without getting
into the mess of API versioning.
`api`. For example, in this repository it's the `example/api` folder. That
allows us to isolate our API components in a consistent location. If
we were to put it in the root of our app, then we would end up with a huge list
of API-specific modules in the general area of the app. That's without getting
into the mess of API versioning.
For projects with a lot of small, interconnecting apps, it can be hard to hunt
down where a particular API view lives. In contrast to placing all API code
@@ -148,13 +150,14 @@ within each relevant app, sometimes it makes more sense to build an app
specifically for the API. This is where all the serializers, renderers, and views
are placed. Therefore, the name of the app should reflect its API version
#### API Versioning
It might often be necessary to support multiple versions of an API throughout
the lifetime of a project. Therefore, we're adding in support right from the
start.
For different API versions, we're assuming the following will change:
- Serializers: That is, how the data is presented to a consumer
- Views: That is, how the data is accessed and modified by a consumer
- URLs: That is, where the consumer access the data
@@ -167,35 +170,37 @@ data is handled and managed within your application.
Sufficient unit tests and integration tests should wrap services and API
endpoints to ensure full compatibility.
#### What's `v2` of an API?
Currently, we're proposing that major changes to the following constitutes a new
API version:
1. Representation of data, either for submission or retrieval
1. Major optimizations
1. Major code reorganization and code refactor
1. Usually, in a Django project, you won't need to worry about API versioning
### `config`
* Contains project configuration files, including the primary URL file
* ~~Contains settings split into `base`, `local`, `production` and `development`.~~.
Update: As environment specific variables will be handled using environment
variables, we've deemed it unnecessary to have separate settings files for now.
Update: As environment specific variables will be handled using environment
variables, we've deemed it unnecessary to have separate settings files for now.
### `deployments`
* Contains Docker, Docker-Compose and nginx specific files for deploying in
different environments.
* Contains Docker, Docker-Compose and nginx specific files for deploying in
different environments.
### Exception handling
You should probably add a custom exception handler to your project based on
who consumes your APIs. To learn how to create a custom exception handler,
you can check out the Django Rest Framework documentation at:
https://www.django-rest-framework.org/api-guide/exceptions/#custom-exception-handling
## FAQ
> Why not just make a cookiecutter out of this?
Honestly, GitHub templates are so much easier. It's a one-click solution and
@@ -205,8 +210,8 @@ linters, etc. And that's something better left to the developer. Although, I am
playing around with the idea of having a cookiecutter with those sensible
defaults, but let's hope we have time to work on it on the `cookiecutter` branch.
## References
- [Two Scoops of Django by Daniel and Audrey Feldroy](https://www.feldroy.com/books/two-scoops-of-django-3-x)
- [Django Best Practices](https://django-best-practices.readthedocs.io/en/latest/index.html)
- [Cookiecutter Django](https://github.com/cookiecutter/cookiecutter-django)