Amplify って実際どうなの？開発経験者がデメリット・メリットをまとめてみた😎

こんにちは！

Amazon Web Service のオンラインサミットでも取り上げられている「 Aws Amplify 」は、Aws インフラの構築、CRUD の API の自動生成、フロントエンドへの SDK 提供など、開発初期を圧倒的に効率化させてくれます。

スタートアップをする際にはかなり有用なツールです。

ただ、ここ最近触り倒した結果、良いところ・悪いところの両方が見えるようになってきたので、これから Amplify を採用検討している方へ本記事をシェアします。

Amplify のデメリット

一言で言えば、制約事項が多いです。
もし制約事項を超えるような要件が発生した場合には、正直作り直しを覚悟しないといけません。Ruby や Laravel の開発では、多少フレームワークでサポートしていない内容でも力技で解決できますが、Amplify の場合はその力技が非常に辛い場面に遭遇するでしょう。（ でも逆に使い所によっては非常に強力なフレームワークだと言えます ）

開発時に高確率でハマるポイントを簡単に列挙します。

• スキーマを定義するファイルへ @key で GSI 貼り付けは後から追加できない
• ElasticSearch を使用して検索を構築は後から追加できない（ 厳格にはインデックス手動で貼り付ければいけます ）
• 制約をはみ出ようとするときに Amplify の自動生成するファイルへ手を加えることができない（ 個別にやるしかない ）
• ソート関係を実装する際は検索結果総件数は ElasticSearch を使用しないと取得できない様子

特に最も警戒しないといけないのは、ソートの実装です。公式の Issueを見るとちらほら見かけますが、例えば総件数の取得、Enum ソート指定時、ページネーションを途中の番号から開始するなどの際に思うように開発できないケースが多数です。

Amplify を用いた検索開発の際は、必ず事前に必ず下記を確認し、少しローカルで触るなど検証してからプロジェクトへ導入しましょう。

• どのようなデータ型で検索するのか
• 検索条件は何なのか（部分一致なのか完全一致なのかなど）
• 複合検索の有無
• ソートに指定するキーの有無
• ページネーションの要件
• 検索総件数の取得は必要か

正直なところ、出始めのフレームワークなのでまだまだ不完全さは否めないです。

もう一点、最後に Amplify 開発前に抑えておかないといけないポイントとして、Amplify は SSR が行えません。つまり、SEO が命のアプリケーションでの利用は確実に控えることを推奨します。スマフォアプリや会員限定コンテンツを扱う WebSPA、業務アプリでは利用を検討して良いかもしれません。

Amplify の使いどころ・メリット

逆に、下記のようなプロジェクトではかなり力を発揮すると思います。

• 先々リプレース前提で作業を進めることが可能
• 直近の素早いリリースを何よりも最優先したい
• スタートアップまたは新規事業である
• 既存プロダクトは存在せず完全にど新規の開発（ 既存DBを使い回すなどは Amplify では不可能に近い ）
• プロジェクトを進めていく中での仕様添削が可能である
• アジャイル開発・スクラム開発
• SEO 完全無視、検索エンジンの流入なんて気にしない

ポイントなのは、Amplify で構築した際は将来的にリプレースの選択が可能であるということ。

プロダクトが成長してきて機能要件が複雑になってきたタイミングで一度リファクタリングの名目でリプレースを検討する必要があります。

• シリーズAに入ってマネタイズができてきたので作り替え
• シード時期だけ一旦最速で作りきって資金調達後に改めて作り替え

こういった場合は、世界最強のフレームワークだと思います。開発速度で言えばあの Ruby on Rails を上回ります。（ インフラ構築も自動化できるので ）

まとめ

開発が盛んなフレームワークなので今後に期待したいですね。
SSR ができるようになれば、より多くのスタートアップが利用できると思います。
現状は、toB ならまだしも toC のプロダクトを開発しているプロダクトオーナーは採用しにくい印象です。

弊社の場合は、インハウスのプロダクトでSHIMBAを運営していますが、このような場合は Amplify は適していませんね。本音を言うと SSR できれば是非採用したかったです。

Amplfiy での開発に悩んでいる方は是非一度弊社へお問い合わせください！