I'm going to answer your question on how to do what you ask, but I will also point you in a direction that I believe is more efficient, stable and faster method.
TLDR: Go to the bottom under notes
Most of the tutorials say that you have to integrate angular into django
I'm not quite sure why or where these tutorials are that say you need to integrate
Angular into Django, as they are not something that can integrate, but they work together. The frontend-application (in this case Angular) will typically make requests to a backend (in this case DRF), they don't exist together as a single code base.
I want to deploy both on the same server
Before I begin, I should say that I have lots of industry experience in maintaining production services. Although you wish to deploy on the same server, I would advise against this, as you usually will have usually have each service sitting behind load balancers, as the strain for resources is much higher when running backend code vs delivering frontend bundles.
Now you can either have Angular and DRF on the same server, or on different servers, but essentially boils down to having something like NGINX on a/the server, which can deliver clients the Angular bundle you have created, or data from the DRF backend, with two configuration files in Nginx.
The following configuration would, if the client connects to example.com, return the Angular bundle (Specifically the index.html of the bundle) sitting in /var/www/example.
# example.com.conf
server {
root /var/www/example;
index index.html;
server_name example.com;
location / {
try_files $uri $uri/ = 404;
}
listen 443 ssl;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
include /path/to/options-ssl-nginx.conf;
}
server {
listen 80;
listen [::]:80;
server_name example.com;
include /path/to/encrypt.conf;
location / {
return 301 https://example.com$request_uri;
}
}
And the following can be used to allow requests from the Angular application to get data from the backend via making requests to api.example.com:
# api.example.com.conf
server {
server_name api.example.com;
listen 443 ssl;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
include /path/to/options-ssl-nginx.conf;
location / {
proxy_pass http://0.0.0.0:8000;
proxy_set_header Host $myhost;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect off;
}
}
server {
listen 80;
listen [::]:80;
server_name api.example.com;
include /path/to/encrypt.conf;
location / {
return 301 https://api.example/com$request_uri;
}
}
Deployment
There are a few ways to do this:
You run the service(s) on the server(s) ... NO DOCKER :'(
This is more traditional but essentially boils down to installing dependencies for Node, Python, etc, on a server or servers, which most likely differs from the development/staging environment. What I mean by this, is that if you have developed all the code on a Macbook, and then run the code on a Linux server, it's most likely that the way you installed packages are different, and not all packages can work on all operating systems, leading to code you have written suddenly breaking.
Now whenever you update your code, you don't want to mess with the server already in production, so you will need to start a new server, install all requirements again, etc..., It's a lot of work.
Run the service(s) on the servers(s) ... WITH DOCKER :D
I can't express enough how amazing and useful docker is!!. If you have not used it, it essentially allows you to have your code run inside containers that run the same whether you are on Mac, Windows or Linux. The containers are in pretty much all regards, as fast as running them without a container.
Now this is great, you can do exactly the same as above, but containerize the DRF code, containerize the Angular code, and then containerize an NGINX proxy, and then let the NGINX container route requests to different containers or servers, such as:
location / {
proxy_pass http://drf-container:8000;
Now this means, that you can now run the same code in development, staging, and production, knowing that the results will be the same, no hidden surprises when deploying.
Run the services on a cluster with docker (most popular)
I have maintained servers on both AWS and Digitalocean.
AWS allows you to start a cluster of servers, and then you can upload docker images to their repository. Once that is done, you can then start docker container instances, with pre-allocated resource limits, and then AWS we automatically deploy them to the cluster. This is great because AWS also allows a seamless way to update running containers, and if the new container is healthy, AWS will automatically drain connections from the old container to the new container, and then remove the old container. This means extremely fast, safe and efficient deployments.
Digitalocean now offers something similar, 2019 saw their Kubernetes feature go from beta to fully supported. Kubernetes can do exactly the same as what I described AWS does above, just a little more manual setup.
Summary
I hope the above helped clear up the deployment of Django and Angular. Essentially, in a most simplistic way boils down to having the following docker containers;
- Angular container (containing the dependencies to develop angular applications)
- Django container (containing the dependencies and Django codebase)
- Nginx container (containing the production bundle from Angular container, and a
.conf file containing the configuration to proxy-pass to the Django container.)
And then deploying those containers to a server or cluster
Notes
With serverless going big these days, my personal setup that I like, is that my backend microservices (some in python, some in go) offer graphql apis, and are sitting on a cluster described above. Apollo federation can run serverless or in a server, and combine all microservice graphql api's into a single unified one. and then my frontend clients can then just query a single url. No need for Nginx, very scalable serverless graphql api, and very scalable docker instances on the cluster, and because it's using docker, makes it very easy for development.
