ケーススタディ4: 手をかけずに済むコンテンツサイト

アイデア

ある趣味人が、Markdownノートのフォルダ — 何年もの旅行で書いたレストランレビュー — を、ログインするCMSも月額の請求も無しに、検索可能な公開サイトに変えたいと考えていました。ノートを追加して、プッシュして、おしまい。

仕様

Markdownファイルのフォルダから生成される静的サイト。レビュー1件
につき1ファイル(フロントマターに title, city, rating, body)。
レビューを新しい順に並べるホームページ、レビューごとのページ、
そして city か name でのクライアントサイド検索を作って。
データベース無し、ログイン無し、私が手で実行するビルド手順無し。
新しい .md ファイルをプッシュしたら、それが公開されること。

隠れた要件は最後の一文にあります。「私が手で実行するビルド手順無し」は、この仕様が出力そのものだけでなく、本当はワークフローに関するものだということを意味します — そしてワークフロー要件は、名前を付けなければAIが飛ばす部類です。動いているアプリには現れないからです。

スタック

ビルド時にMarkdownを読む静的サイトジェネレーターを、Gitトリガーのビルドを備えたCDNホストにデプロイしました。リポジトリにプッシュすると、ホストが再ビルドし、CDNが配信します。検索はビルド時に生成される小さなJSONインデックス上でクライアントサイドに行うので、サーバーも無くクエリのコストも無い — レビュー数百件では妥当なトレードオフであり、見つけたものではなく私たちが名前を付けた意図的な選択です。

鍵となったプロンプト

私たちはどんなUIよりも先に、AIをデータの形に錨で固定しました。

/reviews 内のすべての .md ファイルを読む静的サイトをセットアップ
して。各ファイルのフロントマターには title, city, rating(1-5),
date がある。ビルド時にそれらをすべてパースして並んだリスト
(新しい順)にし、生成して: それらを並べるホームページと、
/reviews/<slug> にレビューごとのページ。どんなスタイリングよりも
先に、データ読み込みのコードを見せて。

「どんなスタイリングよりも先に」は意図的なレバーです。一度に全部を頼めば、信用できないデータに配線された美しいページが手に入ります。データ層を先に頼めば、たった1ピクセルが注意を逸らす前に土台を検証できます。それから、安く保つよう範囲を絞った検索です。

ビルド時に、すべてのレビューについて {title, city, slug} を持つ
search.json を生成して。ホームページに検索ボックスを追加し、
見えているリストを city か title のマッチでクライアントサイドに
絞り込む — ネットワーク呼び出し無しで、すでに読み込まれた
インデックスをただ絞り込むだけ。JSは50行未満に収める。

障害

ビルドはローカルでは通りましたが、デプロイされたサイトは個々のレビューページすべてで404を返しました。ホームページは動き、レビューごとのページは動きませんでした。私たちは理屈をこねるより、症状と設定を貼り付けました。

ホームページはライブで動くのに、/reviews/<slug> のページは
ローカルのdevでは動くのに本番では全部404になる。これが私の
ビルド出力ディレクトリの一覧と、ホストのデプロイ設定: [貼り付け]。
なぜローカルのdevはこれらのページを配信するのに本番はしない?

AIはそれを、devサーバーのルーティング(パスを動的に解決する)と
静的ホスティング(物理的に存在するファイルだけを配信する)の
違いに突き止めました。ビルドがレビューページを間違った出力
フォルダに生成していたので、それらは一度もアップロードされなかった
のです — devは、本番にはできないルートをルーターが偽装することで
バグを隠していました。

私たちは出力ディレクトリをホストが実際にデプロイするものに合わせ、ページが現れ、ローンチのチェックリストに一行を加えました。ホームページだけでなく、ライブサイトでディープリンクをクリックすること。より広い教訓は、「devで動く」と「デプロイして動く」は別の主張であり、静的エクスポートこそその2つが分かれる地点だということです — devサーバーは、実際のファイルベースのホスティングが決してそうでない仕方で、ルートに対して寛容なのです。

ローンチ

私たちは本物のレビューを1つプッシュし、ホストが再ビルドするのを見守り、その特定のレビューへのディープリンクをライブのドメインで読み込みました — devが嘘をついていたまさにそのケースです。それからインデックスがそれを拾ったか確認するため、その city を検索しました。次のレビューを追加するのは一行のコミットでした。それがすべての要点でした。ローンチは一瞬の出来事ではなく、私たち抜きで動き続けるワークフローだったのです。