なぜ必要なのか

記事と保存ボタンがある地域の便りサイトを作るとします。誰もが同じ記事を読むため、閲覧ごとにコードを動かすと運用の仕事が増えます。

どう解決するのか

記事を読む操作はファイルの経路を通ります。地域の便りの保存は別のAPIから外部ストアへ進みます。再保存しても例の読者・記事キーにより記録は1件です。次の保存を失敗させるとストアを変えず失敗を返します。処理器を再起動しても外部の記録は残ります。リセット・再読み込みは仮想ストアを含むページメモリ全体を消します。

静的ファイルと別のAPI

概念シミュレーション

静的ホスティング

公開記事を読み、地域の便りを保存します。再送も美奈 / 地域の便りを共有します。

01 · GET

ブラウザー → 公開ホスト → 記事HTML

HTML · CSS · JavaScript

02 · POST 地域の便り

ブラウザー → 別の保存API → 外部ストア → 確認応答。

実行世代: 1 · この世代の呼び出し: 0

待機

ストアもページメモリ上の模型です。再起動では残り、リセット・再読み込みで消えます。重複防止は独自のアプリ処理です。

実行境界
公開閲覧：事前生成ファイル。個人書き込み：別APIの実行と外部保存。
状態と責任
公開担当はファイル鮮度、API担当は認証とデータ復旧を担います。処理器再起動はデータ復元ではありません。

本文内の架空のデモです。リセット・再読み込みで初期状態に戻ります。

どんな考え方なのか

静的ホスティングは事前生成したHTML・CSS・JavaScriptを配信します。ブラウザーの操作は可能ですが、公開ファイルは読者の個人記録を保存しません。

個人の書き込みには生成ファイルと認証付きAPIを組み合わせます。

出典