From idea to a working proof of concept on Azure

From brief to data model

Nouns become tables; states become a rule table. LeaveLoop: employees, leave_requests (status, decided_by, decided_at, reason), audit_log.

• Key by what makes a record unique, usually unit and period, or next year overwrites this one.
• Constraints in the database (CHECK, UNIQUE, foreign keys) catch what code misses.
• Rule table first: (from, to) → roles and state → role → fields. Enforce on the server.
• Review the schema with a human before any screen. It's the costliest thing to change later.

• Use the Azure pricing calculator with the right region; always-on is about 730 hours a month.
• Biggest to smallest for this stack: App Service plan, SQL database, edge/WAF or private networking, monitoring ingestion. Storage and Key Vault are small.
• Budget and tags: Cost Management in the portal; --tags CostCenter=... Owner=... at creation.
• Log Analytics bills by data ingested; keep retention short for a POC.

Keep every environment difference (database address, secrets, allowed origins, demo-data switch) in environment variables read by one config file.

az login
az account set --subscription "<id or name>"
az account show -o table      # confirm tenant and subscription first

Tools: Azure CLI, Git, Node 20+, your runtime. Open a new terminal after installing. If database tokens are blocked on your laptop, use the in-app setup in Part 7. If Graph is blocked, read your object id from the oid claim of your ARM token.

1. Schema first (SQLite locally, Azure SQL in cloud). Portable SQL (? placeholders, no ON CONFLICT/MERGE), one file that knows dialect differences, a test that fails if schema files drift.
2. Rule table: TRANSITIONS: (from, to) → roles; EDITABLE: state → role → fields. 403 for role problems, 409 for state problems.
3. Audit: one row per changed field, in the same transaction; write nothing if nothing changed. Append-only (ledger table on Azure SQL).
4. Auth: signed, expiring tokens; routes depend only on current_user and require_roles, so Entra ID can replace the login.
5. Tests: rules, permissions (including must-be-refused), calculations. Run on every change.
6. Seed: idempotent, gated by SEED_DEMO_DATA, only on an empty database.
7. Operations: /health and /health/db from day one; config in environment variables.

Variables

$RG   = "rg-leaveloop-poc"
$LOC  = "<approved region>"
$PLAN = "plan-leaveloop-poc"
$APP  = "app-leaveloop-poc-<unique>"   # becomes <APP>.azurewebsites.net, globally unique
$SWA  = "swa-leaveloop-poc"

1 · Group and plan

az group create -n $RG -l $LOC --tags CostCenter=<code> Owner=<you>
az appservice plan create -g $RG -n $PLAN --is-linux --sku B1

2 · Static Web App and token

az staticwebapp create -g $RG -n $SWA -l <swa region> --sku Free
$swaHost  = az staticwebapp show -g $RG -n $SWA --query defaultHostname -o tsv
$swaToken = az staticwebapp secrets list -g $RG -n $SWA --query properties.apiKey -o tsv

The token is a password. Don't commit it.

3 · The API web app

az webapp create -g $RG -p $PLAN -n $APP --runtime "PYTHON:3.12"
az webapp config set -g $RG -n $APP --startup-file "bash startup.sh"
az webapp config appsettings set -g $RG -n $APP --settings `
  SCM_DO_BUILD_DURING_DEPLOYMENT=true ENABLE_ORYX_BUILD=true `
  "SECRET_KEY=<long random string>" "ALLOWED_ORIGINS=https://$swaHost"

ENABLE_ORYX_BUILD=true makes App Service install requirements during a zip deploy. Without it: 503.

4 · Deploy the API

Zip with code, requirements.txt and the startup script at the root, forward-slash paths, LF line endings. Build it with a script (Python zipfile), not Compress-Archive.

az webapp deploy -g $RG -n $APP --src-path ./deploy.zip --type zip --async true
# poll https://$APP.azurewebsites.net/health (first start installs packages: a few minutes)

5 · Build and publish the front end

cd frontend
$env:VITE_API_URL = "https://$APP.azurewebsites.net/api"   # baked in at build time
npm ci
npm run build
npx --yes @azure/static-web-apps-cli deploy ./dist --deployment-token $swaToken --env production

Anything with a VITE_ prefix ships to every browser: no secrets. Search the bundle for the host name to confirm it points where you meant.

6 · Verify

• GET /health OK; sign in as each role; one allowed and one forbidden action.
• Browser network error but curl works: check CORS (ALLOWED_ORIGINS must hold the exact front-end URL).

az webapp log config -g $RG -n $APP --docker-container-logging filesystem
az webapp log tail   -g $RG -n $APP

For a throwaway demo, keep SQLite on the web app's persistent /home disk. It doesn't survive scaling to several instances, so move to Azure SQL once the data matters.

• Entra-only authentication on the SQL server: no SQL logins exist.
• A named person (ideally a group) is SQL admin.
• The API's managed identity is a database user with read/write on tables only.
• Optional ledger audit tables: WITH (LEDGER = ON (APPEND_ONLY = ON)). Tampering becomes detectable, not impossible.

One-off table setup

A, from your machine (if developer machines may get database tokens): add your IP to the firewall, az login --scope https://database.windows.net/.default, run setup as admin, create the API's user, remove the firewall rule.

B, from inside the web app (when conditional access blocks A):

1. Make the app's identity the temporary SQL admin (management call, no database sign-in):

   az sql server ad-admin create -g $RG -s <sql server> --display-name $APP --object-id <app principal id>

2. Run setup at start, controlled by e.g. SETUP_MODE=real: create tables, seed reference data, grant the identity read/write. If FROM EXTERNAL PROVIDER fails ("Server identity is not configured"), create the user from the identity's client id (CREATE USER [name] WITH SID = ..., TYPE = E).
3. Watch the setup log until it succeeds.
4. Restore the human admin, delete the setup settings, restart.
5. Confirm /health/db reports the Azure SQL database.

Rehearse on a throwaway database named *_test, and make any destructive reset refuse to run elsewhere. Connect with ActiveDirectoryMSI on Azure (ActiveDirectoryDefault locally). With no server configured, fall back to SQLite.

• HTTPS only, TLS 1.2, FTPS off, health check set.
• Roles enforced on the server by role and workflow state; tests for refusals.
• Audit log in the same transaction; ledger on audit tables.
• Managed identity for Azure-to-Azure access.
• Storage private, no shared keys; uploads limited by size and an allow-list (never executables or HTML).
• Front-end build variables are public: no secrets.

• Entra ID sign-in (external tenant for partners).
• Private endpoints or restricted SQL firewall; remove "allow Azure services".
• Front Door with WAF; custom domain.
• Time-based immutability policy on the ledger digest container.
• Blob uploads via short-lived links; geo-redundant backups; staging slot (Premium plan).

requests   | where success == false | summarize count() by name, resultCode, bin(timestamp, 1h)
exceptions | order by timestamp desc | take 50

• Alerts: health check failing, HTTP 5xx, database CPU/DTU over 80%.
• Budget alert set; tags on every resource.
• Teardown: az group delete -n $RG removes everything inside. Check the name twice. Key Vault soft delete keeps the vault name reserved for its retention period.