公開日：2017-12-11
先週までアメリカ・ラスベガスで恒例のAWS年次カンファレンス re:Invent が開催されていました。弊社からは Yasutaka Oki が ガッツリ参加していましたので、このブログにもそのうち何か書いてくれるでしょう。今年も様々な機能・サービスが発表されましたが、今回は AWS AppSync について考察してみたいと思います。
（12/20追記: AppSync のプレビュー利用が承認されたので、試した内容をこちらへ投稿しました）
AppSync は簡単に言えば API を作るサービスです。AWS には既に API Gateway というサービスがあり、Lambda Function と呼ばれる 独自のプログラムコード（ユーザーロジック）を呼び出したり、あるいはプログラムを書かずに AWS のサービスや VPC内のサーバーへ中継することができます。弊社のように、いわゆる “サーバーレス” アプリケーション、マイクロサービスのインテグレーションを主体としていれば毎日のように扱っているサービスです。
API Gatewayと比較し AppSync は何が異なるかと言うと、API Gateway は REST APIを作るサービス、AppSync は GraphQL を用いた APIサービスだということになります。
なぜ、REST APIではなく、GraphQL といったものが必要だと言われるのかを考えてみましょう。
例えば、弊社が強みとさせていただいている kintone の場合、レコード操作系だけを取り上げても以下の REST APIを提供しています。
* レコードの取得（1件）
* レコードの一括取得（クエリで条件を指定）
* レコードの登録（1件）
* レコードの一括登録
* レコードの更新（1件）
* レコードの一括更新
* レコードの一括削除
* レコードの作業者の更新
* レコードのステータスの更新
* レコードコメントの一括取得
* レコードコメントの投稿
* レコードコメントの削除
もし、これから新たに開発していくサービスにおいて、kintone と同様にこれらの REST APIを提供する必要があるなら、一つ一つの APIをそれぞれ実装していくことになります。
また、「レコードの一括取得（クエリで条件を指定）」は “query” というパラメータに クエリ文字列（クエリ式）を記述して渡す APIですが、クエリ式に指定された任意の文字列を解釈・実行するエンジンが必要になります。この仕様が許されないなら、検索条件ごとに APIを作成したり、パラメータとして渡せるように実装することになります。
とにかく、サーバーサイドの開発者が実装工数をかけて APIサービス、サーバーを実装する必要があり、その実装が終わるまではクライアントサイドの開発者は APIのモックを使用して開発を続ける、仕様変更があれば都度調整するといった手間を強いられます。
GraphQL は、この課題への一つの答えとして facebook社が開発した API仕様です。
どんな機能が必要であっても “APIは 1つだけ”で、かつ、”サーバーサイドのコーディングが不要”です。
クライアント（アプリ）の開発者は、サーバーサイドの技術者を待たずに開発を進めることができます。
そして、この GraphQL APIをサポートする AWS サービスが AWS AppSync であり、アプリ開発者は AppSync を介して、これまで以上に容易に DynamoDB のデータへアクセスできるようになります。また、データの変更があれば通知を受け取ったり（Pub/Sub）、オフライン時用にキャッシュ機能を使うことが出来ます。これは、AppSyncが事実上の業界標準であるオープンソースのGraphQL実装 “Apollo” を用いて構築されており、Apolloが提供している機能と互換性を持つためです。同様のサービスとして Googleは以前解説したように Cloud Firestore 、あるいは その前身の Firebase Realtime Database といった独自仕様サービスを提供していますが、AWSは今のところ業界標準に沿って実装しているということになります。
少し説明が長くなり過ぎました。
次回は kintone内のカスタマイズ Javascript から 既に GraphQL APIを提供しているサービス “ GRAPHCOOL” にアクセスしてデータを取得する具体的なコードを解説します。
投稿者プロフィール
