Introduction GraphQL with Github API

Sansan 社内 LT 大会Sansan 株式会社 本田 陽平

Self-Introduction名前 : 本田 陽平、 yonda

年齢 : 29

最近 : Ruby Kaigi で触発されて英語勉強中

悩み : 英語の勉強にもう飽きてきた

The GitHub GraphQL API

What is GraphQL ?●Facebook が GraphAPI で柔軟にデータのやり取りが出来るように開発し

た言語仕様

●簡単に言うと、 REST と違って返す情報を決め打ちで API を作るのではなくて、何を返して欲しいか、とか、情報の結合なんかもクエリで指定できる

What is GraphQL points better than RESTfull API ?●何度も通信しなくていい

● 都度 API を作らなくて（変更しなくて）いい

○ API 側の処理も効率化出来る

Why github choose GraphQL ?You may be wondering why we chose to start supporting GraphQL. Our API was designed to be RESTful and hypermedia-driven. We’re fortunate to have dozens of different open-source clients written in a plethora of languages. Businesses grew around these endpoints.

Like most technology, REST is not perfect and has some drawbacks. Our ambition to change our API focused on solving two problems.

The first was scalability. The REST API is responsible for over 60% of the requests made to our database tier. This is partly because, by its nature, hypermedia navigation requires a client to repeatedly communicate with a server so that it can get all the information it needs. Our responses were bloated and filled with all sorts of *_url hints in the JSON responses to help people continue to navigate through the API to get what they needed. Despite all the information we provided, we heard from integrators that our REST API also wasn’t very flexible. It sometimes required two or three separate calls to assemble a complete view of a resource. It seemed like our responses simultaneously sent too much data and didn’t include data that consumers needed.

As we began to audit our endpoints in preparation for an APIv4, we encountered our second problem. We wanted to collect some meta-information about our endpoints. For example, we wanted to identify the OAuth scopes required for each endpoint. We wanted to be smarter about how our resources were paginated. We wanted assurances of type-safety for user-supplied parameters. We wanted to generate documentation from our code. We wanted to generate clients instead of manually supplying patches to our Octokit suite. We studied a variety of API specifications built to make some of this easier, but we found that none of the standards totally matched our requirements.

And then we learned about GraphQL.

(from http://githubengineering.com/the-github-graphql-api/)

GraphQL Explorer for Github API●github の GraphQL API の explorer

●https://graphql-explorer.githubapp.com/

Github API を使ってGraphQL の文法をざっくり紹介

example (at first)

example (multi fields)

example (aliases)

example (like a join of SQL)

example (fragments)

example (variables)

example (directives)

感想●クエリが直感的でいい感じ

●柔軟に使えそう

●結構高機能

●mutation とか使えばデータの更新もできるみたい

○ ちょっと今回はそこまで触れなかった。。。

●次は Rails に適用してどんな感じになるか触ってみようかな

○http://mgiroux.me/2015/getting-started-with-rails-graphql-relay/

参考● http://graphql.org/learn/

○ わかりやすいチュートリアル

● http://graphql.org/code/○ 各言語の実装も頑張ってるみたい

■ js, ruby, python, .net ...etc● https://graphql-explorer.githubapp.com/

○ github GraphQL API explorer● http://rebuild.fm/102/

○ 結構前の Rebuild で masuidrive さんが話してた● http://githubengineering.com/the-github-graphql-api/

○ Github が GraphQL 使うよ っていうブログ−● https://developer.github.com/early-access/graphql/

○ Github の GraphQL API のリファレンス

ありがとうございました