Serve frontend from same server as the backend

[batpad]

As we move the application into the Mozambique IT environment, we should ideally serve everything from the server we setup there, including the frontend. This will also give us more flexibility in how we handle dynamically rebuilding the frontend when data changes, to handle data updates that are ideally baked into the frontend build.

Roughly I'd do this in two phases:

Phase 1: Serve frontend via nginx on server

• Add a folder on the server like /var/www/moz-frontend
• Pull and build the frontend code
• Add nginx config to server the frontend dist folder on a separate subdomain
• Create a webhook so that pushes to main on the frontend trigger pulling latest code and rebuilding on the server to serve an updated frontend.

At this point, we'd have the frontend being served from the server, and we will have the ability to trigger a rebuild by pushing a commit to main.

Phase 2: Auto re-build frontend in response to data changes

As the frontend "bakes in" some data from the backend as part of the build, we ideally also want a way to have the frontend build be re-triggered when something in the backend data / data models change. For this, we would want roughly:

• Create a celery task to handle rebuilding the frontend
• Trigger the celery task whenever a data model / scenario is added or edited

Since automatically triggering the build in response to data changes could get a little tricky, the other option would be to have something like a button on the Admin that says "Publish Frontend" which triggers the celery task via an explicit user action in the Admin.

I need to think about this a bit. I think I can go ahead with Phase 1 described above and just get the server serving the frontend with the same nginx setup, may need some help thinking through Phase 2 to automate re-builds.

cc @hanbyul-here @willemarcel @LanesGood

[hanbyul-here]

There are two spots that need data from back-end while generating the application.

First is to generate pages (model/${model-slug}/), and the second is to populate UIs. Second is a nice to have, it is nice if users don't have to wait for UI to be loaded, and it will be nice if we just make the build fail with incorrect configuration. But First is critical.

Currently, the pages are being generated with slugified model's name. If the model's name changes, and the build is outdated, this data doesn't have a page to be served, falling back to 404 page and make 404 page work like SPA. (like current staging works) Considering it is so unlikely that there will be more/less models in the future, detecting changes on model name might be enough - even though I am not sure if this decreases the amount of work at all.

If time allows, I recommend deploying front-end application to be included in the training. There can be surprising factors like subdomain + assets.