The Cave Project

課題デザインでは、スクロールに合わせて前後に再生される動画クリップが求められていました。ところが、スクロールのたびに動画要素のシークを行うと、ブラウザーに負荷がかかりすぎます。トラックパッドでもマウスホイールでもひどくカクつき、意図した演出ではなく、壊れているように見えてしまいます。

解決策動画のシークは完全にやめました。クリップをあらかじめ99枚のWebPフレームに書き出し、スクロールのたびに画像を1枚差し替える方式にしています。結果は即座に反応し、どのデバイスでも完全に滑らかです。

課題公開フォームには、ボットの送信が集まります。CAPTCHAを置けば、本当に申し込みたい人の体験を損ないます。これはリトリートの参加申込であって、メルマガの登録ではありません。その場面で手間をかけさせると、団体についての誤った印象を与えてしまいます。

解決策2つの公開フォームに、隠しフィールド「website」を置きました。人の目には見えませんが、ボットはすべての欄を埋めるため、バックエンドはこの欄に値が入っている送信を拒否します。チェックはサーバー側で動くので、APIを直接呼び出しても回避できません。

課題APIを呼び出せば誰でも参加申込のレコードを作成できるため、悪意のある第三者が、リクエストの内容を細工するだけで、最初から「受け入れ決定」にした申込を送れてしまいます。

解決策リクエストの内容にかかわらず、バックエンドが新しい参加申込のステータスを必ず「新規」に固定します。公開APIを通って、自分の申込を自分で昇格させる経路はありません。

課題チェックされていないチェックボックスは何も送信されず、空のファイル入力は0バイトのファイルを送信し、空の数値欄は空文字列を送信し、選択をすべて解除した複数選択は項目を1つも送信しません。そのどれもが、編集者の意図とは違う形でデータベースに解釈されます。

解決策サーバーアクションの正規化レイヤーが、レコードを書き込む前に、それぞれのエッジケースをデータベースが期待する形に変換します。管理画面がデータを壊れた状態にすることはありません。

課題composeネットワークの内側では、Next.jsコンテナはサービス名でPocketBaseに到達できます。しかし、訪問者のブラウザーはそのアドレスを使えません。両者を混ぜると、サーバーレンダリングか、本番環境のすべての画像とファイルのリンクのどちらかが壊れます。

解決策初日から、2つのURLをコードベース全体で明確に分けました。Docker内のサーバーサイドレンダリングにはPB_URL_INTERNAL、ブラウザーが直接読み込むものにはNEXT_PUBLIC_PB_URLを使います。