HN 日本語サマリー

← 一覧へ戻る
インフラ・DevOps

スタートアップでAWS Cognitoを使った。もう二度と使わないだろう

I Used AWS Cognito for a Startup. I Wouldn't Do It Again (joshkaramuth.com)

11 pointsby speckx7 コメント

要約

著者はスタートアップでの認証システム構築にAWS Cognitoを使用した経験を語り、その複雑さ、ドキュメントの不備、Amplifyの破壊的なアップデート、ローカル開発の困難さ、カスタマイズ性の低さ、そして設定ミスからの復旧の困難さを詳細に述べている。最終的に、開発者体験を重視するツール選択の重要性を説き、Cognitoの利用を検討している読者には小規模なPoCの実施を推奨している。

全文翻訳

スタートアップの認証システムを構築し始めて3日後、何かが間違っていることに気づきました。セミコロンを1つ見逃した、というレベルの間違いではありません。「ドキュメントのあらゆるステップに従ったのに、パスワードリセットフローが間違った場所にリダイレクトされる」というレベルの間違いでした。ドキュメントは12個のタブで開いていました。コードサンプルをコピー&ペーストしました。この悪夢を経験したことがあるような話し方をする人のチュートリアルさえ見ました。そういうことです。私は以前にも認証を実装したことがあります。Auth0と格闘し、Firebase Authを使いこなし、さらには自慢できるものではありませんが、機能したカスタムJWTシステムも自分で構築しました。そのため、スタートアップで認証が必要になり、チームがCognitoに傾いたとき、「AWSエコシステムに既にあり、月間アクティブユーザー50,000人までは無料だから」という理由で、私は「どれほど悪いことがあるだろうか?」と思いました。私はすべてを後悔しています。 ドキュメントは5人の異なる読者のために一度に書かれたかのようでした Cognitoのドキュメントを読むのは、3つの別々のマニュアルを持ってきて、それらをミキサーに入れ、風味付けに古いStack Overflowの回答を振りかけたような気分です。AWSは同時にあまりにも多くのオーディエンスにサービスを提供しようとしています。基盤となるIDプロトコルを理解したいエンタープライズアーキテクトがいます。ログインフォームが欲しいだけのフロントエンド開発者がいます。ネイティブSDKを必要とするモバイル開発者がいます。そしてドキュメントはすべての人にすべてであろうとしますが、それは結局誰にも役立たないことになります。私は「Cognitoカスタム属性の検証」を検索して、私がまだ存在を知らなかった他の4ページを既に読んでいることを前提としたディレクトリスキーマに関する段落から始まるページにたどり着きました。明確な線形パスはありません。それはハイパーリンクと祈りのウェブです。そしてコード例。ああ、コード例。その半分は古いJavaScript SDK用です。いくつかはAmplify v1 APIを参照しています。他は生のAWS SDKを使用しています。ドキュメントは、どのバージョンについて話しているのかを常に明確に教えてくれないため、あなたはインポートステートメントを使って探偵のように振る舞うことになります。 Amplify v6が私を裏切った日 バージョンと言えば。JavaScriptライブラリの状況についてお話ししましょう。これは本当に私を不意打ちしました。私たちが構築を始めたとき、Amplifyはバージョン5でした。私は認証フローを書き、テストし、コミットし、他の機能に進みました。数週間後、バグを修正するために戻ったところ、コンソールにいくつかの非推奨の警告があることに気づきました。問題ないと思いました。最新バージョンに更新するだけです。皆さん。Amplify v6は、いくつかのメソッドシグネチャを変更しただけではありませんでした。Cognitoとの対話方法を根本的に再設計しました。私がそれらを中心にUIフロー全体を構築した関数はなくなっていました。置き換えられました。消滅しました。移行ガイドは技術的には存在しましたが、ランドマークの半分が欠けている宝の地図のように感じられました。私はコードを書き直しました。リファクタリングではありません。書き直しました。本番環境で完全に機能していた認証ロジックは、ライブラリのメンテナーが古いAPIはもはや推奨されるパスではないと決定したため、再構築する必要がありました。それはアップグレードではありません。それは人質状況です。 ローカル開発は特別な種類の苦痛です Cognitoに関する面白い事実があります。それはクラウドベースです。知ってましたか。しかし、実際には、ローカルインスタンスを起動してオフラインで認証フローをテストすることはできません。常に実際のAWSエンドポイントに接続しています。さて、サーバーレスオフラインプラグインやローカルCognitoエミュレーターのようなツールがあり、このギャップを埋めようとしています。しかし、それらはメンテナンスと忠実度のレベルが異なるコミュニティプロジェクトです。AWSからの公式な話は基本的に「クラウドに対してテストする」ということですが、飛行機に乗っているとき、インターネットが不安定なとき、またはネットワークラウンドトリップを待たずに迅速なイテレーションサイクルを望むときを除けば、それは素晴らしいアドバイスです。私は、実際の環境と完全に一致しないローカルモックを設定するために、恥ずかしいほどの時間を費やしました。これは、ローカルでバグが潜り込み、ステージングで表示されることを意味しました。ローカル開発の目的は、問題を早期に発見することであり、Cognitoはそれに積極的に反対します。 カスタマイズしたいですか?ロゴが私にできる最善のことです これは痛かったです。Cognitoが提供するホストUIは機能的です。それはそこにあります。ほとんどの場合、機能します。しかし、それがAWSサービスのコスチュームを着たものではなく、あなたのブランドのように見せたいのであれば、あなたは悪い時間を過ごすことになるでしょう。ロゴを変更できます。コンソール経由でいくつかのCSSを調整できます。しかし、レイアウト、構造、全体的な雰囲気はどうでしょうか?それはAWSの家であり、あなたは部屋を借りているだけです。基本的なカスタマイズ以上のものが必要な場合、コミュニティからのアドバイスは通常「SDKを使用して独自のUIを構築する」です。それは結構ですが、その時点で、ホストUIは具体的に何を節約してくれているのでしょうか? 私の精神を打ち砕いたメールのみの設定 ラップトップを窓から投げ捨てそうになった瞬間をお話ししましょう。私たちのアプリはメール認証のみを必要としていました。ユーザー名はありません。ユーザーはメールアドレスでサインアップし、それを検証し、パスワードを設定します。簡単なコンセプトですよね?そこで、Cognitoユーザープール設定に入り、メールアドレスをサインイン識別子として使用するように設定しました。属性マッピングを設定しました。サインアップフローを作成しました。すべて順調に見えましたが、Cognitoは「メール」をコア属性、エイリアス、またはカスタム属性のいずれであるかによって異なる方法で扱うことを理解しました。そして、設定オプションはコンソールの複数の画面に分散しており、相互依存関係は完全に説明されていません。初期設定で間違いを犯しました。小さな間違いです。標準属性であるべきものをカスタム属性として設定してしまいました。問題ないと思いました。変更するだけです。変更できません。ユーザープール属性がカスタムとして作成されると、それは永遠にカスタムになります。そして、認証スキームが特定の属性間の関係に依存しており、その関係を間違えた場合、選択肢はほぼ次のようになります。ユーザープール全体を削除して最初からやり直すか、または正しい設定で新しいプールにユーザーを移行する複雑なプロセスを構築するかです。アクティブユーザーがいる本番アプリにとって、「削除するだけ」は実際には選択肢ではありません。そのため、あなたはユーザー移行をスクリプト化し、新しいプールでパスワードリセットを処理し、ユーザーに不便をかけて謝罪することになります。すべては、コンソールのドロップダウンが少し曖昧すぎたためです。 私が実際に学んだこと ただ文句を言いたくはありません。それは簡単です。「Cognitoは悪い」という以上のものに役立つ何かがあると思うので、この経験から私が学んだことを正直に伝えたいと思います。認証は手抜きをする場所ではありません。「既にエコシステムにある」という議論は魅力的ですが、そのツールが触れるたびにあなたを不幸にするなら、エコシステムの近さは関係ありません。無料ティアの価格設定は魅力的ですが、ドキュメントと格闘したり、APIの変更のためにコードを書き直したりするのに費やされたエンジニアリング時間を計算するまでです。次回は、AWSサービス統合の利便性ではなく、開発者体験に基づいたツールを選択します。Cognitoの問題をデバッグするのに費やした時間は、有料認証プロバイダーの数年分を賄うことができたでしょう。そして、私たちはより少ない深夜のピザを消費して、より速く出荷できたでしょう。もしあなたがあなたのプロジェクトのためにCognitoを評価しているためにこれを読んでいるなら、私はあなたに何をすべきか言うつもりはありません。しかし、私はこう言います。まず、小さな概念実証を構築してください。些細なものではないもの。カスタム属性とメール検証とパスワードリセットフローを備えたもの。それがどのように感じるか見てください。時間を計ってください。終わったときに開いているドキュメントタブの数を数えてください。その数が20を超える場合は、再考するかもしれません。ちなみに、私はこのプロジェクトでまだCognitoを使用しています。今更取り除くには遅すぎます。しかし、AWSコンソールを開いて、そこにユーザープールがあるのを見るたびに、私は小さく、静かな恨みを感じます。皿を洗わず、あなたのものを「借り」続ける古いルームメイトのように。その感覚を知っているでしょう。 それを成し遂げる開発者が必要ですか? この投稿があなたの問題を解決するのに役立ったなら、私たちが一緒に何を作れるか想像してみてください!私はPython、Django、Typescript、そして最新のWebテクノロジーに精通したフルスタック開発者です。