サーバレスアーキテクチャの選択肢として、AWSのAmplify、GoogleのFirebaseが有力な候補となっているのではないでしょうか。
実際にAmplify・Firebaseの両者に触れ、比較・検討して得られた知見をまとめました。
※直近プロダクトの開発にAmplifyを採用して進めてきたので、Amplifyを軸に記事を書いています。
#API連携
AmplifyとFirebaseとで異なる特徴のひとつにAWS AppSync（GraphQLをすぐに利用できるフルマネージドサービス）を利用できる点があります。
自前でGraphQLを構築するのは手間がかかりますが、AmplifyのAPIモジュールは「AWS AppSync」をサポートしているので簡単に構築できます。DynamoDBやLambdaとのアクセスもシームレスに行えるので非常に便利です。
以下はその他のAppSyncのメリット
- リアルタイムのデータアクセスと更新：Websocketを使ったSubscriptionハンドシェイクを実装できるので、データ更新をクライアントに対して即時に反映可能。
- オフラインデータ同期：オフライン時のデータキャッシュの管理機能が提供されている。
- アプリケーション内でのデータのクエリ・フィルタリング・検索：サーバー側とクライアント側両方でのフィルタリングが可能。
- エンタープライズセキュリティときめ細かなアクセスコントロール：IAMベースでアクセスコントロールが可能。
GraphQLやデータ同期のDelta Sync、アクセスコントロール周りを考慮すると、AppSyncの方がより幅広い開発に対応できそうです。
GraphQLの良さについて詳しく書くことは割愛しますが、Amplify・AppSyncによる恩恵でドキュメント作成に時間を費やす必要がなくなったことと、エンドポイントが1つになるので、クライアント側のリソースを節約できたのは大きなメリットになりました。
※Firebase・Firestoreはapolloライブラリを使用することで、GlaphQLの実装を可能にします。
#DB（ DynamoDB / Firestore ）
AmplifyのDynamoDBではAppSyncのサポートもあり、GraphQLのスキーマ定義で@connectionを使うことで他のモデルを参照できるようになっています（リレーションのようなことができます）。他にもスキーマの定義では@authでモデルへのアクセスを制限したり、operationsを指定すると読み取りのみの設定なども可能です。
また@modelを作ると、DynamoDBの作成をしてくれたりと、Amplifyはスキーマ定義１つのファイルでよしなにやってくれます。これに対してFirestoreは、rulesの管理が手間だったりします。Firestoreでは実現できないないことも、DynamoDBではAmplifyとの組み合わせで可能になり、Nosqlの普遍的存在になった気がしています。
Firestoreのアップデートも頻繁に行われているので、これからの新機能のリリースなど新たな動きに注目していきたいです。
FirestoreはこちらのQiitaの記事が参考になりました。
「Cloud Firestoreだけでサービスを作ることは不可能ではない」でもしんどい。
#Hosting
Amplifyにはホスティングの選択肢として、Amplify consoleとAmplify-CLIを利用した２つがあります。Amplify consoleには、Amazon CloudFrontが活用されており、コマンドひとつで簡単にデプロイすることができます。
このあたり、FirebaseのHostingと大差ないのですが、AmplifyはBasic認証をサポートしているので、コンソール上からの設定で簡単に導入できました。FirebaseではCloud functionを経由させるための設定とBasic認証用のコードを追加しなければなりません。
またAmplify consoleはCI／CDもできるので、静的WebサイトやサーバーレスWebアプリ・PWAのユースケースには良い選択肢となりそうです。
※FirebaseはCl/CD環境がありません。
#Auth（Cognito / Firebase Auth)
AWS Cognito と Firebase Authのそれぞれの違いについては、他の記事にもソースは豊富なので割愛しますが、触ってみた印象としてはFirebaseの方が、直感的インターフェースで分かりやすいと思います。
ただLambdaトリガーを組み合わせたメールの送信メッセージのカスタマイズ性などはCognitoの方が高いです。Firebaseの場合は、メールテンプレートの文言でカスタマイズできない部分があります。
#Storage(S3 / Firebase Storage)
Storageの基本的な部分は同じですが、違いとして印象に残っているはS3の「Presigned URL」の機能です。これはS3上にあるファイルを一時的に不特定多数に公開したい場合や、IAM Userアカウントを持っていない人に対して一時的にファイルのダウンロード／アップロードさせたい場合に効果があります。
FirebaseのStorageの場合は、このような機能で制限することなどはできません。
#その他
###AWS Pinpoint / Firebase Analytics
2019年10月に、Googleアナリティクスのモバイルアプリのレポートの提供が終了しました（WEBは継続）。代替案として「Google アナリティクス for Firebase」検討した方も多いのではないでしょうか。
Pinpointのデータは90日間までの保持となっているので、90日間以上経過しているログを参照するには S3 への Auto Export を有効化しておく必要があります。またイベントに関する情報は Amazon Kinesis に送信するように Amazon Pinpoint を設定することもできます（Kinesis は、他の AWS サービスからのデータをリアルタイムで収集、処理、分析できる AWS サービスです）
このあたりはアプリにAmplifyを採用していても、Firebase Analyticsは使えるので（逆も同様に）、運用チームとコンソール画面の操作性やOSのバージョン・属性などの取得できるデータの確認が必要です。
※Google アナリティクスSDK終了の理由としてGoogle社は、Google アナリティクス for Firebaseがより良い基盤と考えており、多額の投資をしているためと説明しています。
###devOps
Amplifyは複数環境のデプロイをサポートしています。
Firebaseは環境ごとにプロジェクトを作成する必要があり、切り替えるのにも少し手間がかかります。
Amplify・Firebaseはコマンドひとつでデプロイすることができますが、Amplify pushの実行時間はCloudFormationが間にあるためFirebaseと比べると時間が非常にかかっている印象です。
###サーバレス開発
Amplify・FirebaseはWEB、IOS、AndroidのSDKを提供しています。
AmplifyはReact、Vue、AngularそれぞれのSDKもあるので、WEBアプリの開発には嬉しいサポートですね。
#まとめ
Amplify、Firebaseの両方を触ってみての印象としては「AmplifyはFirebaseに比べて学習コストは高いが、安定したアプリケーションの構築と開発する上での小回りは非常に効く」ということが実感できるものでした。
Amplify・Firebaeの両者を比較し、Amplifyを採用するにあたり以下の点に重きをおきました。
- MFAでのセキュアな認証
- 大きめのAPI開発
- メンテナンス性
メンテナンス性においては、AmplifyはAPIの設計をschema.graphqlにまとめられるのでドキュメントの作成・更新の手間が大幅に削減できたこと、SDKのバージョンの固定もできる点などがありました。Firebaseの場合、バージョンのアップデート時に今まで使っていたコードが突然動かなくなるといったこともあり。。（このあたりは今後のアップデートで改善されていくはず）
※Amplify・Firebaseともにアップデートが活発なので、把握しきれていない部分あるかもしれません。更新された情報や誤り等ありましたらコメントいただけると幸いです。