Matt Segal Dev

3 ways to deploy a Django backend with a React frontend
Tue 07 April 2020, by Matthew Segal
Category: Django

You're developing a web app with a Django REST backend and some sort of single page app frontend using React or Vue or something like that. There are many ways for you to run this app in production. There are a lot of choices that you need to make:

How do you choose? What is "the right way"?

Well, the bad news is that there is no "right way" to do this and there are a lot of different trade-offs to consider. The good news is that I've compiled three different options with their pros and cons.

Option 1 - Cram it all into Django

This is the "default" approach, where you have a Django site and you just add React to it. All your HTML is served via Django views, and all your JavaScript and CSS is bundled by Django and served as static files. All your code, frontend and backend, is in one Git repository. You serve the app from a single domain like www.myapp.com.

When you deploy your code using this setup, you will need to:

You will need to use a setup like this or django-webpack-loader to integrate Webpack's build assets with Django's staticfiles system and templates. Other than that, it's a vanilla Django deployment.

The pros are:

The cons are:

Choose this when:

Option 2 - Completely separate infrastructure

This is an approach that has become more popular over the last several years. In this setup you have two separate codebases, one for the frontend and one for the backend, each with their own Git repository.

The frontend is deployed as a "static site" of just HTML CSS and JavaScript assets. It is hosted separately to Django, in an AWS S3 bucket, Netlify, or something similar. The frontend is built, tested and deployed independently of the backend. The frontend gets data from the backend soley through REST API calls.

The backend is a Django REST API with no HTML views (other than the admin pages), and hosts no static content (other than what's needed for the admin). It is built, tested and deployed independently of the frontend.

Importantly, since the frontend and backend are on different servers, they will also have different domain names. The backend might live on something like api.myapp.com and the frontend on www.myapp.com.

The pros are:

The cons are:

Here are some cross domain Django settings that I hope you never need to think about:

Choose this when:

Option 3 - One server, separate deployments

This approach is an attempted fusion of options 1 and 2. The idea is to still deploy the frontend as a separate static site, but you deploy everything to one server, under a single domain name:

You manage this by using a webserver, like NGINX, which handles all incoming requests. Requests to the URL path /api/ get sent to the WSGI server which runs your Django app (traditional reverse-proxy setup), while all other requests are sent to the frontend, which is set up as a static site and served from the filesystem (eg. /var/www/).

The pros are:

The cons are:

Choose this when:

I'll be honest here. I actually have never tried option 3 (I've used 1 + 2 before). I thought it up when replying to a Reddit post. I think it'll work though. Good luck!

If you have any feedback or questions email me at [email protected]