Submit Search
Web API のすすめ
•
4 likes
•
1,938 views
Yuji Shimada
Follow
1 of 108
Download now
Downloaded 16 times
More Related Content
Web API のすすめ
1.
Web API のすすめ
~巨人にさらなる力を~ 2010/10/16 YAPC::Asia 2010 @xaicron
2.
自己紹介 名前
Yuji Shimada 嶋田裕二 仕事 DeNA CPAN XAICRON twitter @xaicron blog http://blog.livedoor.jp/xaicron/
3.
謝罪
4.
サブタイトルはただの あおり文句です
5.
今日は Web API
の話をします
6.
が、コードとかは ほとんど出てきません
7.
15時から講堂でやるやつは コードいっぱい出てきますので
見に来てね!!
8.
一口に Web API
と言っても いろいろありますね
9.
public に使えるもの Google
Map とか 認証が必要なもの twitter 内部的に使ってるもの Gmail
10.
それぞれの特徴
11.
public なもの ユーザー登録とかなしで、http(s) 経由 で直接使える どれくらいのアクセスがくるのか予想を つけ辛い
12.
認証が必要なもの ユーザー登録が必要 AccessToken とかがもらえて、それを 使ってアクセス ユーザー数からアクセスがある程度わ かる
不正なユーザーとか BAN できる
13.
内部的に使ってるもの 自分のところのページを非同期にする ために同一ドメイン内とかで Ajax 通信 ユーザーは自分ではつかわない アクセス数は、ユーザー数でわかる
14.
いろいろなものがある
15.
全体に共通して言えること
16.
速さが重要
17.
Web API は速くないと 全く使う気が起きない
18.
内部 API の場合は非同期でペー
ジを表示してるだけだから、 そんなに速くなくてもよくね?
19.
ページの描画が 10% 遅くなるだけ
でアクセス数が(ry
20.
というのは置いておいても
21.
速いに越したことはないよね!
22.
正直、Web API はもう流行ってな
いんじゃないか疑惑
23.
参考: http://yusukebe.com/archives/10/10/04/210341.html
24.
引用: “実際に「使える」Web APIは限られていることからマッシュ
アップはツンダ”
25.
その API が流行るかどうかは誰
にもわからない
26.
もしかしたら何かで流行るかもし
れないし
27.
とりあえず作ってみようぜ!
28.
高速な Web API
の実現方法
29.
既存の WAF を使わない
30.
前夜祭で @tokuhirom が言ってい
たこと
31.
徳永 「WAF は全部コードが読める
ものじゃないと使えない」
32.
Agree
33.
自分がわかっていないものを使っ
て、 問題が起こったときにn
34.
速いものを作るには、特化したも
のを作るしかない
35.
PSGI のおかげで
36.
ここ一年で Web アプリを取り巻く
環境は劇的に変わった
37.
いまはツールが充実している
38.
ore-ore WAF を作るのは難しくな
い
39.
既存の WAF だと機能過多な場合
がほとんど
40.
Web API では用件が
シンプルなので
41.
Controller をがんばる必要が
ない
42.
1:1
43.
でマッピングできる
44.
detach とか forward
みたいな 機能すら不要
45.
Web API に限ったことではないけ
ど
46.
Web App を作る上では、 Controller
と Model は完全に分離 すべき
47.
結局はちょっと高機能な dispatcher としてしか使っていない
48.
なら無駄な機能を削ぎ落としたや つを自分で書いた方がいい
49.
さらに、Web API では
View らしい View はない
50.
ほとんどすべての場合で、 JSON を返せばみんな幸せ
51.
一時期、XMLとか、なぜかYAMLと かを返すものもありました
52.
誰もうれしくない
53.
みんなで幸せになりましょう
54.
ここまでのまとめ
55.
Plack Router::Simple JSON
56.
あたりを使って、イカした ore-ore WAF を書きましょう
57.
ちょっとしたものなら本当に
すぐ書けるよ
58.
第一部 〜完〜
59.
第二部 〜実践編〜
60.
よし、たぶん高速な dispatcher は
書けるはずだお!
61.
とはいえ、dispatch にかかる時間
は通常は全体の処理の 数%程度!
62.
本当に必要なのは Model の
チューニングですね
63.
通常、ちゃんとチューニングされた
Perl コードであれば
64.
多くのボトルネックは DB 接続の
ようなものになる
65.
残念ながらそうならないケースもち
らほら
66.
どんな場合にも言えることだけど、 最も効果の出やすいチューニング
は
67.
method 呼び出しを減らすこと
68.
ただし、過剰に減らして可読性が 下がってもしょうがない
69.
Devel::NTYProf を使ってちゃんと
ボトルネックを見つける
70.
次に、オブジェクトの生成を減らす
71.
例えば、ORM を使っていて、それ がかなりのオブジェクトを生成して いるのであれば、使用をやめる
72.
ただし、生の DBI をそのまま使う
のはやはり面倒
73.
最近は
74.
DBIx::Connector -> (DBIx::DBHREsolver ->)
DBI
75.
みたいにラップして使うのがいい
気がしている
76.
もちろん、ORM でも十分に速度を
出すことも可能なので
77.
その辺りはよしなに使い分ければ
いいと思います
78.
必ず使うクラスがあり、それを毎回 new
しているような場合
79.
Object::Container のようなものに 入れて singleton
にしておくのがい い
80.
最近の Object::Container は preload
オプションとかついたので
81.
さらに使いやすくなっている
はず!
82.
run する前に 読み込んでおけば、
CoW が効くのでメモリーも抑えら れて一石二鳥
83.
ここまでのまとめ
84.
Plack Router::Simple JSON Object::Container DBIx::Connctor (DBIx::Skinny)
85.
当然、ここの部分は API の用件に よってかなりぶれがあり、一概にこ
れがいいとはいません
86.
が、一般的に、今言ったことを守っ ておけば、コード事態がボトルネッ クになる確立はだいぶ減ると思い
ます
87.
というわけで
88.
第二部 〜未完〜
89.
第三部 〜運用編〜
90.
多分、次で @fujiwara さんが 超絶詳しく説明してくれます
91.
第三部 〜期待〜
92.
だけではさすがにあれなので
93.
まぁ基本的なことですが
94.
まぁ基本的なことですが
95.
当然、必要な場所でログはとりま
しょう
96.
Log::Dispatch がデファクトなので 素直に使っておくのがいいです
97.
Syslog n
98.
ここまでのまとめ
99.
Plack Router::Simple JSON Object::Container DBIx::Connecter (DBIx:: Skinny) Log::Dispatch
100.
あたりを使って薄いものをつくれば
いいですね!
101.
それ Amon2 で出来るよ!
102.
って感じですが、あれは普通に参 考になるので一度はソースを読ん
だ方がいいです
103.
まとめ
104.
今の時代、 ore-ore WAF を書くのは
別に怖くない
105.
もちろん、なれてないうちは、イケ てないものが出来ちゃうかもしれ
ないけど、
106.
新しいものを常に追求した方が楽
しいでしょ!!
107.
:-)
108.
ご清聴ありがとうございました
Download