Why: the goal or problem

Imagine a community newsletter with articles and a Save button. Reads return identical files; running code per read adds work.

How: work toward a solution

Read article follows the file path. Save Community Newsletter follows a separate API path into an external store. Repeat Save keeps one record under the example’s reader/article key. Fail next save returns failure without changing storage. Restart handler keeps the record because storage is outside the handler. Reset or reload clears this page-memory simulation, including its illustrated store.

Static files and a separate API

Concept simulation

Static hosting

Read the public article, then save Community Newsletter. Repeated requests share Mina / Community Newsletter.

01 · GET

Browser → public host → article HTML

HTML · CSS · JavaScript

02 · POST Community Newsletter

Browser → separate Save API → external store → acknowledged.

Execution generation: 1 · Calls in this generation: 0

Waiting

The store is simulated in page memory. Restart preserves it; Reset or reload clears it. Deduplication is authored application logic.

Execution boundary
Public reads: prebuilt files. Private writes: separate API execution and external storage.
State and responsibility
Publisher owns file freshness; API owner owns authentication and data recovery. Handler restart is not a data restore.

A fictional demo within this article. Reset or reload restores its initial state.

What: the concept

Static hosting delivers prebuilt HTML, CSS, and JavaScript. Browser interaction remains possible, but public files do not store private reader records.

Pair generated files with an authenticated API for personal writes.

Source