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 덕분에 개발자들은 스택을 다시 구축하지 않고도 전환할 수 있었다.

핵심은 순서였다. 이 발표는 YC가 목표로 한 10월 28일의 새 렌더링 엔진 도입일 전까지 생태계에 3주간의 준비 기간을 주었다. 새 엔진은 여전히 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는 그 자체가 목적이 아니라 그 변경을 가능하게 하는 수단으로 제시되었다.

근거 확인하기

출처

  1. Hacker News API Y Combinator Blog · blog.ycombinator.com ·
  2. Hacker News discussion: Hacker News API Hacker News · news.ycombinator.com ·