Unitrad APIの設計
新しいAPIを設計するためにカーリルが取り組んだこと
2016/9/11 Code4Lib Japan Conference
Ryuuji Yoshimoto CC-BY
新規開発は楽しいよ
今日の話
Server
Client
Web API
React
伝統的な横断検索の再発明
API First
先にAPIを決めて、
スクレイピングエンジンとAPI
フロントエンド
それぞれ並走して開発していく
設計が品質を決める → がんばらない
どうやってAPIを設計する?
ニーズと課題
既存の横断検索システムは、
AJAXの採用で使いにくくなった
画面の頻繁な変化はストレス
RESTfulな応答はできない
横断検索先は依然として遅い
レガシーな環境・検閲に対応しなければならない
i-FILTERの影
カスタマイズのニーズに対応
APIよりうしろはさわらない
都道府県の横断検索はもはや動いていない
動くものをつくる
横断検索先が増えると遅くなる
横断検索の流れ
検索クエリ
検索結果
検索結果
検索結果
Server
Client
データストリーミングの手法
-
ポーリング
-
ロング・ポーリング
-
WebSocket
-
Socket.IO
あなたにWebSocketは必要ないかも
http://postd.cc/you-might-not-need-a-websocket/
自分が解決しようとしている問題をメッセージングパターンの観点から考え、データ同期についても考慮してください。そうすれば、シンプルで、より適切なHTTPベースの手法が見つかるでしょう。
ポーリング+α
-
変化があるまでは待機(ロング・ポーリング)
-
タイムアウト時間を指定
ポーリングの最適化はクライアントに任せる
転送量の削減
カーリルローカル → ポーリング 毎回全件取得
横断検索先の増加すると遅くなる
スマホでつらい
効率的な差分転送の検討
JSON-delta: a diff/patch pair
for JSON-serialized data structures
-
http://json-delta.readthedocs.io/en/latest/
-
JSONの差分データを生成するライブラリ
- PythonやJavascriptでの実装がある
- 追加/変更/削除
横断検索の流れ
検索クエリ
初期データ
差分
差分
Server
Client
JSON-delta
実装したらうまくいかない!
100件のデータに10件増える… 数ミリ秒で差分生成
1000件のデータに100件増える... 10ミリ秒以内で差分生成
10000件のデータに1000件増える .... 3000ミリ秒以内で差分生成
データが増えると差分生成コストが高くなる傾向
マージはわりと速い
心地よい制約
-
差分データの生成は重い
→ 増分ならどうか -
横断検索データは減ることはない
そもそも読んでいるうちに動くのはストレス -
書誌データに特化した、
データが増加・または変化することしか想定しない
差分フォーマットの開発
差分生成
(Python)
def diffs(new, old):
ret = {
'insert': [],
'update': []
}
for line, x in enumerate(new):
if line < len(old):
_tmp = {}
for k, v in x.items():
if isinstance(v, unicode):
if old[line][k] != v:
_tmp[k] = v
elif isinstance(v, list):
if old[line][k] != v:
_tmp[k] = list(set(v) - set(old[line][k]))
_tmp[k].sort()
elif isinstance(v, dict):
diff = set(v.keys()) - set(old[line][k].keys())
if len(diff) > 0:
_tmp[k] = {}
for key in diff:
_tmp[k][key] = v[key]
if len(_tmp.keys()) > 0:
_tmp['_idx'] = line
ret['update'].append(_tmp)
else:
ret['insert'].append(x)
return ret
マージ
(ES2016)
Array.prototype.push.apply(this.data.books, data.books_diff.insert);
for (key in data) {
if (data.hasOwnProperty(key)) {
if (key !== 'books_diff') {
this.data[key] = data[key];
}
}
}
ref = data.books_diff.update;
for (i = 0, len = ref.length; i < len; i++) {
d = ref[i];
for (key in d) {
if (d.hasOwnProperty(key)) {
if (key !== '_idx') {
if (Array.isArray(d[key]) === true) {
Array.prototype.push.apply(this.data.books[d._idx][key], d[key]);
} else if (d[key] instanceof Object) {
for (k in d[key]) {
this.data.books[d._idx][key][k] = d[key][k];
}
} else {
this.data.books[d._idx][key] = d[key];
}
}
}
}
ちょっとした制約で高速化
100件のデータに10件増える… 1ミリ秒以内で差分生成
1000件のデータに100件増える... 1ミリ秒以内で差分生成
10000件のデータに1000件増える .... 5ミリ秒以内で差分生成
コストバランスがとても重要
サーバー側の実装
- すべてのバージョンのデータをメモリ上に保持
- クライアントが持っているデータのバージョンと
サーバーが持っているバージョンの差分を返す
→ サーバー側はステートレス
- HTTP/2
- GZIP圧縮
→ HTTP層の様々な技術に乗ってさらに高速に
横断検索に見られる無意味なチェックボックス群
押すとチェックが外れるんじゃなくてリンクしちゃう
横断検索先の選択など仕様に入れるものか
クライアントの実装で勝手にやってください
API設計はサービスのゆるい運用ポリシーでもある
それは制約の設定である
なにをして、なにをしないのか
結局、全部作ったけど、
それほど大変ではなかった。
メモリは潤沢に、そしてオーバーコミット
エラーになったら潔く死ぬ
自動リカバリー
頑張らなくていいよ。
Special Thanks
Unitrad APIの設計
By Ryuuji Yoshimoto
Unitrad APIの設計
- 7,552