General Architecture Application
On this page we'll explain the general infrastructure of our application. In the image below you can see an overview of all the containers and the ports on which they operate. Only the nginx one exposes ports to the world.
We use Docker for as our production and development environment. This has several advantages:
-
Portability: Docker allows us to package our entire development environment, including all the necessary dependencies, into a lightweight container. This makes it easy to share the environment with other team members or deploy it to different machines without worrying about compatibility issues.
-
Consistency: We can ensure that every developer in our team is working in the exact same environment. This eliminates the problem of "it works on my machine" and helps to minimise any configuration-related bugs.
-
Isolation: Docker provides isolation between our development environment and the underlying host system. This means that any changes or modifications made within the container will not affect the host system. It also allows us to run multiple containers simultaneously without conflicts.
We use Docker Compose to manage our multi-container application. The docker-compose.yml file contains the configuration for Docker Compose to define and manage the services, networks, and volumes.
To be able build our application you'll need an .env file in the main folder of the project. This file contains secrets that shouldn't be revealed. This file must contain the following keys:
-
ENVIRONMENT- development/production -
POSTGRES_PASSWORD- user password required for login into the database -
POSTGRES_USER- username to login into the database -
POSTGRES_DB- name of the database -
DJANGO_SECRET_KEY- a hash of random characters to secure the backend -
SECRET_EMAIL_USER- the email address that sends the emails to the users when passwords get dropped -
SECRET_EMAIL_USER_PSWD- the password of the email client (usually an application password, not user password)
We use Nginx as a reverse proxy in our application:
We have three exposed ports to the outside world:
-
80/443for the front-end, routes to the front-end service on port3000 -
2002for the backend, routes to the back-end service directly on port8000
There is only one exception to the internal routing diagram: GET http(s)://<domain>/documentation will route from port 80 to the backend directly (2002) on docs/ui/
We use Django as our backend. Despite being a full-stack Python framework, we only use it as a backend server. The backend currently only supports HTTP requests, however it's built in a RESTFUL way, so other representations could be supported in the future.
The server that hosts the backend is a Daphne server. This server instance has been developed by the developers of the Django project to support web-sockets and asynchronous design. However we don't take the full advantage of the asynchronous features yet (since we still use synchronous middleware), but making our backend fully asynchronous was out of scope for the assignement. Maybe this could be a future project.
We use Postgres as our database management system for persistent data storage. However we normally don't interact with the database itself. We'll use the ORM supported by Django for this.
We use Redis as the channel layer in our backend (to make websockets work). Redis includes a publish/subscribe messaging mechanism. It allows different components of an application to communicate with each other through publish and subscribe channels. Publishers send messages to specific channels, and subscribers receive and process these messages in real-time, enabling efficient message-based communication between components.