ディスカッション (11件)
Supabaseの認証機能からClerkへの乗り換え、あるいはその先を見据えた「より良い認証システム」の構築について議論しましょう。
少し前のSupabase移行に関する記事も面白かったよ。長期的なエンジニアリングの意思決定について、誠実で質の高い記事は貴重だから、ぜひブログを続けてほしい!
やあ、Better AuthのBereketです。Better Authはまさにこの課題を自分自身で解決するために作り始めて、それが後に会社になったんだ。他の人たちが同じように価値を感じてくれているのを見ると、いつも嬉しくなるよ :) まだまだ改善の余地があるから、どうすれば良くなるかぜひ教えてほしい。
ClerkとBetter Authを比較するのは、ある意味で不公平かもしれないね。一方はサービスで、もう一方はライブラリだから、リンゴとオレンジを比べるようなものさ。スタックに統合するサードパーティサービスは負債になるし、ライブラリも程度は低いとはいえ同じ。サービスをライブラリで置き換える流れがもっと進んでもいい頃合いだよね。Better Authはそのやり方を示していると思う。フロントエンド、バックエンド、データベースに統合できるライブラリだし、それがこの製品の凄さだよ。
だからこそ、早い段階でLuciaを選んで本当に良かったと思ってる。彼らはライブラリのサポートを終了して、自分自身で認証を管理・ホストするためのドキュメントと小さなユーティリティに移行したんだ。認証は自分では管理できない恐ろしいものとして語られがちだけど、一週間かけてセキュリティや基本的なソルト化の仕組みを学んでみたら、中身を自分で完全に理解しているという自信が持てたよ。
Clerkを使ってるけど、かなり不満がある。まともなRBACがない(ロールが組織に紐付いていてユーザー個別に保存されないから、任意のキーバリューペアでメタデータを使わない限りグローバル管理者のような概念を作れない)し、ここ数週間から数ヶ月の間に何度かダウンタイムがあって、アプリ全体が止まることもあった。将来的に使うかどうかは考え直すレベル。
誰か賢い人教えてくれない?なぜPostgresのユーザーテーブルをわざわざサードパーティのプロバイダーに外出ししなきゃいけないんだ?HetznerのVMで自分のテーブルを保持しておくのがそんなに大変なことなの?決済データじゃなくて、ただの数フィールドのデータだろ?
複雑なシステムを構築する際に学ぶ厳しい教訓は、その信頼性は、重要な各パーツの信頼性を掛け合わせた「最小値」に収束するということ。
それどころか、可用性は各コンポーネントの積になるからもっとひどい話だ。もしソフトウェア、認証レイヤー、クラウドプロバイダーの可用性がそれぞれ99%で、どれか一つでも止まればサービス全体が停止するなら、最終的な可用性は97%にまで下がる。そんなコンポーネントが11個もあったら、可用性なんてあってないようなものだよ。
だからこそコンポーネントを減らして、信頼できるソリューションを選ぶことが大事なんだ。チームがその方針を選んだことを嬉しく思うよ。
「バイブコーディング」でどうでもいい場合を除いて、認証は絶対に外注しちゃダメ。もしどうでもいいなら、そもそも認証なんて入れるな。自分一人でやるか、データベースのパスワード検索を適当に書けばいい。
最後に、自然界の掟を言っておくよ。
VC(ベンチャーキャピタル)から資金を得たソフトウェアは、とことん搾り取られる。今日じゃないかもしれないし明日でもないかもしれないが、10年か20年後、熱いジャガイモ(過大評価された製品)がたらい回しにされて、最後に行き着いた所有者が大損する番になる。すでに10倍の利益を得た連中が、高値で売り抜けた後にね。
Clerkの価格設定を見れば、それが証明されてるでしょ。
ここで認証を自作することを推奨するコメントが多くて驚いたよ。ここ何年も「認証は絶対に自作するな」としか聞いてこなかったからね。
それじゃあ、批判を浴びるのを覚悟で言わせてもらうと、自分は認証コードを自作したよ。手間がかかるし退屈だったけど、ロケット科学でもないし、普通にうまく動いてる。自作がダメなケースがあるのは認めるけど、これは「認証は自作するな」という合唱に対する反論だ。
コードのすべての行を把握していたおかげで、あるクライアント向けに位置情報機能を追加したり、別のクライアントの要件に合わせてログ機能をカスタマイズしたりできた。一番良かったのは、遥かに巨大な競合相手に対して、古代のレガシーシステムとの統合を可能にして勝てたことだね。
「GoTo文は有害」とか「DRY」「YAGNI」と同じで、あれらは立ち止まって考えさせるにはいい格言だよ。でも、絶対的なルールじゃないんだ。