Advanced level · Module 6: JavaScript Capstone Project · Lesson 1 of 5
Capstone Requirements and Sync Design
Define the users, data and offline behaviour, and design how visits recorded offline are synchronised safely.
In this lesson you will
- Write user stories and a data model for the tracker
- Design an idempotent sync process
Key concepts
user storiesdata modelclient-generated IDsidempotent sync
The lesson
Community health workers record visits in places without coverage. Stories describe their needs: record a visit offline, see which visits are waiting to sync, and see a summary per area once synced.
Give each visit an ID generated on the device (crypto.randomUUID()). When the app syncs, it sends visits with their IDs; the server stores each ID once, so sending the same visit twice after a dropped connection creates no duplicate. This property is called idempotency.
Record each visit's sync state — pending, synced or failed — and design what the user sees in each state.
Step by step
- Write user stories with acceptance criteria.
- Define the Visit and Household types.
- Design the sync request and server behaviour.
- Describe the sync states in the UI.
Practice activity
Submit the requirements, types and sync design for milestone 1.
Expected result: An approved design that explains how duplicates are prevented.
Check your understanding
-
Why generate visit IDs on the device?
Show answer
So the same visit keeps one ID across retries, letting the server ignore duplicates.
-
What does idempotent mean for sync?
Show answer
Sending the same data more than once has the same effect as sending it once.
Taught live by an instructor — online or in person. Free course lessons are for self-study and do not lead to a certificate — see registration options.