Apollo GraphQLでWebサービスを開発してわかったこと

2018/07/26
このエントリーをはてなブックマークに追加

初めまして! インターンの長瀬です。普段はWebフロントエンド関連の業務をしています。

今回は、私がApollo GraphQLを使ってWebサービスを開発してみて感じたこと・考えたことを共有します。前半では開発での知見を活かし、GraphQL APIをRESTful APIと比較しながら紹介していきますので、GraphQLなんて使ったことがないよ! という方もお楽しみいただけるかと思います。

tl;dr

  • WebサービスをApollo GraphQLで開発した
    • サービスにおいて、特に複雑なグラフ構造のデータモデル等はなかったが、型定義の自動生成や単一エンドポイントなどの点でGraphQLを使う意義があったと感じた
    • Apollo GraphQLはブラウザ拡張やapollo-codegenなどの開発支援も充実しており、快適に開発ができた

GraphQL, Apollo GraphQLについて

GraphQL, Apollo GraphQLについてすでにご存じの方は読み飛ばしていただいて結構です。

GraphQLについて

そもそも、GraphQLはWeb APIのためのクエリ言語です。RESTfulなAPIが抱えがちな以下の課題を解決できます。

  1. エンドポイントやURLのクエリパラメータが煩雑になる
  2. 目的のリソース以外の余計なデータがついてくることがある
  3. リソースをフェッチするために必要なリクエスト数が多くなりがち

エンドポイントやURLのクエリパラメータが煩雑になる

たとえばレスポンシブ対応の一環としてモバイルとPCで別サイズの画像を返したい時や、件数の多いデータをページネーション形式で返したい場合など、場合分けが必要になってくるにつれてURLのクエリパラメータが煩雑になってしまいます。

また、APIのエンドポイントの構造もAPIが大規模化するにつれて複雑になっていきます。

対して、GraphQLのエンドポイントは単一であり、またURLのクエリパラメータは使わずにGraphQLのQuery内に記述します。QueryはGraphQL APIが提供しているデータのうち何がほしいかを簡潔に記述したもので、HTTPリクエストのbodyに乗せて送ります。
例として、ブログサービスにおいて特定の投稿以降に投稿された投稿を20件分取得したい場合には、以下のようなQueryを記述します。

{
  latest(after: "ID", count: 20) {
    cursors {
      after
    },
    posts {
      title
      thumbnailUrl
      description
    }
  }
}

QueryはURLのクエリパラメータやセッション等を使うより可読性や表現力が高く、静的な型付けがされるため(afterはString, countならInt)、エディタでの自動補完やコード・ドキュメントの自動生成などの恩恵を受けることができます。RESTfulなAPIでもopenapi-generator(swagger-codegen)などを使うことで同様なことが可能ですが、GraphQL APIの場合はGraphiQLというAPIのテストツールやエディタにおいてQuery自体に対して補完が効くため非常に便利です。また、GraphQL APIサーバはIntrospectionという機構を持っており、cliツールなどを利用してすでに動作しているAPIサーバからAvailableなQueryや型などの情報を吸い出してファイルにダンプできます。このファイルをコードの自動生成・補完に利用するというしくみです。

GraphiQLでAPIをテストする様子

サーバでこのクエリをどのように処理するかというと、クエリで指定されるフィールドごとにresolverという関数を定義し、対応するデータをDBなどのデータストア等から取得して返すようにします。resolverの書式は以下の通りです。

fieldName(obj, args, context, info) { result }

見ての通り、resolverは最大4つの引数を取ります。

  1. obj には、指定したフィールドの親フィールドのデータが含まれています。親フィールドが存在しない場合(ルートのフィールドの場合)には、設定値が返されます。
  2. argsには、クエリで渡した引数(先の例のafter, countに該当)が含まれています。
  3. contextには、すべてのresolverで引き回して使いたいような、セッション・ヘッダ・APIエンドポイントのURLなどの情報が含まれます。たとえば「ログイン済みのユーザーのみがデータへアクセスできるようにしたい場合」や、先程挙げた「モバイルとPCで別サイズの画像を返したい場合({device: 'pc'}などとしてデバイスタイプの情報を指定する場合)」などで有用です。
  4. infoでは、そのフィールドの名前やパス(ルートからそのフィードを指定するまでの道筋)、親フィールドの型などのメタデータが含まれています。

