サーバーエンジニアの下川です。突然ですが、AWS AppSync触りましたか？

昨年から「AppSyncがあればサーバーの工数が下がるらしい」「Firestoreにとって変わるものがついにAWSから！」の様な噂を耳にすることが多くなって来ました。 Fammではオンデマンド商品をいくつかユーザーに提供していることからもサーバーサイドの処理は不可欠となっており、新規機能開発でサーバーの工数の方がクライアントに比べて高い事もしばしばです。

そこで、AppSyncを入れてサーバーの工数が下がるなら導入したいと考えましたが、クライアントエンジニアに使い心地を聞かずには導入までは決められません。

ということで早速私が信頼するiOSとAndroidエンジニアを連れてコワーキングスペースで1日合宿して来ました。

AppSyncとは

・マネージドのGraphQLサービス

・データストアをDynamoDB、RDSが選択できる

・リアルタイムデータ同期

・オフラインでも使用でき、オンラインになったタイミングで同期を行ってくれる

簡単なイメージは以下の通りです。

AppSync

ここですごいのが、RDSをデータストアに選択できる点です。

RDSをデータストアに選択することにより、フロントに関わるAPIをAppSyncに移行し、現行のバッチ処理はそのままRDSを参照するの様な形を取る事もできます。

また、写真アップロードのアーキテクチャを以下の様に最小工数で変更できそうで、妄想が捗ります。

Upload

現在Fammの写真アップロードは、クライアントからS3へ直Uploadし、Lambda経由でServiceDBへ書き込んでいますが、アップロード完了をクライアントが検知するために自前でサーバーから通知を送っています。

AppSyncで同期されれば処理もシンプルになります。

妄想はこの辺にして実際触ってみます。

データストアの選択

データストアは、現状DynamoDBやAurora servelessを使用するのが設定もシンプルですが、Lambdaリゾルバーを設定することによりRDSインスタンスを使用することができます。今回は一番設定が面倒なLambdaを使用してのAppSyncの設定にトライしてみました。 (Fammでは現在Aurora serverlessは使用しておらず、現行のAuroraに組み込むために選択しました。)

チュートリアルは以下を参照ください。 https://docs.aws.amazon.com/ja_jp/appsync/latest/devguide/tutorial-lambda-resolvers.htmldocs.aws.amazon.com

成果

途中何度もハマりましたが、なんとか、6時間でRDS上のデータの読み書きまで成功しました。

しかし、この記事の本題はこれからです、クライアントエンジニアがどう思ったのか？インタビューをお送りします。

使ってみて実際どうだったか？

下川: 「触ってみてどうでしたか？」

おじさんA：「入りやすさはFirebaseの方が上かなぁ。具体的に言うと、チュートリアルに沿ってやっていればすぐできちゃう所は・・・。」

おじさんB：「AWSの仕組みがある程度わかっていないと認証とかはハマりそうだな、という所感はある。一方Modelの定義を自動生成してくれるのはGraphQLの良さだなと感じたかな。」

下川: 「Firebaseだとそこってどうなるのです？」

おじさんB: 「モデルは自分で手作りしてる。AppSyncというよりGraphQLの良さになっちゃうけど、Modelの自動生成は魅力的。」

下川：「ありかなしだとズバリどうですか？」

おじさんA & B: 「ありですね。既存の資産を使える意味でのメリットはかなり大きいと思う。」

下川：「DB移行しなくていいのはメリットありそうですもんね。」

おじさんA：「Fammだとアプリ起動時の写真と動画の一覧画面に使うのが適していそう。」

下川：(最初に妄想していた所・・・！)

おじさんA：「写真のアップロードの検知は、socketからの通知トリガでFetchし直ししたりしてるんだけど、そこが勝手にSyncされる世界はとても綺麗なんじゃないかと。」

下川：「それはサーバーサイドとしても通知してるの手間なので同感ですね。」

おじさんB：「新規で作る取得系APIはもう全部AppSync経由！ってしちゃうのもありだと思う。更新系はバリデーションもあったり面倒だから、まずは取得から、とか。」

下川:「確かに、GraphQLの設定で複数テーブルの参照もできるし、取得系APIを移行するイメージはわきますね。」

おじさんA:「サーバーエンジニア的にはどうでした？」

下川：「GraphQLのお作法周りが最初なれなくてかなりハマった・・・。んだけど、慣れて来たらかなり高速になってきて、これはすごいって感じでした。気になるのはバージョン管理とテストかな、テストはコンソールからも叩けたので自動化は簡単そうに見えた。」

下川：「最後に何かありますか？」

おじさんB：「AWSの新しいものが触れてたのしかったです。」

おじさんA：「うんうん。」

おつかれさまでした〜。

最後に

今回は6時間という短い中でAppSyncの検証とインタビューをしました。

クライアントエンジニア的にもAppSyncを取得系から導入していくのはアリという意見をいただけました。

現在、取得系のAPIでも実装工数がかかるものもあり、AppSyncを導入することで既存資産を活かしながら開発スピードが上がったり、リアルタイム性が向上してUXも上がるんじゃないか？と妄想しとてもワクワクしました。

今回はRDS for MySQLをデータストアに使用しましたが、Lambdaを挟むことで設定が煩雑になったので、これを機にAurora Serverlessに移行するメリットもあるのかと感じました。一方で既存資産をそのまま利用していくメリットもあると思うので、本格的に導入を検討する際は慎重に見極めたいです。

最後に、新しいサービスを一緒に技術検証できる時間を与えてもらえたこと、一緒にチャレンジする仲間がいることはとてもありがたいことだな、としみじみ思いました。