Before you start
A coding agent and comfort with a local client/server project. Use fictional data and two test accounts.
Why this lesson exists
This lab adapts the “Build a Full-Stack Life Tracker on Azure” project write-up into a practice build. The time is an estimated first session, not a promise to finish a production system. Use the public repository as a reference when available; the exercise can be built with original sample content.
Do the exercise
Define the practice version
The archived LifeTracker project explored separate frontend, API and infrastructure layers. Use the lesson as architecture practice; verify current identity-provider guidance instead of copying older service choices.
Build step 1
Build one vertical slice: create and list habits.
Build step 2
Define the API contract before wiring the interface.
Build step 3
Add authentication and verify tokens on the server.
Build step 4
Store user IDs with every record.
Build step 5
Add tests for cross-user access.
Build step 6
Add infrastructure automation after the local system works.
Run the experiment
Create one record as user A. Confirm user B cannot list, fetch or modify it through direct API calls as well as the interface. Test an unauthenticated request.
A prompt to adapt
Replace the bracketed parts with your own practice details.
Work in a disposable practice project. Explain any setup requirements before changing files. Build one small step at a time and show how I can check it. Design a secure vertical slice for a habit tracker with React and Express. Include TypeScript request/response schemas, authentication boundary, database fields, validation, error cases, and tests proving one user cannot read another user’s habits. Compare this older frontend/backend/Kubernetes architecture with a modern managed-platform alternative. Preserve security and portability, but identify complexity that is unnecessary for an early prototype. My first-version boundary: The archived LifeTracker project explored separate frontend, API and infrastructure layers. Use the lesson as architecture practice; verify current identity-provider guidance instead of copying older service choices.
Run this experiment
Create one record as user A. Confirm user B cannot list, fetch or modify it through direct API calls as well as the interface. Test an unauthenticated request.
Check your result
Use evidence from your output. A confident explanation from the AI is not enough.
- The server verifies identity and ownership.
- Cross-user access is rejected.
- Validation errors are visible and do not expose secrets.
If it isn’t working
Hiding a button is not authorization. Enforce the boundary on the server, and choose current supported identity services before production.
Optional. Progress stays in this browser.
Where this came from
Public project repository ↗. The practice lesson is an adaptation, not a verbatim transcript. About the sources.
Prepared September 2026. Tools and interfaces change; use current official setup instructions. Session lengths are estimates.