なぜ必要なのか

時々届く要求にもサーバー処理は必要です。ただし、待機し続けるプロセスを自分たちで運用したくない場面です。

どう解決するのか

記事の閲覧は処理器を呼び出します。A17の保存は別の実行で外部ストアに記録します。再保存しても例の読者・記事キーにより記録は1件です。次の保存を失敗させるとストアを変えず失敗を返します。処理器の再起動は実行状態だけを破棄し、記録を残します。リセット・再読み込みは仮想ストアを含むページメモリ全体を消します。

呼び出しの寿命と重複処理

概念シミュレーション

サーバーレス関数

公開記事を読み、A17を保存します。再送もreader-01 / A17を共有します。

01 · 管理型の実行

ブラウザー → 関数呼び出し → 記事HTML

02A · 保存の呼び出し

reader-01 / A17

02B · 再度の呼び出し

reader-01 / A17

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

↓ 同じキー → 1記録

待機

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

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

どんな考え方なのか

サーバーレス関数はイベントやリクエストに応じて管理された処理を実行します。基盤はサーバーを管理しますが、アプリの正しさは開発者の責任です。

重複処理と永続保存を設計し、前の実行環境が残ると仮定しないでください。

出典