Follow one piece of data

Browser storage is not one box. Cookies, Web Storage, IndexedDB, Cache Storage, and origin-private files all live in the browser, but they solve different jobs.

Most storage bugs start the same way. Someone reaches for localStorage because it’s the API they know, and the data outgrows it. So before picking an API, follow one value through its whole life.

The questions to ask

Take a single piece of data and ask:

• who creates it?
• which code reads it?
• does the server need it on every request?
• how large can it grow?
• when does it expire, and who deletes it?
• how does the user get it back after losing it?

The answers tell you where the value belongs. The API becomes a consequence, not a habit.

Our running example

Throughout this course we’ll build a small field-notes app. Think of a hiker writing short notes on a phone, sometimes with no signal, sometimes with a photo attached.

The app stores a handful of things, all different:

• a color theme. Small, replaceable, nobody cries if it’s lost
• an unfinished editor draft. It belongs to the tab you’re typing in
• saved notes. Structured records that grow and need searching
• help pages. Fetched responses we want to read offline
• attachments. Files, sometimes large
• a login session. The server must see it on every request

That’s six values and five different storage shapes. A theme and a login session both look like “a small string”, but one must travel with HTTP requests and one doesn’t. That single difference decides the API.

Assume the data can disappear

My advice is to treat every value in the browser as temporary. A user can clear site data with two clicks. A private window throws everything away when it closes. A phone gets replaced. And browsers evict best-effort storage on their own when the disk fills up, without asking.

If losing a value would hurt, the browser can’t be its only home. Give the user an export, or sync to a server. We’ll build the export at the end of the course.

If losing a value is harmless, say so. A theme falls back to light and nobody notices. That’s a fine recovery plan.

Build the inventory

Now do this for the field-notes app. Make a table with one row per value: theme, draft, saved note, cached help page, attachment, login session.

For each row fill in owner, reader, lifetime, maximum size, cleanup rule, and recovery path. Leave the API column empty. The next two lessons show where the browser draws its boundaries, and then we’ll fill that column in.