12画面の組み立てと配信

12-1　利用者がURLを開くと、要求は利用者に近い場所に置かれた実行環境に届く。 1台の大きなサーバーではなく、世界中に散らばった小さな実行の場が、要求ごとに割り当てられる。

技術的には　エッジ実行環境（利用者の近くで動く、 起動が速く軽い実行の仕組み）。1つの要求ごとに独立して立ち上がり、終われば片付けられる。 これが8番の「順番待ちの鍵」の効き方を決めている―― 鍵はその実行環境のメモリの中にしか無いので、 別の実行環境に割り当てられた同時操作には効かない。 同じ理由で、2番の30秒の控えや6番の6時間の控えも「運が良ければ効く」程度のものになる。

12-2　まず、この環境に設定されているNotionの接続情報を、 プログラムが読める場所へ写し替える。

技術的には　写すのは4つ：接続用のトークンと、 3つのデータベースの識別子。要求のたびに毎回実行される（1回だけではない）。 この実行環境では設定値が渡され方の都合で環境変数に自動で入らないため、手で橋渡ししている。 写す前に値があるかを確認するので、設定されていない項目は上書きされない。 この4行が無いと、Notionを呼ぶ処理はすべて 503 で止まる。

12-3　画像を小さく作り直すための専用の入口だけ、先に横取りする。

技術的には　/_vinext/image というパスへの要求だけを 別扱いにし、決められた幅の一覧の中でのみ画像を変換して返す。 ただしこのアプリは、この仕組みを使っていない。 添付画像の表示も、原典プレビューの代表画像も、素の画像表示で書かれている （そのことを示す注記がコードに残っている）。 土台の雛形に最初から付いていた機能が、使われないまま残っている形。

12-4　それ以外の要求は、3つの画面のどれか、または12本のAPIのどれかへ振り分けられる。

技術的には　振り分けはフォルダの構成がそのままURLになる方式。 画面は3つ：/（受信箱）、/map（全体マップ）、/lab/recompose（再構成ラボ）。 3つとも「毎回サーバーで作り直す」指定が付いている。 なおAPIのほうは、ここを通ったあと 1番の門に入る。

12-5　画面の題名・説明文・共有したときに出るカードの絵を組み立てる。 このとき、いま自分がどのアドレスで呼ばれたかを見て決める。

技術的には　要求ヘッダの x-forwarded-host（間に立つ機器が「本来の宛先はここです」と伝えるための項目）と x-forwarded-proto を読んで、絶対URLの基準を組み立てる。 どちらも無ければ host を使い、それも無ければ手元の開発用アドレスにする。 つまり、置き場所を変えてもOGPのURLが自動で追従する。 題名は「Zettelkasten Inbox」、説明は 「Notionを正本に、Literature NoteをTagからABC Noteへ迷わず知識化する受信箱。」で固定。 全体マップの画面だけは別の題名を持つが、こちらは要求に関係なく固定値。

12-6　枠だけのHTMLが返る。受信箱の一覧も、Tagも、ABC Noteも、まだ1件も入っていない。

技術的には　返るのは、画面の外枠と読み込み中の表示だけを含むHTML。 中身を担当する部分は「ブラウザ側で動く」印が付いていて、 サーバーでは実行されない。だから HTMLの中を覗いても、Notionのデータは1文字も入っていない。 これは検索や共有に対しては不利（外から中身が見えない）だが、 このアプリは個人用で外に見せる必要が無いので問題にならない。

12-7　HTMLを受け取ったブラウザは、続けて文字（フォント）・見た目の指定・ 画面を動かす部品を取りに行く。

技術的には　文字は外部の配信元から読み込まない。 必要な字形だけを取り出したファイルが、このアプリと同じ置き場所から配られる。 外部の配信元に取りに行くと、電波の悪い所で文字だけ遅れて表示される（一瞬別の字体で見える）ので、 それを避けている。画面の部品は用途ごとに分かれていて、 受信箱の部品・全体マップの部品・再構成ラボの部品は別々。 受信箱しか開かない人は、全体マップの部品を受け取らずに済む。

12-8　これらの部品には「1年間そのまま保存してよい」という印が付いている。 2回目からは通信すら起きない。

技術的には　Cache-Control: public, max-age=31536000, immutable。 31,536,000秒＝365日。immutable は「中身は絶対に変わらないので、 確認の問い合わせすら不要」という意味。 こんな強い指定ができるのは、ファイル名に中身から計算した文字列が入っているから―― 中身が変われば名前も変わるので、古いものを使い回す事故が起きない。 HTMLのほうには一切この印を付けない。 部品は永久保存、画面は毎回取り直し、という使い分けになっている。

12-9　部品が揃うと画面が動き出し、そこで初めて1〜11のAPIが呼ばれる。 ここから先が、これまでの11ブロックの話になる。

技術的には　受信箱なら 2番（一覧の取得）、 全体マップなら 10番、再構成ラボなら 11番が最初に呼ばれる。 画面上部のナビ（受信箱／全体マップ）は、部分的な切り替えではなく <a href> によるページ全体の読み込み直しで移動する。 つまり切り替えるたびに 12-1 からやり直す。 コードにはその理由が「配信環境で各画面が確実に初期化されるようにするため」と 書き残されている。速さより確実さを取った判断が、理由付きで残されている珍しい箇所。