YAPC::Fukuoka 2017 HAKATA

Web API の未来について GraphQL のことをお話ししました。

Transcript

1. { talk(title: "Web API の未来") { title event speaker keywords } }
2. { "talk": { "title": "Web API の未来", "event": "YAPC::Fukuoka 2017", "speaker": "Takatsugu Shigeta", "keywords": ["API", "GraphQL"] } }
3. { speaker(name: "Shigeta") { name elsewhere work } }
4. { "speaker": { "name": "シゲタタカツグ", "elsewhere": { "PAUSE": "SHIGETA", "Twitter": "@comewalk", "GitHub": "@comewalk", "Blog": "https://blog.comewalk.com/" }, "work": { "at": "Six Apart Ltd.", "information": "We are hiring!" } } }
5. Web API の未来 について考える
6. https://trends.google.co.jp/trends/explore?date=all&q=Web%20API,REST%20API
7. Web API の歴史を遡る ※諸説あります Photo by https://flic.kr/p/8iSBWB
8. REST + JSON • 2010年年頃から現在の主流 • ブラウザとの親和性
9. REST + XML • 2005年年 Ajax の登場 • 2005年年 REST ムーブメント • ブラウザの時代へ
10. XML-RPC • 1999年年頃 仕様策定 • RPC を HTTP の上で⾏行行うプロトコルのひとつ • Firewall を越えてインターネットワイドに • 2001年年頃 SOAP 誕⽣生
11. RPC • Remote Procedure Call • ネットワーク越しに関数呼び出しするという意味で は Web API の原点にある（と思う） • 独⾃自ポートを開けるなど Firewall を越える課題など
12. RPC XML-RPC REST + XML REST + JSON 2000年年 2005年年 2010年年 2015年年
13. サーバサイド • 独⾃自サーバから Web サーバへ • インターナルからインターネットへ • 独⾃自フォーマットから JSON へ
14. クライアントサイド • 専⽤用プログラムからブラウザへ • C⾔言語などから JavaScript へ • 単純なマークアップ（HTML）から SPA へ
15. REST の功罪 Photo by https://flic.kr/p/ogSP8K
16. REST によって HTTP の表現だけでリソースごとのシ ンプルなアクセスが提供できた⼀一⽅方で、⼤大量量のリソー スを抱えるサービスは多くのエンドポイントを持つた め、複数リソースからデータの取得が必要な場合に複 数回の API コールを余儀なくされる結果、主にクラ イアントサイドのオーバヘッドが増え、⾮非同期処理理や ローカルキャッシュなどの技術を駆使することによる 実装の複雑化を増幅した結果、サーバサイド以上にク ライアントサイドは⾼高度な技術を要求されることとなっ た。
17. http://graphql.org/
18. – GraphQL Tokyo https://www.meetup.com/ja-JP/GraphQL-Tokyo/events/239924595/ “Meetup #1 Thinking in GraphQL”
19. – POSTD http://postd.cc/api-paradigms/ “GraphQLはWeb APIの次のフロンティアか？”
20. GraphQL • 2012年年 Facebook 開発 • 2015年年 Working Draft 公開 • http://graphql.org/
21. • プロトコル • アーキテクチャ • ソフトウェア • クエリー⾔言語 GraphQL
22. type Talk { title: String event: String speaker: String keywords: [String] } type Query { talk(title: String): Talk }
23. type Talk { title: String! event: String! speaker: String! keywords: [String] } type Root { talk(title: String): Talk } schema { query: Root }
24. { talk(title: "Web API の未来") { title event speaker keywords } }
25. { "data": { "talk": { "title": "Web API の未来", "event": "YAPC::Fukuoka 2017", "speaker": "Takatsugu Shigeta", "keywords": ["API", "GraphQL"] } } }
26. Request { talk(title: "Foo") { title event speaker keywords } } Response { "data": { "talk": { "title": "Foo", "event": "YAPC::Fukuo "speaker": "Mike Jone "keywords": ["Alice", } } }
27. $ curl -s\ > -H 'Content-Type: application/json'\ > -H 'Authorization: Bearer ...YOUR TOKEN…'\ > -d '{ "query": "{ viewer { login } }" }'\ > https://api.github.com/graphql | jq . { "data": { "viewer": { "login": "comewalk" } } } JSON でリクエスト
28. struct Talk { char* title; char* event; char* speaker; char* keywords; }; struct Talk t; talk("Foo", &t); printf("%s", t->title); // "Foo" RPC の時代に似てますね！ （20年年以上のあいだ、形を変えてもやっていることは同じ）
29. 操作（Operations） • Query （データ問い合わせ） • Mutation （データ操作） • Subscription （データ更更新通知）
30. Query （データ問い合わせ） type UserQuery { search(name: String): [User] } schema { query: UserQuery } type Query { search(name: String): [User] }
31. Query （データ問い合わせ） Request query { search(name: "Foo") { name email } } Response { "data": { [{ "name": "Bob", "email": "bob@example.com" }] } }
32. Mutation （データ操作） type UserMutation { update(name: String): Int } schema { muration: UserMutation } type Mutation { update(name: String): Int }
33. Mutation （データ操作） Request mutation { update(name: "Foo") { result } } Response { "data": { 1 } }
34. Subscription （データ更更新通知）
35. –GitHub https://developer.github.com/early-access/graphql/ https://developer.github.com/v4/ “The ability to define and specify precisely the data you want for your integration is a powerful advantage over the existing REST endpoints. ” 事例例: GitHub
36. –Facebook https://facebook.github.io/relay/ “A JavaScript framework for building data- driven React applications” 事例例: Relay
37. クライアント アプリケーション サーバ • 構⽂文解析 • 結果返却 GraphQL
38. クライアント アプリケーション サーバ GraphQL Proxy • 構⽂文解析 • データ収集 • 結果返却 GraphQL REST
39. クライアント アプリケーション サーバ GraphQL Proxy • 構⽂文解析 • データ収集 • 結果返却 GraphQL REST 外部Webサービス DBサーバ
40. –Netflix http://netflix.github.io/falcor/starter/what-is-falcor.html “Falcor is middleware.〜 Falcor can be used to optimize communication between the layers of a new or existing application.” Falcor
41. https://netflix.github.io/falcor/documentation/network-diagram.png
42. Web API の未来 • Facebook, Netflix, GitHub など⼤大⼿手が動き始めた • GitHub API は v3 が REST、v4 が GraphQL • REST が GraphQL に置き換わることは当⾯面ないと思う • だけど（ほぼ）5年年周期で変わるトレンドのはじまり • フォーマットは JSON • REST 原理理主義は卒業してもいい • きっと次に⽣生まれる何かが Web API の未来を担う
43. "phrase": { "text": "One more thing..." }
44. "CPAN": { "module": { "name": "GraphQL", "author": "SHIGETA" } }
45. "CPAN": { "module": { "name": "GraphQL", "author": "SHIGETA" => "ETJ" } }
46. "CPAN": { "module": { "name": "GraphQL::Tiny", "author": "SHIGETA" } }
47. #!/usr/bin/perl use common::sense; use GraphQL::Tiny; use JSON; my $result = GraphQL::Tiny->new( schema => <<'SCHEMA', type Query { hello: String bye: String } SCHEMA source => '{ hello }', root_value => { hello => sub { return 'Fukuoka'; } }, )->run(); say JSON->new->encode($result); $ perl hello.pl { "data": { "hello": "Fukuoka" } }
48. "links":[{ "rel": "self", "title": "Happy coding!", }, { "rel": "next", "title": "Any Question?", "href": "@comewalk" }]