また、Queryと同様にして、GraphQL APIが提供しているデータに変更を加えたい場合にはMutationを、データに対するMutationを監視して常に最新の状態を維持したい場合にはSubscriptionを書くことができます。GraphQL APIはこれらのQuery, Mutation, Subscriptionの3つの操作から成り立っています。

目的のリソース以外の余計なデータがついてくることがある

ブログサービスの例で、あるユーザーのidからユーザー名を取得したい場合、RESTfulなAPIでは/users/:id/users?id='id'に対してリクエストをし、以下のようなレスポンスを得るはずです。

{
  name: "haruka",
  id: "19900204",
  posts: [],
  subscriptions: [],
  subscribedBy: [],
  thumbnailUrl: []
}

ほしいデータはユーザー名のみなのですが、購読・被購読者や過去の投稿の一覧までが返されてしまいます。アプリケーションのアクティブユーザー数が増えてくると、クライアント<->APIサーバおよびAPIサーバ<->データストアの通信回数が大きく増えて問題になりかねません。そこで、GraphQLでは以下のようなQueryでリクエストします。

{
  user(id: "19900204") {
    name
  }
}

必要なフィールドのみを指定するため、余分なデータが取得され返されることはありません。

{
  name: "haruka"
}

リソースをフェッチするために必要なリクエスト数が多くなりがち

先程のレスポンスが、以下のように購読者一覧を含んでいたとします。

{
  name: "haruka",
  id: "19900204",
  posts: [],
  subscriptions: [
    "/users?id=19910917",
    "/users?id=19861028",
    "/users?id=19851025"
  ],
  subscribedBy: [],
  thumbnailUrl: []
}

全購読者のユーザオブジェクトを取得しようとすると、計4回のラウンドトリップが発生します。先程の例で紹介したように、GraphQL APIでは必要なフィールドだけを指定して1度の通信ですべてのデータを取得するため、通信コストが大きく削減できます。

また、facebook/dataloaderなどと組み合わせることで、深くネストしたクエリについて、キャッシュやバッチ処理を利用し効率的にデータストアからデータをフェッチできます。こちらはAPI<->DBについての話題であり、GraphQL APIに限らずさまざまなシーンで利用可能です。

Apolloとは

Apollo vs Relay

ApolloとはGraphQL APIのクライアントライブラリの1つです。ほかにはGraphQLの開発元であるFacebookによるRelayが有名ですが、対応しているクライアントや開発ツールの充実度からApolloに分があると考え、こちらを採用しました。

ApolloRelay
対応クライアントReact.js, Vue.js, Angular, Swift, Java, etc…React.js
開発ツールの充実度launchpad, engine, codegen, ブラウザ拡張等盛りたくさんplayground環境
ドキュメントの充実度充実(動画、 ブログ、 Webサイト等)比較的充実(Webサイトのみ)
ローカルステートの管理apollo-link-stateを利用可能Redux, MobX, etc..

Apolloはモックサーバを手早く簡単に作成・公開できるApollo Launchpadや、APIサーバの監視・解析ツールであるApollo Engine、そしてAPIサーバを解析してクライアント毎にコードを自動生成するapollo-codegen(apollo-cliというリポジトリ名に変わりました)といった充実した開発ツールが用意されています。

apollo-link-stateによるローカルステートの管理

Apolloが注目されている理由の1つとして、公式が「apollo-link-stateを利用してローカルステートを管理することで、ReduxやMobXといった他の状態管理の機構を使わなくて済む」ことを謳っている点があります。apollo-link-stateにより、single source of truthなデータストアでリモート(API)のデータとアプリケーションの状態の両方を管理することが可能だということです。

ブログサービスの例で考えてみます。ユーザーが過去の投稿の一覧を複数選択し、まとめて削除できるような機能を作りたいとしましょう。apollo-link-stateを使うことで、過去の投稿一覧のQueryは以下のように書けます。

query allPosts($userId: ID!) {
  allPosts(userId: $userId) {
    id
    content
    selected @client
    author {
      id
      name
      thumbnailUrl
    }
  }
}

@clientというディレクティブをこのように使うことで、APIではなくブラウザのインメモリキャッシュからデータをフェッチできます。同様に先ほど紹介したmutationについても、DB等のリモートのデータではなく、キャッシュのデータに変更を加えるようにできます。

mutation selectPost($postId: ID!) {
  selectPost(postId: $postId) @client {
    selected
  }
}

このようにして、ローカルステートとリモートのデータを共通のインタフェース(=GraphQL)で管理し、single source of truthを実現しています。

