大学院の研究でGitHubのデータを取得しようとしたら新しいバージョンのAPIはGraphQLなインターフェースだったり、最近AWSがAppSyncをリリースしたり、Graphcoolを使ってAlgoliaをGraphQLで叩いて〜とかって記事を見かけたり、、とかっていうのがあってちゃんと追ってみたいな、と。
こういうのはやっぱりそもそもなフィロソフィー的なことから知りたいなってことでググってたら、GraphQL開発元のFacebookさんがそのままズバリなブログを書いてらっしゃるじゃありませんか、と。
//embedr.flickr.com/assets/client-code.js
ということで、コチラを自分の理解を深めることも踏まえてまとめてみたいと思います。もちろん英語が読める方は原文を読んでいただくことをオススメします。尚、本ブログの内容はタイトルの通り私個人のものであり、所属企業・部門見解を代表するものではありませんmm
GraphQL: A data query language
When we built Facebook’s mobile applications, we needed a data-fetching API powerful enough to describe all of Facebook, yet simple enough to be easy to learn and use by our product developers. We developed GraphQL three years ago to fill this need. Today it powers hundreds of billions of API calls a day. This year we’ve begun the process of open-sourcing GraphQL by drafting a specification, releasing a reference implementation, and forming a community around it at graphql.org.
私達がFacebookのモバイル・アプリケーションを構築する際、Facebookの全てをモバイル上で可動させるための十分強力なデータフェッチングAPIが必要で、且つ、開発エンジニアたちにとって十分シンプルで簡単に技術習得可能なものが求められていました。私達はこのニーズを満たすためにGraphQLを三年前に開発しました。今日では1日数千億ものAPIコールを受け付けています。今年から私達はGraphQLをオープンソースにするプロセスに次のように取り掛かりはじめました。仕様のドラフト、リファレンス実装のリリース、そしてgraphql.orgとそのコミュニティの育成。
Why GraphQL?
Back in 2012, we began an effort to rebuild Facebook’s native mobile applications.
2012年、私達はFacebookのネイティブモバイル・アプリケーションの再構築をに取り掛かり始めました。
At the time, our iOS and Android apps were thin wrappers around views of our mobile website. While this brought us close to a platonic ideal of the “write once, run anywhere” mobile application, in practice it pushed our mobile-webview apps beyond their limits. As Facebook’s mobile apps became more complex, they suffered poor performance and frequently crashed.
その頃、iOSとAndroidのアプリは私達のモバイルウェブサイトの薄いラッパーでしかありませんでした。これはプラトニックで理想的な”write once, run anywhere”なモバイル・アプリケーションに近いものでしたが、実際には、mobile-webviewアプリはその制限に押し込まれる結果になってしまっていました。Facebookのモバイルアプリはより複雑化し、それはpoorなパフォーマンスと頻繁に発生するクラッシュに悩まされる結果をもたらしました。
As we transitioned to natively implemented models and views, we found ourselves for the first time needing an API data version of News Feed — which up until that point had only been delivered as HTML. We evaluated our options for delivering News Feed data to our mobile apps, including RESTful server resources and FQL tables (Facebook’s SQL-like API). We were frustrated with the differences between the data we wanted to use in our apps and the server queries they required. We don’t think of data in terms of resource URLs, secondary keys, or join tables; we think about it in terms of a graph of objects and the models we ultimately use in our apps like NSObjects or JSON.
modelとviewをネイティブ実装に置き換えていく中で、ニュースフィードに関するAPIが最初に必要になりました。それはそれまでHTMLとしてのみ提供されていたものでした。私達はニュースフィードのデータをモバイルアプリに届けるための選択肢を評価していました。それはRESTfulなサーバーリソースやFQLテーブル(FacebookのSQLライクなAPI)を含むものでした。そこでは、私達が欲しいと思っているアプリ内で使うために必要なデータと、それを取得するためのサーバークエリーとの差分にフラストレーションを感じていました。モバイルアプリを構築する上でデータを取得するためのリソースのURL、セカンダリキーやテーブルのジョインなどは考えたくはなく、私達はNSObjectsやJSONのようなオブジェクトのグラフとモデルが欲しいだけだったのです。
There was also a considerable amount of code to write on both the server to prepare the data and on the client to parse it. This frustration inspired a few of us to start the project that ultimately became GraphQL. GraphQL was our opportunity to rethink mobile app data-fetching from the perspective of product designers and developers. It moved the focus of development to the client apps, where designers and developers spend their time and attention.
それは、サーバー側で必要なデータを取得するコード、そして、それをクライアント側でパースするためのコードを相当量かかなくてはならないものでした。このフラストレーションが我々の中の何人かにインスピレーションを与え、そこではじまったプロジェクトがGraphQLへと繋がっていきました。GraphQLは、プロダクトデザイナーおよび開発者の目線で、モバイルアプリにおけるデータのフェッチを再考する機会になりました。つまり、焦点がクライアントアプリから、デザイナーおよび開発者が使う時間と注力に移ったということです。
What is GraphQL?
A GraphQL query is a string that is sent to a server to be interpreted and fulfilled, which then returns JSON back to the client.
GraphQLクエリとは、サーバーに送信され、サーバー側で解釈および実行される文字列のことを指します。そしてクライアントにはクエリ結果のJSONが返ります。
Defines a data shape: The first thing you’ll notice is that GraphQL queries mirror their response. This makes it easy to predict the shape of the data returned from a query, as well as to write a query if you know the data your app needs. More important, this makes GraphQL really easy to learn and use. GraphQL is unapologetically driven by the data requirements of products and of the designers and developers who build them.
データ型の定義: まず最初に気づくことは、GraphQLクエリはレスポンスをそのまま反映させている、という点です。これによってクエリによって返却されるデータの型が予想しやすくなるのと同時に、アプリケーションにとって必要なデータが予め分かっている場合にクエリが書きやすくなります。更に重要なのは、これによってGraphQLは本当に学習しやすく、且つ、使いやすくなる、ということです。GraphQLはプロダクトのデータおよびデザイナー/開発者のデータ要求にunaplogetically(正々堂々と？)に動作します。
Hierarchical: Another important aspect of GraphQL is its hierarchical nature. GraphQL naturally follows relationships between objects, where a RESTful service may require multiple round-trips (resource-intensive on mobile networks) or a complex join statement in SQL. This data hierarchy pairs well with graph-structured data stores and ultimately with the hierarchical user interfaces it’s used within.
階層構造: GraphQLのもう一つの重要な要素は、その階層構造です。GraphQLはナチュラルにオブジェクトの関連に従います。それはRESTfulなサービスであれば何回もの(リソースインテンシブなモバイルネットワーク環境下で)ラウンドトリップを伴うようなものや、SQLによる複雑なjoinを伴うようなものです。このデータ階層はグラフ構造なデータストアにみられるもので、ユーザーインターフェースに使われる階層構造と根本的によく似ています。
Strongly typed: Each level of a GraphQL query corresponds to a particular type, and each type describes a set of available fields. Similar to SQL, this allows GraphQL to provide descriptive error messages before executing a query.
強い型付け: それぞれのレベルのGraphQLクエリは特定の型に対応し、それぞれの型は可能なフィールドセットを示します。SQLと同じように、これによってクエリ実行前にエラーメッセージを提供することが可能になります。
Protocol, not storage: Each GraphQL field on the server is backed by any arbitrary function. While we were building GraphQL to support News Feed, we already had a sophisticated feed ranking and storage model, along with existing databases and business logic. GraphQL had to leverage all this existing work to be useful, and so does not dictate or provide any backing storage. Instead, GraphQL takes advantage of your existing code.
プロトコルであってストレージではない: それぞれのサーバー側のGraphQLフィールドは任意のファンクションによって成り立ちます。ニュースフィード用のGraphQLを構築していた際、既に私達は既存のデータベースやビジネスロジックに加えて、洗練されたフィードランキングとストレージモデルを保持していました。GraphQLはこれら全ての既存処理全てにレバレッジを効かせなければなりませんでした。これは任意のストレージの利用を必要とするようなものではありません。その代りにGraphQLはあなたの既存のコードを活用します。
Introspective: A GraphQL server can be queried for the types it supports. This creates a powerful platform for tools and client software to build atop this information like code generation in statically typed languages, our application framework, Relay, or IDEs like GraphiQL (pictured below). GraphiQL helps developers learn and explore an API quickly without grepping the codebase or wrangling with cURL.
内省的(内部の見通しの良い環境): GraphQLサーバーはサポートするタイプのクエリを受け付けます。この情報を活用することでパワフルなツールやクライアントソフトウェアといったプラットフォームの構築が可能になります。例えば静的型付け言語におけるコードの自動生成, アプリケーションフレームワーク, Relay(https://facebook.github.io/relay/), もしくはGraphiQL(下の図を参照)のようなIDEがそれにあたります。GraphiQLは開発者の理解を促進し、APIの操作をgrepしたりcurlを叩いたりすることなく試すのに役に立ちます。
Version free: The shape of the returned data is determined entirely by the client’s query, so servers become simpler and easy to generalize. When you’re adding new product features, additional fields can be added to the server, leaving existing clients unaffected. When you’re sunsetting older features, the corresponding server fields can be deprecated but continue to function. This gradual, backward-compatible process removes the need for an incrementing version number. We still support three years of released Facebook applications on the same version of our GraphQL API.
バージョンフリー: 返却されるデータは完全にクライアントからのクエリによって決まります。その結果サーバーはシンプルで汎用化されやすくなります。プロダクトに機能を追加する場合、サーバーにフィールドが追加されるだけで既存クライアントには影響がありません。もし古い機能を削除する場合は、対応するサーバー側のフィールドはdeprecatedになりますが継続して機能します。この徐々にそして下位互換性を保つプロセスはバージョン番号をインクリメントさせていくようなニーズを排除します。私達は今でも3年前にリリースしたものと同じバージョンのGraphQL APIを使い続けています。
With GraphQL, we were able to build full-featured native News Feed on iOS in 2012, and on Android shortly after. Since then, GraphQL has become the primary way we build our mobile apps and the servers that power them. More than three years later, GraphQL powers almost all data-fetching in our mobile applications, serving millions of requests per second from nearly 1,000 shipped application versions.
GraphQLによって、私達は2012年に全機能を搭載したネイティブなニュースフィードをiOS上に構築することができましたし、Android対応もその後に短期間で行いました。それからというもの、GraphQLは私達のモバイルアプリおよびそれ用のサーバー開発のプライマリな選択肢となりました。3年以上経過しましたが、GraphQLは私達のほぼすべてのモバイルアプリケーションのデータフェッチに使われています。規模感としてはおよそ1000ものバージョンのリリースされたアプリケーションから秒間に数百万リクエストを受け付けるようなｍのとなっています。
When we built GraphQL in 2012 we had no idea how important it would become to how we build things at Facebook and didn’t anticipate its value beyond Facebook. However earlier this year we announced Relay, our application framework for the web and React Native built atop GraphQL. The community excitement for Relay inspired us to revisit GraphQL to evaluate every detail, make improvements, fix inconsistencies, and write a specification describing GraphQL and how it works.
私達が2012年にGraphQLを作った時は、正直ここまでFacebookで物づくりする上で重要なものになるとは思っていなかったし、Facebookを越えて活用されるような事態は想定していませんでした。しかし、2015年のはじめにRelayをアナウンスしました。これはGraphQLを利用したWebとReact Native用のアプリケーションフレームワークです。このRelayコミュニティのエキサイトメントはGraphQLを再度全ての詳細を評価することに繋がり、それによって、改善がなされ、一貫性がない部分が修正され、GraphQLの仕様の記述とそれがどのように動くのかを文書化することに繋がりました。
Relay, React Native, and GraphQL are designed as parts of a complete development stack built around the focus of the product designer and developer. As part of our goal to share this stack with the community, earlier this year we evaluated every detail of GraphQL, made improvements, fixed inconsistencies, and wrote a specification describing GraphQL and how it works.
Relay, React Native, そしてGraphQLはプロダクトデザイナーおよび開発者にフォーカスし完全な開発スタックの中の一部としてデザインされています。このスタックをコミュニティにシェアする私達のゴールとしては、GraphQLの全ての詳細の評価, 更なる改善, 一貫性のない部分の修正,そしてGraphQLの仕様の記述とそれがどのように動くかを文書化したことが挙げられれます。
Two months ago, we made our progress public and released a working draft of the GraphQL spec and a preview reference implementation: GraphQL.js. Since then, a community has started to form around GraphQL, and versions of the GraphQL runtime are being built in many languages, including Go, Ruby, Scala, Java, .Net, and Python. We’ve also begun to share some of the tools we use internally, like GraphiQL, an in-browser IDE, documentation browser, and query runner. GraphQL has also seen production usage outside Facebook, at the Financial Times.
2ヶ月前に、私達は進捗状況をパブリックに公開し、GraphQLのワーキングドラフトをリリースし、GraphQL.jsというリファレンス実装のプレビューを公開しました。それ以来、GraphQLを取り巻くコミュニティが形成され、GraphQLのランタイムはたくさんの言語(Go, Ruby, Scala, Java, .Net, そしてPython)で実装されました。私達はブラウザで動作するGraphiQLのような内部ツールを公開しはじめました。GraphQLはまたFacebook以外にFinancial Timesのプロダクション環境で使われるようになりました。
While GraphQL is an established part of building products at Facebook, its use beyond Facebook is just beginning. Try out GraphiQL and help provide feedback on our specification. We think GraphQL can greatly simplify data needs for both client product developers and server-side engineers, regardless of what languages you’re using in either environment, and we’re excited to continue to improve GraphQL, help a community grow around it, and see what we can build together.
GraphQLはFacebookのプロダクトを開発するために構築されたもので、Facebook以外での利用ははじまったばかりです。是非GraphiQLを試して私達の仕様に関するフィードバックの提供にご協力ください。私達は使用するプログラミング言語や環境にかかわらず、GraphQLがクライアントサイドおよびサーバーサイド両方の開発者にとってデータのニーズを大幅にシンプルにできるプロダクトであると考えています。そして私達はGraphQLの今後の益々の発展と、コミュニティの成長支援と、そして一緒に作り上げていくことができるものを非常に楽しみにしています。
amzn_assoc_ad_type =”responsive_search_widget”; amzn_assoc_tracking_id =”diary045-22″; amzn_assoc_marketplace =”amazon”; amzn_assoc_region =”JP”; amzn_assoc_placement =””; amzn_assoc_search_type = “search_widget”;amzn_assoc_width =”auto”; amzn_assoc_height =”auto”; amzn_assoc_default_search_category =””; amzn_assoc_default_search_key =”graphql”;amzn_assoc_theme =”light”; amzn_assoc_bg_color =”FFFFFF”; //z-fe.amazon-adsystem.com/widgets/q?ServiceVersion=20070822&Operation=GetScript&ID=OneJS&WS=1&Marketplace=JP
