Fully-featured, Django 5 + React 18 boilerplate with great DX.
This is an opinionated fully-featured Django + React boilerplate built for great development experience and easy deployment guidelines.
It is ideal if you want to bootstrap a blog or a portfolio website quickly, or even a more complex application that requires a backend and a frontend, while leveraging the best from React and Django.
After cloning this project, install all dependencies by running:
pnpm run bootstrap
This command will install all dependencies for the frontend (React) and backend (Django) apps.
To start developing on this project, you will need a Postgres database instance running. It doesn 't matter if it's a local instance or a remote one. Just make sure to set up a Postgres database and configure the .env
file with the correct credentials.
For convenience, if you want to use Docker + Docker Compose to spin up a Postgres instance locally, with pgAdmin using alongisde, use the following command:
pnpm run dev:db:up
This project uses Cloudinary as a CDN, so you will need to have an account on Cloudinary and set up the .env
file with the correct credentials. Use the .env.example
file as a reference.
Once you've set up the database, you can start the project by running one of:
pnpm dev # Starts the project while assuming you've setup a database not using the Docker Compose setup. Spins up only the backend and frontend apps pnpm dev:full # Starts the project while assuming you've setup a database using the Docker Compose setup. Spins up a Postgres instance and pgAdmin alongside the backend and frontend apps
By default, the frontend app will run on localhost:4000
and the backend app will run on localhost:8000
. If you're running the containerized Postgres, it will run on localhost:5432
and pgAdmin will run on localhost:5050
.
This application's architect is quite simple and leverages the best of both Django and React. On a nutshell, React and Django integrate through Django's Views and Django Rest Framework's API endpoints.
flowchart TD ns("Frontend") --> ny("React") & n9("Env. variables") nl("Backend") --> nt("Django") & ni("Django Rest Framework") nt --> n5("Views") & nb("Templates") & na("Models") n5 --> nb ny --> n0("API Client") & n4("Root Container") na --> nn("API Key") & nd("Publications") n4 -- Mounts on same file from\nDjango templates --> nb n9 -.-> nn & n0 ni -- Provides a REST\nendpoint to manipulate\ndata from models --> ng("REST API") ng --> nd n0 -- Consumes API Key\nto authenticate\nwith backend --> ng
Below you will find the stack used for each part of the application and the features that are already implemented.
Stack:
- React 18
- React Router 6
- Typescript 5
- Webpack 5
- Tailwind CSS 3
Stack:
- Django 5
- Django Rest Framework
- Postgres
Although this project provides some guidelines on how to deploy the app, it is not mandatory to follow them. You can deploy the app on any platform you want, as long as it supports Docker and Docker Compose, or even deploy the app on a bare-metal machine.
This codebase has two deploy methods available via GitHub actions:
The virtualized-deploy-qa
and virtualized-deploy-prod
branches will trigger this wokflow. You can use it to deploy the app to any Virtual Machine accessible via SSH (AWS EC2s, GCloud apps, Digital Ocean droplets, Hostgator VPSs, etc), and you would likely want to change the name of these branches to something more meaningful to your project.
The bare-metail-deploy-qa
and bare-metal-deploy-prod
branches will trigger this workflow. You can use it to deploy the app straight on the host machine, without any virtualization. This is not recommended, but ou never know when you will need to deploy an app on a bare-metal machine 🤷♀️
You should configure these variables on a .env
file on the root folder for the global configuration and a .env
file for the frontend configuration under frontend/.env
when developing. As for deploying the app, you will need to set the same set of dev variables + some variables exclusively used in production environments as secrets.
Environment variable | Default | Description |
---|---|---|
SECRET_KEY | w%h-ok)&7l2e@1&ht!#ol3!!qg9zwz9hs$wf@fk4e0-7x1r*#d | Django's SECRET_KEY used to encrypt passwords. It can be generated by running: python -c 'from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())' |
CDN_NAME | - | Cloudinary's CDN name |
CDN_API_KEY | - | Cloudinary's CDN API key |
CDN_API_SECRET | - | Cloudinary's CDN API secret |
DB_HOST | - | Database host name |
DB_NAME | - | Database name |
DB_USER | - | Database user |
DB_PASSWORD | - | Database password |
DB_PORT | - | Databse port |
SMTP_HOST_USER | Your SMTP email (should be a GMail one) | |
SMTP_HOST_PASSWORD | - | Your SMTP email password |
TEST | 0 | Used to test the app on the pipeline |
Environment variable | Must be |
---|---|
IMAGE_NAME | Docker image name (for HML, it will append -hml on its name) |
MODE | production . This is hardcoded on the Dockerfile |
ALLOWED_HOSTS | A set of hosts allowed to pass CORS policy. I.g: "www.example.com" "example.com" |
HML_ALLOWED_HOSTS | Same as ALLOWED_HOSTS but for a HML environment |
DEPLOY_TOKEN | A Github token with permission to pull this project's image from your Github registry |
HML_DEPLOY_TOKEN | Same as DEPLOY_TOKEN but for a HML environment |
HOST | The domain under which your site will be hosted (i.g.:example.com) |
HML_HOST | Same of HOST but for a HML environment (i.g.: hml.example.com) |
SSH_PRIVATE_KEY | The SSH key used to access the host machine (currently, one for both PROD and HML environments) |
USERNAME | The SSH username used to access the host machine (currently, one for both PROD and HML environments) |
Environment variable | Default | Description |
---|---|---|
NODE_ENV | development | Let's Webpack know when to build files to correct public path, optimize code and when to prepend localhost for API endpoints or not. Values must be either development or production . This is hardcoded on the Dockerfile |
AUTH_TOKEN | - | An auth key generated on Django's admin that must be associated to a user with specific permissions (i.g.: read specific infos from Django's ORM) |
Environment variable | Must be |
---|---|
HML_AUTH_KEY | Same as AUTH_KEY but for a HML environment |
HML_GTAG_ID | Same as GTAG_ID but for a HML environment |