Introduction GraphQL with Github API

  • Published on

  • View

  • Download


Introduction GraphQL with Github API Sansan 社内 LT 大会 Sansan 株式会社 本田 陽平 Self-Introduction 名前: 本田 陽平、yonda 年齢: 29 最近: Ruby Kaigi…


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 GraphQL Explorer for Github API github の GraphQL API の explorer 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 に適用してどんな感じになるか触ってみようかな 参考 わかりやすいチュートリアル 各言語の実装も頑張ってるみたい js, ruby, python, .net ...etc github GraphQL API explorer 結構前の Rebuild で masuidrive さんが話してた Github が GraphQL 使うよ−っていうブログ Github の GraphQL API のリファレンス ありがとうございました