しかしながら、実際のユースケースではほかのRESTfulなAPIと組み合わせて使うケースがほとんどかと思います。その際はapollo-link-restというパッケージを利用できます。こちらはapollo-link-stateとは異なりunder active developmentな状態ですが、以下のようにしてRESTfulなAPIに対してQuery, Mutationを発行できます。

query allPosts {
  allPosts @rest(type: "Post", path: "/posts") {
    id
    content
  }
}
mutation publishPost(
  $someApiWithACustomBodyKey: PublishablePostInput!
) {
  publishedPost: publish(input: "19900204", body: $someApiWithACustomBodyKey)
    @rest(
      type: "Post"
      path: "/posts/{args.input}/new"
      method: "POST"
      bodyKey: "body"
    ) {
    id
    title
  }
}

実際に開発してみて

開発の流れ

実際にApollo GraphQLを使ってWebサービスをゼロから作ってみました。大まかな開発の流れは以下のようになりました。

  1. Node.js(with TypeScript, graphql-yoga)でAPIサーバを書く
    • graphql-yoga: Apollo, Relayに対応したNode.js向けのGraphQL APIフレームワーク Expressのミドルウェアを利用可能
  2. GraphQLでAPIのスキーマを書く
  3. 2のスキーマから、gql2tsというツールでTypeScriptの型定義を生成する
  4. 3の型定義を利用して、resolverを書いていく
  5. GraphiQLでAPIをテストする
  6. angular-cliでアプリケーション側(フロントエンド)のスケルトンを作成する
  7. APIに対するクエリをGraphQLで書く
  8. apollo-cliを使って、APIサーバのインストロペクション結果と7のクエリから、フロントエンドで使うTypeScriptの型定義を自動生成する
  9. 8の型定義を使ってフロントエンドのロジック部分を書いていく(apollo-angularを利用)

Apollo GraphQLのよかったところ

今回の案件ではフロントエンドとサーバサイドの両方でTypeScriptを利用したのですが、どちらの環境でもスキーマから自動生成された型定義を利用してスムーズに開発を進めることができました。またフロントエンドではフレームワークにAngularを利用しましたが、QueryのレスポンスはObservableで返されるため、違和感なく使うことができました。

さらに、ブラウザ拡張のApollo Client Developer Toolsも便利でした。Developer Toolsには以下の機能が備わっています。
– GraphiQLをその場で実行する(本来であればAPIサーバと別のポートでGraphiQLサーバを立ち上げて、ブラウザでそこにアクセスして利用します)
– JavaScriptから発行されたクエリのログの確認、クエリの編集・再発行
apollo-link-stateでキャッシュに書き込んだ値の確認(apolloはクエリのレスポンスを勝手にキャッシュしてくれるのですが、その内容も確認できます)

Apollo GraphQLのつらかったところ・気になったところ

特に「GraphQLのここがつらかった」というところはありませんでした…強いて言うなれば、開発の中盤で「これGraphQL APIにする意味あったんだろうか…(OpenAPIでもよかったのでは)」という気持ちに襲われたことくらいです。しかし一通り開発を終えると、エディタ・GraphiQLにおけるクエリの補完や、GraphQLが提供する型システムに魅力を見出していました。前半で解説したとおり、通信コストやパフォーマンスの点でもGraphQL APIに分があるはずです。

気になった点としては、今回はSubscriptionを使う場面がなかったため、どう実装し利用すればよいのかが気になっています。

さいごに

Apollo GraphQLを使ってゼロからWebサービスを開発し、得られた知見を共有させていただきました(どちらかというとGraphQL・Apolloの解説がメインとなってしまいましたが…)。Apolloは対応するクライアント・Webフロントエンドフレームワークが多いことから、これからより一層注目されていくと考えています。この記事を読んで「Apollo、さっそく私も試してみよう!」という方が出てきてくれたらうれしいです。

その他の記事

Other Articles

2019/08/14
Maker Faire Tokyo 2019でARゲームを出展しました

2019/07/25
夏休みだョ!WebAssembly Proposal全員集合!!

2019/07/08
鵜呑みにしないで! —— 書籍『クリーンアーキテクチャ』所感 ≪null 篇≫

2019/07/03
W3C Workshop on Web Games参加レポート

2019/06/28
TypeScriptでObject.assign()に正しい型をつける

2019/06/25
カブクエンジニア開発合宿に行ってきました 2019夏

