SPDY、HTTP2.0…Webのリアルタイム性を実現する上で参照すべき7つのソース【2014年前半のインプットlog－山本裕介】

2014/07/28公開

業界で名の知れたプログラマーは、今年の上半期に何を学んでいたのか？　「同業者が役に立ったものは、自分にも役に立つはず」という仮説を基に、彼らの学びlogから、2014年上半期の流れを振り返り、今後の動向を予想してみよう！

プロフィール

株式会社サムライズム
山本裕介氏（@yusuke）

Twitter APIのデファクトスタンダードライブラリ『Twitter4J』の開発者。国内外のITベンダーを経て、2011年9月よりTwitter社のデベロッパーアドボケイトを務める。2012年9月に退職・独立し、現職に。現在はTwitter API連携支援サービスの提供や、各種開発ツールの販売代行を行う

サーバ側からもプッシュが可能な次世代通信プロトコル

山本氏がTwitterとの連携サービスの設計を行った、クラウド会計サービス弥生の新サービス『YAYOI SMART CONNECT』。Twitterのつぶやきからも記帳が可能になる

Twitter APIのJava用ライブラリ『Twitter4J』の開発者として知られる山本裕介氏。

2012年にフリーランス転向後は、JetBrains社をはじめとする自ら愛用する海外ソフトウエア製品の代理店事業を手掛けるかたわら、クラウド会計の弥生のTwitter連携サービスの設計や、Evernote API、PayPal APIなど、APIの専門家としてのキャリアを活かした活動を精力的に行っている。

2013年にフリーランスエンジニアとしてはやや異色の代理店業を軌道に乗せ、2014年の上半期は再度、エンジニアとしての活動に注力し始めているという山本氏。特に注目して追っていたのが、

【1】SPDY、HTTP2.0、WebSocketといった最新通信プロトコル

の動向だ。

「LINEをはじめとしたコミュニケーションツールやモバイルデバイスの通知は、リアルタイム性が肝になりますよね？ Webでも今、リアルタイム性の重要度がどんどん増しています」

Webの進化に伴い、従来のHTTPは特に通信スピードの面で問題が生じてきた。こうした問題の解決策としてGoogleが提案したのが、次世代プロトコルのSPDYだ。従来の通信がリクエスト－レスポンス型だったのに対し、SPDYを使えば、サーバ側からプッシュすることが可能になる。

「今後はこれを応用したサービスが出てくるでしょうね」と語る山本氏は、SPDYを採用したサーバJettyを自社サイトの注文フォームに利用するなどして、いち早く次世代プロトコルに触れてきた。

APIに関しても、リクエスト－レスポンス型プロトコルであるHTTPを前提とした現行のREST APIに加えて、HTTP2.0やWebSocketを活用したプッシュ型でリアルタイム性の強いAPIが出てくるとみている。

「Twitterもリアルタイム性が重要なサービスですが、当時はこうした技術がなかったため、HTTP1.1ベースでやや強引にストリーミングAPIというリアルタイムなAPIアーキテクチャを構成していました。今後はHTTP2.0やWebSocketの普及で、プロトコルレイヤーのインピーダンスマッチが進んでいくはず。Web APIがリアルタイムAPIという次のステージに進むでしょうね」

山本氏は、上半期に注力してインプットした技術としてほかに、

【2】アイデンティティAPI標準技術「OpenID Connect」

【3】JavaScriptの拡張言語として本命視している「TypeScript」

の2つを挙げた。同氏がこれらの情報を収集するのに実際に活用していたソースは、以下のようなものだ。

山本裕介氏が参考にした情報ソース

SPDYをかなり早い段階からサポートしているPure Javaサーバ『Jetty』。山本氏は自社の受発注システムに導入することで、SPDYに関する知見を蓄積した

【1】SPDY、HTTP2.0関連

HTTP2.0は仕様を眺めた程度で、まだ手をつけられていませんが、前述した通り、その基盤仕様であるSPDYを自社のプロダクション環境に取り入れています。

具体的には、SPDYをかなり早い段階からサポートしているPure JavaサーバであるJettyで受発注システムを構築しました。

■Jetty
http://www.eclipse.org/jetty/documentation/current/spdy.html

■HTTP2.0の仕様（GitHub）
https://github.com/http2/http2-spec

リアルタイムなAPIになると、つなぎっぱなしでどんどんレスポンスが来るわけなので、設計がだいぶ変わってくるはずです。

今後、試行錯誤を経て、ベストプラクティスが形成されていくでしょう。

【2】OpenID Connect関連

さまざまな認証プロトコルをサポートするgluuというオープンソースの製品を通じて学びました。それからOpenID TechNight Vol.11というイベントにも参加しました。

■gluu
http://www.gluu.org/resources/documents/standards/openid-connect/

■OpenID TechNight Vol. 11（※イベント当日の模様がUstで載っている）
http://openid.doorkeeper.jp/events/9058

■OpenID TechNight Vol. 11のSlideShare

OpenID Connect
101 @ OpenID TechNight vol.11 from Nov
Matake

従来のOpenIDだと、認証はできても、そこから何の情報も引っ張ってくることができませんでした。OpenID Connectはログインした時からメールアドレスが取得でき、入力の手間が減るのでユーザーの離脱を防げるなどの効果があります。

また、これまでサービスごとに異なっていた認証を、同じ仕様でつなぐことができるようになります。

【3】TypeScript関連

開発環境として自社サイトで販売しているWebStormを使いつつ、TypeScriptを熱心に追っているわかめさんの本で勉強しました。

■WebStormについて
http://samuraism.com/products/jetbrains/webstorm

■書籍『TypeScriptリファレンス Ver.1.0対応』
http://www.amazon.co.jp/dp/484433588X

数あるaltJSの中で、個人的に本命視しているのがTypeScriptです。

型安全な言語であるため、メンテナンスがしやすいし、ツールのサポートを受けやすいです。TypeScriptは、コンパイルしたJavaScriptのソースがシンプルなのも特徴で、万が一TypeScriptが廃れてしまった場合も、コンパイル済みのJSコード資産を活かすことができるのも良いです。流行りものというのは、どれだけいいものでも、みんなが使わなければ廃れてしまうので。