この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、加藤です。
AWS Summit Tokyo 2019 2日目の D2-04 で行われたセッション「Serverless/AppSync によるモバイル開発の今」のレポートを書きましたのでご覧頂ければと思います。
はじめに
スピーカーはAmazon Web Services, Inc. Mobile Principal Specialist SA Steve Johnsonさんと株式会社Gunosyの山本 舜さんです。
<セッション説明文>
モバイル開発向けのマネージドサービス AWS AppSync を使えば、リアルタイムのDB更新、インタラクティブなコミュニケーション、オフライン対応を可能にするモバイルアプリを GraphQL ベースで構築できます。サーバーレスサービス群（DynamoDB、Lambda、Cognito）との組み合わせで広範囲の要件に対応可能で、AWS資産を活用するのに最適です。本セッションでは AppSync を中心としたモバイル開発の生産性をご紹介するとともに、国内のお客様によるゲスト登壇を予定しています。
レポート
アジェンダ
- Serverlessとは
- AppSyncとは
- グノシースポーツとAppSyncについて
- ライブコーディングデモ
Serverlessとは
- Serverlessは次の特徴を持つものである
- インフラのメンテが不要
- オートスケールする
- 価値に対して支払いを行うものである
- 利用した時間分だけ支払う（Pay-as-you-go）
- ハードウェアではなくてスループットに支払うものと言える
- 高可用性・セキュアである
AppSyncとは
- AppSyncとは
- AmazonのマネージドGraphQLサービスである
- GraphQL APIとREST APIの違い。例えばどのようなものがあるか？
- 「post」「comments」「authors」の三つの種類のデータを取得する機能をAPIで提供したいケースがあったとすると、
- REST APIの場合
- /post /comments /authors それぞれに1つづつエンドポイントを用意することになり、3回もNWコールが必要
- GraphQL APIの場合
- /graphql 1回のみNWコールが必要
- REST APIの場合
- 「post」「comments」「authors」の三つの種類のデータを取得する機能をAPIで提供したいケースがあったとすると、
- GraphQLのオペレーション
- Query：取得
- Mutations：変更
- Subscriptions ：通知
- リアルタイムにMutationの通知を取得する（これが特徴！GraphQLを使う理由は主にここにあるでしょう）
- AppSyncの主な特徴のまとめ
- マネージドサービスであること
- データソースの連携先が豊富なこと
- Amazon DynamoDB
- Amazon Aurora
- Elasticsearch
- AWS Lambda
- 任意のHTTP Endpoint
- Subscribeによってリアルタイムで変更通知を受けられること
グノシースポーツとAppSyncについて
このパートから山本さんにバトンタッチ
- 山本さんについて
- グノシー開発部マネージャ
- Android・Kotlinを使った開発
- AppSyncフルに使い グノシースポーツ というアプリを制作
- グノシースポーツって？
- 「もっとスポーツを好きになれる」がコンセプトのアプリ
- 好きなチームの情報をリアルタイムに届けるというもの
- 機能について
- チームをフォローすることで試合結果のPush通知を受け取れる
- 現在行われている試合のスコアをリアルタイムに表示することができる
- 等
- AppSyncの準備に必要な三つのこと
- データソース
- スキーマ定義
- マッピングテンプレート
- リクエスト
- レスポンス
- この三つ、用意すればサーバが建てられる
- なぜAppSyncを採用したのか、どう活用したのか
- なぜ？
- リアルタイム更新を行いたかった
- スキーマファーストで開発を進めたかった
- 複雑かつnestedなデータの取得ができる
- リアルタイム更新を行いたかった
- 従来の開発の課題
- バックエンド開発において、リアルタイム通信の実現のためには同様の処理を二つ書く必要が生じていた
- フロントエンド開発において、こちらも同様に処理を二つ書く必要が生じていた
- 初めはAPIのIFだけ決めてアプリ開発を早期に始めたい。ただ、進むにつれて仕様は変わっていくし、いつのまにか関係者内で仕様の認識はずれていく
- とはいえ仕様書のメンテナンスコストは高いのでメンテナンスは難しい
- リアルタイムデータのスキーマ共有はどうやるべきなのか？Swagger等で管理するのは難しい。
- UI変更のたびにAPIのインターフェース変更が起こってしまいがち
- 楽になったこと
- データ取得時にDynamoDBに書きこみするだけでリアルタイム通知が実現できる
- フロントエンド側でも対応は必要だが、Apollo のsdkを入れることで比較的簡単に実装できる
- 通常のクエリとリアルタイムのデータ取得を、一つのソースで実現できる
- Appsyncはスキーマファーストで進められる（逆に、スキーマが決まらないとそこから進めない）
- CloudFormationでGraphQlのスキーマを管理できる
- これにより最新版は常にGitにある、という運用が可能
- 従来のように同じようなソースを二つ用意するケースが減る
- DynamoDBはマネージドサービスなのでスケーリングの面も安心。
- データ取得時にDynamoDBに書きこみするだけでリアルタイム通知が実現できる
- AppSyncを使ってみてのTips
- GSIで頑張らずにElasticsearchに入れる
- 並び替えや部分一致に柔軟に対応できる
- 各CloudFormationテンプレ内で頑張らないようにする
- 1ファイルが長くなりがちなので、分割する
- GSIで頑張らずにElasticsearchに入れる
- ライブコーディングのデモ（ここからSteveさんにバトンタッチ）
- わずか数回のコマンド、数行の追加でreactのTODOアプリを動かすサンプルを10-15分程度で行なった。（時間の関係上、あらかじめ用意されているコンポーネントもあったが、短い時間でサンプルアプリを動かすところまでできるということは十分伝わる内容だった）
- コミュニティの紹介
- amplifyはオープンソースなのでAWSの社員以外も積極的に機能追加してくれている
- 詳細はgithub communityのウェブサイトを参照
- https://github.com/aws-amplify
- なぜ？
最後に
AppSyncが非常に便利で、かつサンプルをクイックに試せることがよくわかるセッションでした。
個人的には今回お話に出ていたようなリアルタイム性の高い情報を扱うモバイルアプリにはまさにぴったりだと感じました。
ただ、期待する機能やパフォーマンスを出すにはDynamoDBやElasticsearchなど、データソースの選択及び設計に注意する必要があるのかなと感じます。そういった難しいところは実際少なくなさそうですが、フロントとサーバ担当者間のAPI仕様のやりとりやHTTPリクエスト本数の削減など大きなメリットを得られる可能性があり、サンプルはクイックに試すことができるようなので、ぜひ一度試してみてはいかがでしょうか。
14
