個人的に思うAWS Amplifyのいいところ、いまいちなところ

ちょっとそんな話をする機会があったのでついでにまとめておく。技術的な内容というよりはポエムに近いなぐり書きなので甘い部分は多々あると思う。

前提

大前提としてあくまでも僕個人の感覚だし、自分の置かれている状況を踏まえての話なのでフラットな比較評価ではない部分は多々あるし、異論は多いにあると思う。そしてバイアスがかなりかかった意見でもあるとは思っている。

まず、このまとめの前提となる環境は以下のような環境だ。

  • GraphQLを使ったプロダクトではない
  • フロントエンドとバックエンドはそれぞれ別のエンジニアがいる
  • フロントエンドはReact、TypeScript、Next.jsあたり、バックエンドはPythonでコンテナ。つまりLambdaとかのサーバーレスではない
  • 一言でAWS Amplifyと言っているがこの記事で述べていることの多くはAmplify LibraryおよびAmplify CLIについて

あと、以前にも同じような話を書いています。

www.keisuke69.net

今回、限定的とはいえ改めてAmplifyを使う機会があったのでそのインプレッションも含めて記載する。今回使ったのはAmplify LibraryとAmplify CLIだが、一部Amplify Consoleについても言及している。まとまりなくて申し訳ない。

いいところ

  • フロントエンドの人だけでもサーバーレスなバックエンドをなんとなく作れる(とはいえ本当に?)
  • Amplify Consoleを使うと静的サイトはもちろんSPAやSSRのサイトも簡単に環境を作れる
  • ユースケースをもとにフロントエンドに機能追加ができること
  • AWS AppSyncでGraphQLなアプリケーションの場合はとても良い体験を得られる

いまいちなところ

  • 楽になるかと思いきやバックエンドとなるAWSコンポーネントが透けて見えるので嫌でも意識せざるを得ない
  • ビルディングブロックなAWSの各サービスの上に無理やり載せている感が強く体験としてそれほど良くはない
  • 便利関数とかが用意されているが、それはむしろAmplify LibraryとかではなくSDK自体で実装してほしい
  • ユースケースからはみ出た途端にどう扱えばいいかわからなくなる

AWS Amplifyは何であって何でないのか

実際のところ、以前に書いたときの印象と大きく変わることはない。やはり、改めて考えてみても基本的にはAWS AppSync使ってGraphQLをやりたい場合以外は不要だと思った。

ではAWS Amplifyはいったい何を目指しているのか。

これについて、個人的な意見を述べると複雑化しすぎたAWSを専門家不要で使えるようにしたいんだと思う。

特に今のAWSデベロッパー体験があまりよくない。各種マネージドサービスが乱立した結果、インフラの運用管理がなくなって楽になったように思える反面でアプリケーションサイドの人からは何をどう使えばいいのかわからない状態だと言える。これはAWSの各サービスはビルディングブロックであるという思想も相まって、やりたいことをどう実現すればいいのかわからないという状況に陥りがちだ。調べればいいんだけどアプリケーションサイドの人間にはAWSのような足回り部分に興味がない人も多いのではないだろうか。

ちなみにAWSがちょっと得意な僕であっても面倒に思うことは多々ある。AWS AmplifyはそんなAWSをバックエンド、ひいてはそれらを構成するビルディングブロックとなる各AWSのサービスを意識せずに特にフロントエンドのアプリケーションエンジニアに使いやすくするために存在しているのだと思う。

事実、使いやすくはなっているのだろう。ただしそれはAWS Amplifyが想定するユースケースの範囲を出ない限定的な範囲においてはということになると思う。

対抗としてGoogleのFirebaseが挙げられると思うが、正直なところFirebaseのほうが何倍も使い勝手はいい。もちろんFirebaseにはFirebaseの問題点もある。例えばSDKのサイズが大きいことなどはよく言われる。また、サービスの信頼性の観点でも言及されることが多い。これに関しては数年前はたしかによくDBが止まったりしていた記憶はある。しかも何時間もだ。ただし、最近ではそういったことは起きていないように思われる。記憶の範囲、かつ実際に自分がプロダクションとして使っている範囲に限った話ではあるが。 また、普通に使っていると遅いなと感じることも多い。特にFirestore。この話をするとうまく使えてない、正しく使えていないからだとい言われることが多いんだろうけれど。

では、Firebaseのほうが使い勝手がいいのはどういうところなのか考えてみる。FirebaseとAWSではなくFirebaseとAWS Amplifyから利用するAWSという感じで。

個々のサービス自体はAWSにも相当するものが多い。もちろんRemote Configのようなそもそも対抗が存在しないものもあるが。ただ、それ以上にSDKからサービスまでがシームレスな体験を得られていると思う。とても定性的で数値等の根拠ある指標で示せないのが心苦しいが、少なくともSDKから扱うにあたってSDKの使い方とサービスの使い方の両方を学ぶ必要はない。このあたりどう伝えようとしても誤解を生みそうだが、サービスの使い方=SDKの使い方になっているとも言えるかもしれない。

AWS Amplifyの場合、とあるサービスを使うにあたってそのサービスの使い方をしっかり理解しつつAWS Amplifyではどう扱えばいいのかを学ぶ必要がある。AWS Amplifyの想定するユースケースにドンピシャでAmpify CLIとAmplify Libraryだけで諸々が完結する場合はいい。だが、少しはみ出ようとすると途端にこうなる印象が強い。これが意外とストレスに感じる。

自分の場合、どうせ各サービスのことを個別にちゃんと理解する必要があるならば各サービスのプロビジョニングなんかもCDKなりで自分でコントロールすればいいって気になってくる。むしろ、こうなってくるとAWS Amplifyがやってくれることは余計なお世話感が強い。こっちはAmplify Libraryの用意するユーティリティ関数を使いたいだけなのにCognitoが登場してきたりね。

まとめ

基本的にはAWS AppSyncでGraphQLをやりたい場合以外は不要だと思う。S3周りの実装が楽になるかと思いきや逆に微妙な実装で自分たちのユースケースには合わなかったし、そもそもこのあたりの実装はやはりSDKでやってほしいという気持ち。

アプリケーションエンジニアが楽に利用できるっていう路線は諦めて、アプリケーションエンジニアにAWSをもっと知ってもらう方向に舵を切ったほうがいいのではないかとも思うがそれはさすがに余計なお世話か。

JS SDKでもっとHigh level APIを充実させてくれたら何も言うことはない。

©Keisuke Nishitani, 2023   プライバシーポリシー