YAPC::Fukuoka 2017 HAKATA

Bb2173a0c3f4b5dc6f5aab6adfe641a9?s=47 Takatsugu Shigeta
July 01, 2017
540

YAPC::Fukuoka 2017 HAKATA

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

Bb2173a0c3f4b5dc6f5aab6adfe641a9?s=128

Takatsugu Shigeta

July 01, 2017
Tweet

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" }]