解決策
2014年までに、Hacker NewsのHTMLは大規模なエコシステムにとって脆弱な基盤になっていた。多くのサードパーティ製アプリやプロジェクトがサイトのマークアップをスクレイピングして記事やコメントを読み取っており、そのマークアップはモバイルフレンドリーとは程遠いものだった。Y Combinatorはフロントエンドを近代化し、より速く反復開発したいと考えていたが、HTMLを安易に変更すれば、スクレイパーに依存するすべてのツールが一度に壊れてしまう状況だった。
YCの取った策は、プレゼンテーションに手を付ける前に、データを独立した製品として公開することだった。2014年10月7日、YCはFirebase(YC S11)との提携で構築した公式Hacker News APIを発表した。これはhacker-news.firebaseio.comでサイトのコンテンツをほぼリアルタイムに配信するもので、ドキュメントとサンプルはHacker NewsのGitHubアカウントで公開された。Firebaseが標準で提供するiOS、Android、Web SDKに加えてREST APIもあったため、開発者は自らの技術スタックを再構築することなく切り替えられた。
重要なのはその順序だった。この発表により、エコシステムには3週間の猶予が与えられた。YCが目標とした10月28日は新しいレンダリングエンジンの期限であり、そのエンジンは引き続きArcで動作しつつ、よりクリーンなマークアップによってフロントエンドの反復開発を速め、ついにHacker Newsをモバイル最適化するものだった。ほとんどの用途でAPIはスクレイピングより厳密に優れていた——ほぼリアルタイムの更新、メンテナンスされたSDK、脆弱なHTMLパースが不要——ため、移行は面倒な作業ではなくアップグレードであり、サイトはユーザーを人質に取ることなくプレゼンテーションを変更できた。
この動きはエコシステムへの配慮と受け取られた。Hacker Newsのスレッドは同日、1,714ポイントと298件のコメントを集めた。APIは読み取り専用で開始され、ユーザーごとの非公開データへのOAuthアクセスは後日計画されていた。YCはこれを構築したソフトウェアチーム——kogir、dang、sctb——の功績とした。
達成したこと
データ契約を先に公開する:スクレイピングより厳密に容易な公式のほぼリアルタイムAPIを、破壊的変更の前に通知して提供する
うまくいった理由
データをプレゼンテーションから分離することで、コンテンツを消費する誰も壊すことなくフロントエンドを変更できる。
メンテナンスされたSDKを備えたFirebaseのほぼリアルタイム同期により、APIはスクレイピングより厳密に容易になり、採用は強制的な変換ではなく自発的な移行となった。
マークアップ変更前に3週間という固定の猶予期間を告知したことで、すべてのアプリに期限と早期移行の理由が与えられた。
同じArcエンジンを維持しつつ出力マークアップのみを変更したことで、APIとサイトが乖離するリスクが軽減された。
応用できること
他者がその上に構築するプラットフォームを変更するには、まずデータ契約を抽出し、それが置き換えるハックより厳密に優れたものにし、破壊的変更の日付を公表してユーザーが自ら移行できるようにする。
その後
APIは同日hacker-news.firebaseio.comで読み取り専用として稼働を開始し、公式のiOS、Android、Web SDKに加えてREST APIを備えていた。YCはユーザーごとの非公開データへのOAuthアクセスが後に続く可能性があると述べた。Hacker Newsの発表は2014年10月7日に1,714ポイントと298件のコメントを集めた。投稿は10月28日を新しいレンダリングエンジンへの切り替え目標とし、エコシステムが移行する時間を得た後にマークアップを近代化しモバイル最適化できるようにした——APIはそれ自体が目的ではなく、その変更を可能にするものとして位置づけられていた。
出典をたどる
出典
- Hacker News API Y Combinator Blog · blog.ycombinator.com ·
- Hacker News discussion: Hacker News API Hacker News · news.ycombinator.com ·