feat: add Azure Functions API with caching proxy

[trieloff]

Summary

Adds an Azure Functions backend API that proxies and caches responses from Google Apps Script, reducing load and improving response times.

Changes

• Azure Functions API (api/ folder)

  • getCurrentIncident endpoint that proxies Google Apps Script
  • 2-minute cache with stale fallback on errors
  • Returns X-Cache: HIT|MISS|STALE headers

• GitHub Actions Deployment

  • Auto-deploy to production (aem-status-api) on main
  • Auto-deploy to staging (aem-status-api-staging) on feature branches
  • GitHub deployment tracking for visibility

Endpoints

• Production: https://aem-status-api.azurewebsites.net/api/getCurrentIncident
• Staging: https://aem-status-api-staging.azurewebsites.net/api/getCurrentIncident

Secrets Required

• AZURE_FUNCTIONAPP_PUBLISH_PROFILE - Production publish profile
• AZURE_FUNCTIONAPP_PUBLISH_PROFILE_STAGING - Staging publish profile

[Copilot]

Pull request overview

This PR introduces an Azure Functions backend API that serves as a caching proxy for Google Apps Script, reducing load on the upstream service and improving response times through a 2-minute cache with stale-on-error fallback.

Key Changes:

• Adds Azure Functions API with getCurrentIncident endpoint that proxies Google Apps Script
• Implements 2-minute cache with stale fallback mechanism and cache status headers
• Adds GitHub Actions workflow for automated deployment to production and staging environments

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
api/src/functions/getCurrentIncident.js	Core function implementing caching proxy with error handling
api/package.json	Package configuration for Azure Functions with ES modules
api/package-lock.json	Lockfile with @azure/functions v4.9.0 and dependencies
api/host.json	Azure Functions host configuration with logging settings
.github/workflows/deploy-functions.yml	Deployment workflow for production/staging environments
.github/workflows/azure-static-web-apps.yml	Added deployment tracking for static web app

Files not reviewed (1)

• api/package-lock.json: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The getCurrentIncident function lacks test coverage. Given that the repository uses Node.js native test runner (see test/details.test.js), consider adding tests for: cache hit/miss scenarios, stale cache fallback on errors, error handling when both fetch fails and cache is empty, and proper cache expiration.

[trieloff]

We have post-deploy integration tests (api/test/post-deploy.test.js) that verify the API works end-to-end after each deployment. Unit tests with mocking would require additional dependencies. The integration tests cover the critical paths: status codes, headers, and response structure.

[rofe]

I'm not exactly clear on the problem are we trying to solve with this... I can see that load on the Google API could be reduced, but the end user experience would not change that much:

• The first visit to www.aemstatus.net would still trigger an initial call to Google Apps (Azure cache miss), which would now even take slightly longer due to the roundtrip through the Azure function
• www.aemstatus.net currently refreshes the current incident every 30s, which would now be faster but also obsolete due to the 2 minute cache, so for this interval to stay useful, it should be increased to match the Azure cache TTL
• If www.aemstatus.net refreshes the current incident every 2 minutes instead of 30s, it will always be an Azure cache miss and trigger a Google Apps call, making the Azure function obsolete
• The only scenarios where an end user would benefit from a quicker response (and the load on the Google API would be reduced) are:
  • When more than 2 users visit www.aemstatus.net in a 2 minute window: User A gets a cache miss in Azure, triggers a call to Google Apps and waits. User B, C, etc benefit from the Azure cache. But do we have traffic data from www.aemstatus.net that makes this a realistic scenario?
  • When they navigate away from the homepage (i.e. to read a postmortem) and come back within 2 minutes. But I would consider this an edge case that wouldn't warrant a complex setup...
• Also, what happens if multiple users trigger calls to the Azure function while it is still waiting for Google Apps to respond? Does it deliver stale cache (if available)?

[rofe]

@trieloff How about this for a simple, intermediate solution to address the delayed loading the current incident data:
On page load, and just once, we show a placeholder between the services and last 30 days sections. It contains a loading/spinner graphic and text saying "Hold on while we are checking if there is an ongoing incident...".