1

My company uses Azure as our cloud-infrastructure provider, and we are making use of their Azure Webapp PaaS offering to individually deploy our SPA (react.js) and corresponding API (Golang). Haven't felt the need to move to Kubernetes as of yet.

For CI/CD we utilize the GitHub Actions + Azure Web App Deployment slots - a relatively simple setup. Currently both our API and React SPA have three deployment slots in their Web App resource called:

  1. Production (the web app itself)
  2. Main
  3. Stage

Merging on stage branch leads to deployment on stage slot, and merging on main branch leads to a deployment on main slot. When given the go-ahead the Main slot is swapped with the Production one and so now we have code from main branch in the production slot (environment). Swapping allows for zero downtime of production app and avoids directly deploying to the production slot.

For the react spa, all env variables need to be specified at build time; these includes: api_uri, auth_system_uris, etc. This means when merging on the main branch we need to specify all env variables for production slot (not really the main slot). I understand that there shouldn't be the slightest bit of difference between these two deployments but still am confused about the overall architecture.

Do I even need three deployments for my React SPA, if so, how do I make it work? Should main slot of my spa communicate with main slot of api (but that wouldn't work due to the necessity of keeping things same between prod and main slots) ? It would be great help if someone could briefly describe how this architecture should best be set up. Thanks.

Improve this question

1 Answer 1

Reset to default
1

My first thought when I see two components that depend on each other during a deployment - often the app and the database - I try to come up with a way to decouple them.

If you can deploy your UI and API independently, you'll avoid many problems that are caused when they don't match.

You can use similar patterns to update the API in ways that mean the UI can work with either the old or new version (for example the expand/contract pattern), or you can deploy versioned APIs so the UI always calls the version you trust to work (for example /api/v1/operation).

The one thing you don't want to rely on is the UI and API going live at the exact same nanosecond.

With this in mind, you UI and API should have zero knowledge of which slot to talk to. You don't want to manipulate the production slot to talk to the main slot or anything similar to that.

You can set up the configuration against the slot, to prevent having to reconfigure config files in version control.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.