YAPC::Fukuoka 2017 HAKATA

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

YAPC::Fukuoka 2017 HAKATA

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

Bb2173a0c3f4b5dc6f5aab6adfe641a9?s=128

Takatsugu Shigeta

July 01, 2017
Tweet

Transcript

  1. 2.

    { "talk": { "title": "Web API の未来", "event": "YAPC::Fukuoka 2017",

    "speaker": "Takatsugu Shigeta", "keywords": ["API", "GraphQL"] } }
  2. 4.

    { "speaker": { "name": "シゲタタカツグ", "elsewhere": { "PAUSE": "SHIGETA", "Twitter":

    "@comewalk", "GitHub": "@comewalk", "Blog": "https://blog.comewalk.com/" }, "work": { "at": "Six Apart Ltd.", "information": "We are hiring!" } } }
  3. 9.

    REST + XML • 2005年年 Ajax の登場 • 2005年年 REST

    ムーブメント • ブラウザの時代へ
  4. 10.

    XML-RPC • 1999年年頃 仕様策定 • RPC を HTTP の上で⾏行行うプロトコルのひとつ •

    Firewall を越えてインターネットワイドに • 2001年年頃 SOAP 誕⽣生
  5. 11.

    RPC • Remote Procedure Call • ネットワーク越しに関数呼び出しするという意味で は Web API

    の原点にある(と思う) • 独⾃自ポートを開けるなど Firewall を越える課題など
  6. 16.

    REST によって HTTP の表現だけでリソースごとのシ ンプルなアクセスが提供できた⼀一⽅方で、⼤大量量のリソー スを抱えるサービスは多くのエンドポイントを持つた め、複数リソースからデータの取得が必要な場合に複 数回の API コールを余儀なくされる結果、主にクラ

    イアントサイドのオーバヘッドが増え、⾮非同期処理理や ローカルキャッシュなどの技術を駆使することによる 実装の複雑化を増幅した結果、サーバサイド以上にク ライアントサイドは⾼高度な技術を要求されることとなっ た。
  7. 22.

    type Talk { title: String event: String speaker: String keywords:

    [String] } type Query { talk(title: String): Talk }
  8. 23.

    type Talk { title: String! event: String! speaker: String! keywords:

    [String] } type Root { talk(title: String): Talk } schema { query: Root }
  9. 25.

    { "data": { "talk": { "title": "Web API の未来", "event":

    "YAPC::Fukuoka 2017", "speaker": "Takatsugu Shigeta", "keywords": ["API", "GraphQL"] } } }
  10. 26.

    Request { talk(title: "Foo") { title event speaker keywords }

    } Response { "data": { "talk": { "title": "Foo", "event": "YAPC::Fukuo "speaker": "Mike Jone "keywords": ["Alice", } } }
  11. 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 でリクエスト
  12. 28.

    struct Talk { char* title; char* event; char* speaker; char*

    keywords; }; struct Talk t; talk("Foo", &t); printf("%s", t->title); // "Foo" RPC の時代に似てますね! (20年年以上のあいだ、形を変えてもやっていることは同じ)
  13. 30.

    Query (データ問い合わせ) type UserQuery { search(name: String): [User] } schema

    { query: UserQuery } type Query { search(name: String): [User] }
  14. 31.

    Query (データ問い合わせ) Request query { search(name: "Foo") { name email

    } } Response { "data": { [{ "name": "Bob", "email": "bob@example.com" }] } }
  15. 32.

    Mutation (データ操作) type UserMutation { update(name: String): Int } schema

    { muration: UserMutation } type Mutation { update(name: String): Int }
  16. 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
  17. 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
  18. 42.

    Web API の未来 • Facebook, Netflix, GitHub など⼤大⼿手が動き始めた • GitHub

    API は v3 が REST、v4 が GraphQL • REST が GraphQL に置き換わることは当⾯面ないと思う • だけど(ほぼ)5年年周期で変わるトレンドのはじまり • フォーマットは JSON • REST 原理理主義は卒業してもいい • きっと次に⽣生まれる何かが Web API の未来を担う
  19. 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" } }
  20. 48.

    "links":[{ "rel": "self", "title": "Happy coding!", }, { "rel": "next",

    "title": "Any Question?", "href": "@comewalk" }]