2019/06/21
Hola! KubeCon Europe 2019の参加レポート

2019/06/19
Clean Resume きれいな環境できれいな履歴書を作成する

2019/05/20
[Web フロントエンド] 状態更新ロジックをフレームワークから独立させる

2019/04/16
C++のenable_shared_from_thisを使う

2019/04/12
OpenAPI 3 ファーストな Web アプリケーション開発(Python で API 編)

2019/04/08
WebGLでレイマーチングを使ったCSGを実現する

2019/04/02
『エンジニア採用最前線』に感化されて2週間でエンジニア主導の求人票更新フローを構築した話

2019/03/29
その1 Jetson TX2でk3s(枯山水)を動かしてみた

2019/03/27
任意のブラウザ上でJestで書いたテストを実行する

2019/02/08
TypeScript で “radian” と “degree” を間違えないようにする

2019/02/05
Python3でGoogle Cloud ML Engineをローカルで動作する方法

2019/01/18
SIGGRAPH Asia 2018 参加レポート

2019/01/08
お正月だョ!ECMAScript Proposal全員集合!!

2019/01/08
カブクエンジニア開発合宿に行ってきました 2018秋

2018/12/25
OpenAPI 3 ファーストな Web アプリケーション開発(環境編)

2018/12/23
いまMLKitカスタムモデル(TF Lite)は使えるのか

2018/12/21
[IoT] Docker on JetsonでMQTTを使ってCloud IoT Coreと通信する

2018/12/11
TypeScriptで実現する型安全な多言語対応(Angularを例に)

2018/12/05
GASでCompute Engineの時間に応じた自動停止/起動ツールを作成する 〜GASで簡単に好きなGoogle APIを叩く方法〜

2018/12/02
single quotes な Black を vendoring して packaging

2018/11/14
3次元データに2次元データの深層学習の技術(Inception V3, ResNet)を適用

2018/11/04
Node Knockout 2018 に参戦しました

2018/10/24
SIGGRAPH 2018参加レポート-後編(VR/AR)

2018/10/11
Angular 4アプリケーションをAngular 6に移行する

2018/10/05
SIGGRAPH 2018参加レポート-特別編(VR@50)

2018/10/03
Three.jsでVRしたい

2018/10/02
SIGGRAPH 2018参加レポート-前編

2018/09/27
ズーム可能なSVGを実装する方法の解説

2018/09/25
Kerasを用いた複数入力モデル精度向上のためのTips

2018/09/21
競技プログラミングの勉強会を開催している話

2018/09/19
Ladder Netwoksによる半教師あり学習

2018/08/10
「Maker Faire Tokyo 2018」に出展しました

2018/08/02
Kerasを用いた複数時系列データを1つの深層学習モデルで学習させる方法

2018/07/19
【深層学習】時系列データに対する1次元畳み込み層の出力を可視化

2018/07/11
きたない requirements.txt から Pipenv への移行

2018/06/26
CSS Houdiniを味見する

2018/06/25
不確実性を考慮した時系列データ予測

2018/06/20
Google Colaboratory を自分のマシンで走らせる

2018/06/18
Go言語でWebAssembly

2018/06/15
カブクエンジニア開発合宿に行ってきました 2018春

2018/06/08
2018 年の tree shaking

2018/06/07
隠れマルコフモデル 入門

2018/05/30
DASKによる探索的データ分析(EDA)

2018/05/10
TensorFlowをソースからビルドする方法とその効果

2018/04/23
EGLとOpenGLを使用するコードのビルド方法〜libGLからlibOpenGLへ

2018/04/23
技術書典4にサークル参加してきました

2018/04/13
Python で Cura をバッチ実行するためには

2018/04/04
ARCoreで3Dプリント風エフェクトを実現する〜呪文による積層造形映像制作の舞台裏〜

2018/04/02
深層学習を用いた時系列データにおける異常検知

2018/04/01
音声ユーザーインターフェースを用いた新方式積層造形装置の提案

2018/03/31
Container builderでコンテナイメージをBuildしてSlackで結果を受け取る開発スタイルが捗る

2018/03/23
ngUpgrade を使って AngularJS から Angular に移行

2018/03/14
Three.jsのパフォーマンスTips

2018/02/14
C++17の新機能を試す〜その1「3次元版hypot」

2018/01/17
時系列データにおける異常検知

2018/01/11
異常検知の基礎

2018/01/09
three.ar.jsを使ったスマホAR入門

