GraphQL Summit 2018 に参加してきました

フロントエンドエンジニアの @vwxyutarooo (Yutaro) です。11月の7-8日に San Francisco にて行われた GrahpQL Summit 2018 に参加してきましたのでその様子をお伝えします。
フロントエンドからは私とチームメイトの @carlos の2名、バックエンドからも3名参加しました。
現在のメルカリ Web では GraphQL は使われていませんが、アーキテクチャを刷新する Re-Architecture というプロジェクトにおいて GraphQL を使用しています。
トークの内容は YouTube にて公開される予定ですので、全体の雰囲気と私が気になったトークをいくつか紹介します。

f:id:vwxyutarooo:20181128194104j:plain

GraphQL Summit とは

GraphQL Summit は2016年から始まり今年で3年目となります。GraphQL Developer 向けのプラットフォーム、ライブラリを開発提供している Apollo GraphQL により運用されています。
Apollo GraphQL の母体となる会社は 2018 Meteor Development Group Inc. で、名前の通り Meteor を開発したチームでもあります。
今年の GraphQL Summit は San Francisco にある Regency Center という場所で行われました。Airbnb や Audi、BMW、Netflix、GitHub、PayPal など有名な企業からスピーカが集まり、導入経緯や活用事例、Tips など様々なトークが展開されました。
2017 年の動画は YouTube にて公開されています。

GraphQL Summit 全体を通して感じた GraphQL のトレンド

Apollo が運営しているイベントということも大きいですが、サーバ、クライアントサイド共に Node.js (TypeScript) 及び Apollo を絡めた話題が非常に多かったです。私が聞いたトークの中では唯一 Netflix が Ruby を取り上げていました。
フレームワークやツールの拡充が大きく影響する部分ですが、GraphQL Server が今後どの言語で盛り上がっていくのか、というのは気になる点です。Go で GraphQL サーバを実装する話は MTC2018 カンファレンスLPの裏話 〜GraphQL編〜 で紹介されています。
また、2日間を通して Schema の設計及び TypeScript との連携を考える内容も多く見られました。GraphQL による宣言的なプログラミングを成立させるためには、Schema を正とした型生成とその仕組が重要です。Microservices との連携や整合性を保つ仕組みも必要になってくるなと感じました。

気になったトークのサマリ

Apollo Keynote: Doing GraphQL Right

Apollo の CEO @GeoffQL (Geoff Schmidt) による GraphQL と Apollo に関しての基調講演です。

f:id:vwxyutarooo:20181128195653j:plain

なぜ GraphQL か

昨今ではバックエンドの設計が Multiple Services (Microservices) になってきています。Microservices である以上各サービス間でインタフェースの違いが生まれるのは必然です。これを束ねて一貫性のある形でクライアントから扱うことができます。また、例えば100の Microsevices があった時、100のエンドポイントを設けるよりも GraphQL で1本化することでセキュリティなどの面でもメリットがあります。
REST API は手続き的でしたが GraphQL は宣言的に扱えるという点も GraphQL が好まれる理由の一つです。
また、GraphQL の特徴は大きく Integrity、Agility、Operations の3つに分けられ、次のような利点があります。

  • Integrity (整合性)
    • 連結された機能を1つの Graph として提供します
    • Registry から追跡可能な Schema
  • Agility (俊敏さ)
    • Schema はプロダクトの要求に対し柔軟に応えることができる
    • Schema 開発はアジャイル開発に適している
    • 全てのデベロッパーに提供される Graph Metadata
      • 継続的なパフォーマンスチューニングが可能
  • Operations (運用)
    • アクセスと負荷のコントロール
    • 構造化されたログ
    • Service レイヤーから切り離された GraphQL レイヤー

実例として GraphQL は CNBC (アメリカの大手テレビネットワークのひとつ) のアプリケーションにおいて次世代のデータレイヤーとして扱われています。

Apollo Platform のアップデートに関して

Schema registry や Schema change control などの機能が非常に強力で、これにより Schema の整合性チェックやコミット毎の Schema の Diff チェックなどが可能になりました。

What’s next for Apollo Client

f:id:vwxyutarooo:20181128195625j:plain

Apollo チームのメンバーである @peggyrazis のトークです。主に Apollo Client の説明とや今後の展開、最新情報に関する内容について語られました。特に Apollo Link State と VSCode Plugin は厚く解説されています。

Apollo Client について

Apollo Client は煩雑な State 管理をシンプルにすることを目的に作られています。
詳しくは下記 Apollo のブログでも説明されています。

Apollo Link State はローカルの State を Schema で管理可能にするライブラリです。今まで独立したパッケージとして配布されていましたが Apollo Client 次期バージョンの 2.5 からコアに取り込まれることになりました。

VSCode Plugin

VSCode のプラグインと Apollo Engine の組み合わせによるデモの紹介です。コーディング時のスキーマ補完やリアルタイムバリデーション、平均クエリ実行時間などをエディタに表示させるという機能があります。今までなかった体験に、会場でも驚きの声が上がりました。
スライド内にデモ動画がありますので是非見てみてください。
最後に今後の Apollo Client についての話です。3.0で予定されている主要なアップデートは下記の3つです。

  • Apollo Boost が Apollo Client にマージされます
    • バンドルサイズ削減などに貢献する
  • Cache に関する部分を書き直しています
    • リファクタリング、パフォーマンス改善、Cache tag などの新機能追加
  • React の新しい機能についても追従していきます
    • Suspense, hooks, async server rendering

また、今後の Apollo Client に対する Feature Request は下記リポジトリで受け付けられています。

Moving from Redux to GraphQL

こちらは PayPal メンバーからの発表で、彼らも Redux から GraphQL に移行したという話です。正確に言えば GraphQL だけでは成立しないので、Moving from Redux to GraphQL & Apollo という話になります。
私達も Redux 導入検討時に Apollo との比較をしたことがありました。GraphQL 導入時には是非一度検討したい内容です。
少々誤解を与えそうなタイトルと内容ではありますが、PayPal による移行とリファクタの実例は人気を集めていました。

まとめ

初参加の GraphQL Summit でしたが、GraphQL と Apollo が盛り上がってきていることを実感した2日間となりました。
クライアントに求められる要件の複雑化や世界的な Microservices 化の流れの中で、今後も GraphQL の需要は伸びていくのではと感じました。
現状フロントエンドにおいて GraphQL の恩恵を最大限に得るためには Apollo 一択という世界になってしまっています。より健全なエコシステムや選択肢のためにも、Apollo 以外のフレームワークやライブラリが出てくるとよいですね。
日本からの参加は私達5名だけでしたが、今後私達も メルカリ Web の Re-Architecture を通してGraphQL と Apollo のキャッチアップをしながら、導入事例などの情報を発信していければと思いました。

  • X
  • Facebook
  • linkedin
  • このエントリーをはてなブックマークに追加