ORSANCO Architecture
Previous work
- The ORSANCO project was initially started as a React + ASP.NET Core backend project. (Around: Aug 2022)
- Later around Sept 2022, decision was made to switch from a ASP.NET Core to a Django backend.
- The repositories were later split into separate ones for frontend and backend for easier deployment.
- Around Nov 2022, the Django backend was refactored again to go from having 2 Django apps to a single Django app.
- As of 22 March 2023,
- Gold standard repo for frontend, which is deployed → here as an SWA using GH actions on Azure
- Gold standard repo for backend which is deployed → here inside a Azure Linux VM
Previous work wrt to app service and DRF
- There were a lot of issues when the Django backend was deployed as an App Service.
- After a lot of going back and forth with Azure support and spending a lot of time on it, Sudhir was able to get an App Service talking to a React frontend.
note
The App Service was able to return fake data from the backend to the frontend. The App Service was never able to access data from the PostgreSQL database from the VM and return that data to the frontend.
Notes on the frontend
danger
TLDR; Proxy is not meant to be used in production (deployment). It is only meant to be used of local development.
Links which give this answer
Suggested solution
What to use instead of a proxy? Answer → HERE

About backend
danger
The frontend deployed on Azure is served over https. The backend when deployed needs a certificate, if you use a self-signed certificate, you need to manually trust the site → documented here
This is because, you can't access insecure content from a secure domain.
- Once the Django app is runnning inside the Linux VM, the port on which the Django app needs to exposed through the portal.
- Origins allowed to ping the Django backend are NOT inside
settings.py, but are actually configured with thenginx.conffile. - A custom domain was bought was the ORSANCO VM and SSL certificate was also bought.