公開まで4クリック。入り口から完了まで30秒。無料プランではアカウントごとにサーバーを使う公開アプリは1つ。新しいサブドメインが最初のリクエストを処理する際に0.5秒の追加レイテンシがあるが、それ以降は発生しない。3つの数字は豆知識のようなもので、うなずいて次の章までには忘れてしまう類のものだ。しかし「1つ」という数字は、実際に働き方を変える数字なので、この章の大半をそこに費やしたい。
なぜ上限が「0でも無制限でもなく1」なのか
フロントエンドを無料で公開できるノーコードツールの多くは、サーバーを使うアプリには一切対応していないか、あまりにも厳しく制限しているため「無料」は名ばかりになっている。ここでは、アカウント機能・データベース・マルチプレイヤー状態を持つビルドも、静的ページとまったく同じ公開ボタンから公開でき、サーバー側もその1つの操作の一部としてホスティング・管理される——別途データベースをプロビジョニングする必要もなく、環境変数を配線する必要もなく、プレビューではログインが動くのに本番では500エラーになる(バックエンドが実際にはデプロイされていなかった)ことを3日後に発見する、ということもない。これは本物であり、だからこそ人々は上限に達したときに驚くのだ——それまではすべてが無制限に感じられていたから。
実際は違う。無料プランでは、サーバーを使う公開アプリを同時に1つだけ持てる。静的なビルドはこの上限にカウントされない——マーケティングページやポートフォリオサイトは好きなだけ公開できる。しかし、独自のデータベースや常駐プロセスを必要とする2つ目のビルドは順番を待つ必要があり、完全にビルド済みでプレビューはできるが、URLで公開されている状態にはならない。同じ週に3つのSaaSアイデアを試作しているなら、実際のコンピュートを占有できるのは1つだけで、残りの2つはアドレスのない完成品ということになる。この線引きは妥当な場所に引かれていると思う——静的なバンドルをエッジで配信するコストはプラットフォームにとってほぼゼロだが、稼働中のサーバープロセスはそうではないからだ。ただしこれは、どのアイデアがそのスロットに値するかという判断を、公開ボタンを押す前に——2つ同時に公開している状態に愛着を持ってしまう前に——下す必要があることを意味する。
参考までに、その4クリックとは
- ビルドのカードで公開を選ぶ。
- スラッグを選ぶ—— ユーザー名 の中の
yourname.buildmidas.com。既に使われているスラッグには代替案が提案される。 - 確認する。
- カードからURLをコピーするか、後で公開済みページで見つける。
DNSも、外部アカウントも、伝播待ちも不要だ。そしてあの0.5秒について——これはキューでも「24時間後に確認してください」的な遅延でもなく、単なる通常のCDNキャッシュのウォームアップだ。新しいサブドメインへの最初の訪問者は、最寄りのエッジノードがアセットバンドルを取得する間、わずかな追加レイテンシに気づくかもしれない。2人目以降の訪問者は全員キャッシュから配信される。実際にはまず気づかない——公開してリンクをタップすれば、すでに即座に感じられるはずだ。これに触れているのは、読み込み時間のスクリーンショットを仕事にしているような人が、いずれ1回目と10回目のリクエストがなぜ同じでないのかを尋ねてくるだろうからで、これで理由がわかったはずだ。
立ち止まって考える価値がある唯一の判断、それがスラッグだ
このフローの他の部分はすべて機械的だが、スラッグだけは人間が声に出して言ったり暗記して入力したりする必要がある部分なので、一呼吸置いて考える価値がある。「demo-v2-final-final」は内部テストには問題ないが、クライアントに送るには良くない。確定する前にURLを自分で発音してみてほしい—— riverside-cafe.buildmidas.com はすっきり読めるが、 riverside-cafe-mvp2.buildmidas.com はそうならない。短くありふれた単語は、長く運営されているプラットフォームではすぐに埋まってしまうため、既に使われているスラッグはエラーではなく候補の提案になる。それを受け入れるか却下するかは自由だが、意図的に決めてほしい——デモの最中にすぐにリンクが必要になって、ボックスが提示したものをそのまま掴み、直す自然な機会が二度と来ないまま何ヶ月も不格好な名前で運用している人を見てきた。
再公開しても、あなたが指示するまで公開中のサイトには影響しない
早いうちに肝に銘じておく価値のある事実がある。公開済みのビルドを編集しても、公開中のサイトは動かない。何かを壊してもいいし、思い切ったレイアウト変更を試してもいいし、1週間かけて反復してもいい——クライアントが既にブックマークしているURLは、あなたが意図的に再度公開するまで、最後に公開したものを配信し続ける。
それがロールバックのすべてであり、地味であることこそが良い点だ。バージョン6でバグが出荷される——フォームがひっそりと送信されなくなる——そのときrevertコマンドやサポートチケットに頼る必要はない。バージョン履歴を開き、バージョン5を見つけ、それを再公開する。同じボタン、古い成果物、公開中のURLは即座に元に戻る。そのあとプレッシャーゼロでバージョン6を修正できる。作業中も本番は壊れていないからだ。このコストはリリースごとにワンクリック増えることだが、それは編集が自動的に反映されると思い込まず、実際に公開することを覚えておく必要があるためだ。すべての保存が即公開になるツールと比べれば——デモでは見栄えがいいが、実運用に入って3週間もすると厳しくなる——このワンクリックは常に払う価値のある代償だ。
公開停止とはURLが解決しなくなることであって、「一覧に載らなくなる」ことではない
多くのプラットフォームでは「公開停止」は、URL自体はひっそり配信され続けたまま、ギャラリーページから非表示にすることを意味する。ここでは違う——アドレスそのものが完全に無効になる。キャッシュされたページも、プレースホルダーも、何も解決されない。ビルド自体はすべてのバージョンとともに残り、後で再公開すれば同じスラッグが以前と全く同じ状態で戻ってくる。これを使ったのは、ありふれた理由(クライアントとの契約が終了し、誰も古いロゴを公開リンクに漂わせておきたくない)と、そうでない理由(あるビルドが本来漏らしてはいけないものを漏らし、チケットを提出してホスティングプロバイダーに対応してもらう時間ではなく、ボタンをクリックする時間でオフラインにする必要があった)の両方だ。どちらの状況も同じ保証を求めていて、どちらも得られる。
混同しないほうがいいことがもう一つある。公開はリンクを持つ誰にとってもURLを有効にすることだが、それが発見可能かどうか——公開一覧に載るか、時にはShowcaseに掲載されるか——はまったく別のトグルだ。正当な公開サイトの多くは、永遠にリンク限定のままであるべきで、公開一覧掲載を選んだビルドも、その裏側は同じ履歴と同じ公開停止ボタンを持つ、ごく普通の公開サイトにすぎない。