2017/12/17
Python OpenAPIライブラリ bravado-core の発展的な使い方

2017/12/15
WebAssembly(wat)を手書きする

2017/12/14
AngularJS を Angular に移行: ng-annotate 相当の機能を TypeScrpt ファイルに適用

2017/12/08
Android Thingsで4足ロボットを作る ~ Android ThingsとPCA9685でサーボ制御)

2017/12/06
Raspberry PIとDialogflow & Google Cloud Platformを利用した、3Dプリンターボット(仮)の開発 (概要編)

2017/11/20
カブクエンジニア開発合宿に行ってきました 2017秋

2017/10/19
Android Thingsを使って3Dプリント戦車を作ろう ① ハードウェア準備編

2017/10/13
第2回 魁!! GPUクラスタ on GKE ~PodからGPUを使う編~

2017/10/05
第1回 魁!! GPUクラスタ on GKE ~GPUクラスタ構築編~

2017/09/13
「Maker Faire Tokyo 2017」に出展しました。

2017/09/11
PyConJP2017に参加しました

2017/09/08
bravado-coreによるOpenAPIを利用したPythonアプリケーション開発

2017/08/23
OpenAPIのご紹介

2017/08/18
EuroPython2017で2名登壇しました。

2017/07/26
3DプリンターでLチカ

2017/07/03
Three.js r86で何が変わったのか

2017/06/21
3次元データへの深層学習の適用

2017/06/01
カブクエンジニア開発合宿に行ってきました 2017春

2017/05/08
Three.js r85で何が変わったのか

2017/04/10
GCPのGPUインスタンスでレンダリングを高速化

2017/02/07
Three.js r84で何が変わったのか

2017/01/27
Google App EngineのFlexible EnvironmentにTmpfsを導入する

2016/12/21
Three.js r83で何が変わったのか

2016/12/02
Three.jsでのクリッピング平面の利用

2016/11/08
Three.js r82で何が変わったのか

2016/12/17
SIGGRAPH 2016 レポート

2016/11/02
カブクエンジニア開発合宿に行ってきました 2016秋

2016/10/28
PyConJP2016 行きました

2016/10/17
EuroPython2016で登壇しました

2016/10/13
Angular 2.0.0ファイナルへのアップグレード

2016/10/04
Three.js r81で何が変わったのか

2016/09/14
カブクのエンジニアインターンシッププログラムについての詩

2016/09/05
カブクのエンジニアインターンとして3ヶ月でやった事 〜高橋知成の場合〜

2016/08/30
Three.js r80で何が変わったのか

2016/07/15
Three.js r79で何が変わったのか

2016/06/02
Vulkanを試してみた

2016/05/20
MakerGoの作り方

2016/05/08
TensorFlow on DockerでGPUを使えるようにする方法

2016/04/27
Blenderの3DデータをMinecraftに送りこむ

2016/04/20
Tensorflowを使ったDeep LearningにおけるGPU性能調査

→
←

関連職種

Recruit

バックエンドエンジニア(Python・Go)

業務内容

当ポジションは弊社Webサービスのバックエンド機能設計及び実装を担当します。 サービス毎の開発チームで2週間スプリントのスクラム開発を実施しています。 週次で開発チームミーティングを実施し、実装設計の相談や工数見積もりを行います。 全ての開発コードはレビューと自動テストによって品質を保っています。 また、リファクタリングやフレームワークのバージョンアップも開発フローに組込み、技術的負債を放置しない開発を目指しています。

フロントエンドエンジニア(TypeScript)

業務内容

当ポジションは弊社Webサービスのフロントエンド機能設計及び実装を担当します。 サービス毎の開発チームで2週間スプリントのスクラム開発を実施しています。 週次で開発チームミーティングを実施し、実装設計の相談や工数見積もりを行います。 全ての開発コードはレビューと自動テストによって品質を保っています。 また、リファクタリングやフレームワークのバージョンアップも開発フローに組込み、技術的負債を放置しない開発を目指しています。

インターン(Webエンジニア)

業務内容

業務から独立した、調査・研究系のタスクをおまかせしています。コードレビュー、 社内での報告会、 ブログ記事執筆を通して着実にスキルアップしていただくことを目指しています。 (希望があれば、プロダクトの開発業務もおまかせします。)

→
←

お客様のご要望に「Kabuku」はお応えいたします。
ぜひお気軽にご相談ください。

お電話でも受け付けております
03-6380-2750
営業時間:09:30~18:00
※土日祝は除く