私のスタックの現状（T3スタック3.0？）

ソフトウェア開発・プログラミング
この記事は約46分で読めます。

この動画は、T3スタックの創設者が現在使用している技術スタックの変遷と現在の構成について詳細に解説したものである。従来のT3スタックから大きく進化し、ConvexをデータベースとAPIレイヤーの中心に据え、認証システムや決済処理、ファイルアップロードなど各種サービスの選択理由と実装方法を説明している。React、Next.js、TypeScriptをベースとしながらも、モジュラーなアプローチで各コンポーネントを組み合わせる思考プロセスが示されている。

The current state of my stack (T3 Stack 3.0?)
My channel started with the T3 stack and it's been changing. A lot...Thank you Mobbin for sponsoring! Check them out at:
www.youtube.com

技術スタックの変遷と現在の状況

最近、わしのスタックがかなりバタバタしとるんや、気づいてた人もおるやろうけどな。このチャンネル始まってから見てくれとる人やったら分かるやろうけど、全部T3スタックから始まったんや。わしがビジネス作った基盤になったスタックやで、Pingっていうビデオコールアプリな。今でもコラボするときは全部これ使うとるわ。めっちゃうまくいったんや。

このスタックがめっちゃ気に入ったから、世界中の人と共有したかったんや。それでこのチャンネルが生まれたようなもんやな。こんなことになるとは想像もつかんかったし、わしのスタックがこんなことになるとも思わんかった。

せやから今回は、わしの現在のスタックがどんな状況になっとるか、T3スタックがどうなったか、そして今どうやって開発することを勧めるかについて、みんなと一緒に詳しく見ていこうと思うんや。昔とは全然違うし、わしが想像してた姿とも全然違うからな。

現在のスタックに対する満足度と変化

でもな、今のスタックにはめっちゃ満足しとるんや。開発がこれまでよりもっと楽しくて、もっとワクワクするようになったわ。今の状況にはめっちゃ満足しとるけど、みんなを驚かせる部分もあると思うで。

SQLをもうあんまり使わんくなったことから、Next.jsのサーバーコンポーネントから徐々に離れていっとることまで、そして一番重要なのはtRPCから離れとることやな。わしが辿り着いた場所はちょっと変わっとるんや。

でもな、この場所はめっちゃ楽しくて、雰囲気で書くコーディングともめっちゃ相性がええんや。これはわしの好きな開発の考え方にとってはクールなメリットやで。コードベース内のすべてがファイルやったら、どこかのダッシュボードの変な設定やなくて、AIがめっちゃ得意になるんや。変なページをナビゲートするよりもな。

動画の構成と目的

この動画では、わしが使ってるパッケージから、組み立ててるフレームワーク、統合してるサービス、そして最も重要な、アプリケーションとそのインフラを構築・設計するときのこれら全部に対する考え方まで、すべて含むで。

これは「こうしろ、さもなければダメ」っていう話やなくて、わしが自分のものを作るスタックを組み上げるときに、どうやって判断を下すかっていう話なんや。そして最も重要なのは、なんでFlutterがめっちゃ好きかっていうことやな。まじで、これはめっちゃ楽しい動画になるで。みんなと一緒にこれ全部深堀りするのがめっちゃ楽しみやけど、これらの秘密をタダで教えるわけにはいかんのや。まあ、教えることはできるけど、ちょっとは金を稼ぎたいからな。せやから今日のスポンサーからの一言があって、それからすぐに本題に入るで。

スポンサー紹介：Mobin

UIのモックから実際に動くアプリケーションを作るのは、今まで以上に簡単になったんや。お気に入りのAIツールにドロップするだけで、コードを吐き出してくれるからな。でも、正しいリファレンスポイントはどうやって見つけるんや？アプリケーションに新しいビューを追加しようとするときに、最適な出発点はどうやって見つけるんや？聞こえるほど簡単やないで。みんなも経験あるやろ。

Googleの画像を漁って正しいリファレンスを見つけようとしたり、スマホに15個もアプリをインストールして、このデザインの問題を解決する正しいインスピレーションを得ようと期待したりな。今日のスポンサーのMobinは、初めて試したときからめっちゃ驚かされたわ。広告読みの最中に実際に試してみて「うわ、これ必要やん」ってなったんや。

Mobinは1000以上のiOS、Android、ウェブアプリケーションから50万枚以上のスクリーンを集めた美しいコレクションを構築しとるんや。Uberみたいな大企業からT3 Chatみたいな小さな会社まで、たくさんの会社のデザイナーが使ってるで。そう、わしらにとってもめっちゃ便利なんや。わしの実際のアカウントを見せるわ、いつも使ってるからな。

いろんなカテゴリーがあって、アプリとサイトを行き来できる。ウェブサイト用の別セクションもあるんや、これはめっちゃええな。例えば、ショッピングアプリのインスピレーションが欲しいとしよう。現在のショッピングアプリにある様々なガイド付きツアーを見てみよう。ここではWalmartがスキャンの仕組みをどうツアーしてるか見れるし、下にスクロールしたらIKEAのショッピング体験とアプリがどうなってるかも見れる。これらから超速で学べるんや。

気に入ったものを見つけたら、Command+Cで画像をコピーして、選んだエディターにポップして、Command+Vで「これみたいにして」って言えば、そんな風にしてくれるんや。これがどんだけ便利かわかるやろ？雰囲気でコードを書く人でも、プロのデザイナーでも、その中間でも、良いリファレンスを持つことは今まで以上に重要やし、それを見つけるのはめっちゃ大変やねん。Mobinを使わんかったらな。

Mobinが月100ドルでも、わしは迷わんと思うで。でも10ドルしかせーへんのや。これは得られるものに対してとんでもない価値やで。めっちゃ驚かされた。これがデザインのインスピレーションにとって最高のソースやっていうのは間違いないで。インスピレーションを得てより良いアプリケーションを構築したいんやったら、soyv.link/mobinで今すぐチェックしてみてや。

スタックの構成要素の分解

まずはスタックの構成要素を分解してみよう。データベース、APIレイヤーがあるな。APIレイヤーはクライアントやサービスがデータベースのデータにアクセスして、読み書きできるようにするもんや。認証レイヤーもある。自分で作ることもできるし、パッケージを使うこともできるし、サービスを使うこともできる。クライアントフレームワークもある。

これは実際にクライアント上で動くコードと、それを定義するのに使うフレームワークやな。スタイルシステムもある。これはいくつか違うものがある。CSSの使い方のこともあるし、コンポーネントを直接定義する方法のこともある。パッケージ管理と、最近は一般的にワークスペース管理もな。

npmとpnpmがどんどんいろんなことをやるようになって、前はやらんかったこともやってくれる。パッケージ管理はめっちゃ複雑なものになったからな。それから追加のサービスもある。バックエンドホスト、データベースホスト、アナリティクス、それのホストもな。モノレポみたいなオプション的なものもいくつかある。だいたいこれで全部カバーできたと思う。言語もここに入れることができるけど、わしの考えは知ってるやろ。

TypeScriptでできることがTypeScriptやないんやったら、無責任やってる可能性がかなり高いで。どこかでクライアントコードが必要やし、両方に同じ言語を使えるんやったら、めっちゃクールやからな。まじで、全部にElixirって答えたいんやけど、無理やねん。現実的にならなあかん。これで分解したい要素は全部カバーできたと思う。

クライアントフレームワークの選択

クライアントフレームワークから始めよう。これは最近めっちゃ考えとることやな。現実的に言うて、まだReactを使うと思う。他のものがダメとかクールやないからやなくて、Reactは全部にサポートされとるからや。すべてのライブラリ、すべてのコンパイラー、すべてのバンドラー、すべてのエディター、すべてのAI雰囲気コーディングエージェント、すべてがReactをサポートしとる。

ウェブでできることやったら、ほぼ確実にReact用のパッケージがあるで。そういうもんや。どんな感情を持っても構わんけど、Reactほど組み合わせ可能で包括的なエコシステムは少ないんや。

でもこれはもうそんなに単純なことやないねん。Reactはただの一部やからな。全体の方程式やない。そして2つの違う方向に進むことができる。

明らかにGatsbyとcreate-react-appやな。この2つをどうやって選ぶか？明らかにわしは冗談言うとるで。本当の選択肢はNext.jsとViteや。そしてどんどん新しい挑戦者が近づいてきとる。Tanstack Startや。どっちの道に行くんや、疲れた旅人よ？

みんなわしのことは知ってるやろ。歴史的には、この道の1つに他よりもっと行ってたのは知ってるはずや。正直に言うと、まだそんな感じや。いろんな理由でNext.jsの方に引き寄せられるんや。その理由はすぐに話すけどな。でもTanstack StartとTanstackルーターのエコシステムを毎日どんどん見るようになってきた。

でもViteもめっちゃ良い状態やで。小さくて単純なものが欲しいだけなら、サンドボックスやサイドプロジェクトみたいに、静的にレンダリングされたホームページが必要ないものやったら、Viteがめっちゃ良いこともある。

せやからNext、Vite、Tanstackが主な選択肢やな。でも別の考え方を勧めたいんや。バンドラーやinitコマンドとしてやなくて、ルーターの違うパスとして考える方がええと思うねん。Next.jsはNext用のルーターやし、Tanstack StartのルーターはTanstackルーターや。Viteはたくさんの選択肢をくれるけど、現実的には選ぶ選択肢はReactルーターやな。

まじで、みんながWouterみたいなミニマルで強力なルーターをもっと使ってくれたらと思うで。Wouterはめっちゃ愛してる、めっちゃええソフトウェアやけど、みんな使わんねん。React Routerを使うんや。React Routerも最近はめっちゃ良い状態やしな。すべて理にかなってる。

静的ページの必要性による選択

せやから、欲しいルーターと同時に、欲しい生成的な詳細も選ぶ必要があるんや。これらの中から選ぼうとするときに最初に聞く質問は、静的ページが欲しいか？ということやな。

典型的なhomepage.comとapp.homepage.comみたいにできるで。homepage.comはWebFlowか何かのクソで作って、app.homepage.comはReactベースのアプリケーションにする。これはよく見るやろ。わしのコンテンツで話してるもんのほとんどで見ることになると思う。

もしこうするんやったら、WebFlowかAstroみたいなフレームワークか、WordPressでセットアップすることもできる。誰が気にするねん？これらを分離したら、どの部分を静的にして、どの部分を動的にするかについてあんまり考えんでよくなるんや。ホームページをSPAのVueアプリのコンテンツにしたくないからな。ホームページは正しいコンテンツが入ったHTMLファイルにしたいんや。絶対にそうしたい。

もし同じプロジェクト内でこれらを欲しいんやったら（わしはよくそうするんやけど）、Upload Thingみたいなものを見てみ。静的なホームページがあって、ここのride animationみたいなクールな動的パーツがたくさんあるけど、これは静的なHTMLページなんや。JavaScriptを切っても、まだロードしてコンテンツを表示するで。

でもダッシュボードに行ったら、もっと従来の動的アプリケーションになるんや。せやから、いくつかのページを静的にしたくて、アプリの違う部分に対して違うドメイン間での分割をしたくないんやったら、最善の選択は確実にNextかTanstack Startみたいなもんやな。

Tanstack Startはまだ初期段階で、パーツ間の詳細を整理しとるところやけど、めっちゃ速くそこに到達しとる。絶対に注目しといた方がええで。でも本当にSEOとかクソが全部整理された良いミニマルなホームページが欲しくて、同時に同じコードを使える動的アプリが欲しい、同じコンポーネント、同じすべてが使えるんやったら、そこで欲しい魔法は最も簡単にNext.jsでできるんや。

Next.jsの高度な機能：Multizone

せやから、静的ホームページと動的その他すべてが欲しいとか、ブログを静的なセットにビルドしてコンパイルしたいんやったら、すべて良い状態やで。もしそれでめっちゃ遠くに行きたいんやったら、わしがたぶん近いうちにセットアップするであろうものがMultizoneや。

MultizoneはNext.jsプロジェクト1つのより大きなサブパスの違うNext.jsプロジェクトを持てるようにしてくれるんや。せやから、3つの違うNext.jsアプリ用の3つの違うpackage.jsonを持てる。1つはブログ、1つはダッシュボード、1つはホームページで、それら全部が1つのNextアプリでMultizoneを通してルーティングされるんや。

つまり、ブログのビルド時間が動的アプリのビルド時間に影響しないっていうことや。信じられへんかもしれんけど、ブログのビルド時間の方がよく悪いんや。JavaScriptでMarkdownを解析するのがいろんな理由でクソやからな。でも要点は分かるやろ。

Nextにはいろんな静的さと動的さの変化の機会があって、もしこれを気にするんやったら、すでに解決されてるいろんな次元があって、めっちゃ有益なんや。

でも、この動画のこの部分で目がうつろになってる人がいても大丈夫や。Viteを使えばええねん。ViteとReact Routerはめっちゃええ組み合わせで、わしもサイドプロジェクトや単発のもので使うことがどんどん増えてる。めっちゃええツールセットやで。SEOを修正したり、良いランディングページを作ったりするときには助けにならんかもしれんけど、そうでなければめっちゃ簡単に作業できる。

せやから、この部分を理解したら、判断がめっちゃ簡単になると思うで。静的ページが欲しいんやったら、まだNext.jsを強く勧める。Tanstack Startについても考えるべきやな。React RouterとRemixのエコシステムはここではあんまり助けにならんと思う。

Remixの現状と選択指針

Remixは今めちゃくちゃ混乱してる。今の時点では全然賭けられへんな。すべてを変えようとしとるからな。React Routerはミニマルな深さでまだ大丈夫や。反対はしないけど、RemixはReact Routerチームが作ったNextの代替としてのフレームワークやけど、今のところは避けた方がええ。実際には次のバージョンでReactから完全に離れるらしいから。せやから、どうなるか見てみよう。

クールやな。せやから、この2つをどうやって選ぶかは理解してもらえたと思う。マーケティングページが欲しいならNext、そうでないならVite。簡単やな。どこに行く？上か下か？下の方がめっちゃ楽やと思うで。

スタイルシステム：TailwindとShadcn

みんなもわしのスタイルシステムが何かもう想像できるやろ。わしがスタイルについてどう考えてるかを分解した動画がたくさんあるからな。TailwindプラスShadcnや。

気をつけてや、わしらはShadcnをめちゃくちゃカスタマイズしとるけど、同じような違いや。何やってるか分かるやろ？Shadcnは3年前の以前のCSS動画でわしが文句言ってたすべてのことを解決してくれたんや。CSSの動作方法とスタイルシステムの振る舞いのめっちゃええ組み合わせや。そこでめっちゃうまく組み合わさってるんや。

パッケージ管理：PNPMの選択

次は、ここにいるから簡単やな。パッケージ管理。まだpnpmを使っとる。分かってる分かってる、bunの人たちよ。bunの人たちは大きなモノレポを持ってへんねん。bunはモノレポで楽しい体験やない。進歩はしとるけど、まだそこまでやない。

turbo repoみたいなものを使ってるときに、いろんなパッケージをバンドルしてる間にturbo repoとbunをうまく動かすのは、やる価値がない。正直に言うと、単一パッケージや単一package.JSONのもんでも、pnpmにどんどん手を伸ばすようになってきた。2つの違うコマンドを覚えて切り替えるのが嫌やからな。

昔、NANっていうパッケージがあったんを覚えてる。npmとyarnの組み合わせで、ディレクトリのロックファイルを見て、そのプロジェクト用のやつを使うんや。今はbunかpnpmかを使うプロジェクトに応じて使うbnpmが必要やな。

あ、AntFuがneeを持ってるし、neeもこれにめっちゃ良く動くと思うで。そう、neeがたぶんわしの欲しいもんや。ロックファイルを使って正しいパッケージマネージャーを使ってるかを確認する。neeを使ったらbunをもっと使うようになると思う。絶対に考えるべきやな。

要点は分かるやろ。モノレポサポートでpnpmを使ってるんや。まだnpmかyarnを使ってるんやったら、やめてくれ。必要以上に自分を傷つけてるで。

pnpmもbunも、インストールするパッケージをグローバルキャッシュにキャッシュしてくれるから、毎回インストールするときにネットワークリクエストする必要がないねん。パッケージを再インストールしたり、変更したり、複数のプロジェクトを立ち上げたりしてるんやったら、今コンピューターに3つ以上プロジェクトがあって、pnpmやbunを使ってないんやったら、無責任やってるで。

ストレートに言うで。せやから、時間やな。npmとyarnを殺せ。わしもnpmにもっと長くいすぎたわ。yarnからnpmに移ったんは十分良くなったときやったからな。今はずっとpnpmや。切り替えろ。

ホスティング：Vercelを選ぶ理由

次の部分は簡単やな。ただ言うで。別れたことは知ってるけど、まだVercelを使ってる。

プレビュー環境の動作から、ノードを諦めることなくサーバーレス環境でのfluid computeのパワーまで、他のところでやろうとしたらめちゃくちゃ面倒な小さなことをたくさん正しくやってくれるんや。他の選択肢やったらもっとたくさんの作業か妥協が必要やと思う。

Cloudflareの方が安くて、T3 chatの推論エンドポイントみたいな長時間動くエージェント的なワークロード用に若干良いパフォーマンス特性を持ってると思う。cloud workersは、前にあまりにもたくさんの動画で言ったように、Vercelがやってることより抽象化レベルが1つ高いからや。Vercel上のすべてのリクエストは、あなた専用のLinuxインスタンスに行くからな。

せやからLinuxコンテナレベルで仮想化されてるけど、Cloudflareでは何層もカーネルの上のV8の異なるサービスワーカーとして仮想化されてる。つまり、リクエストが他の何かが起こるのを待ってるからCPUが必要ないときに、他の誰かのリクエストが同じボックスの同じV8インスタンス上の他の誰かのコードに行って解決できるっていうことや。

つまり、Cloudflareはリクエストにかかる時間は気にしないんや。リクエストが使う計算量だけを気にする。つまり、OpenAI APIがトークンで応答するのを待ってるだけのAI推論みたいな長時間で低計算のもんにとっては、そのリクエストが20分かかっても関係ないんや。10分の1秒分しか請求されない。

このようなワークロードに対してはCloudflareの方が理にかなってるんやけど、ノードでもないねん。ノード互換性をどんどん良くしてると言ってるのは知ってるし、やってるけど、絶対にクソやってもいる。同時に、Cloudflare上でのデプロイプロセスは、まだVercelよりもコミカルに難しいんや。

Vercelにプロジェクトを置きたいんやったら、CLIも使わん。Vercelのホームページに行って、新しいプロジェクトボタンを押して、GitHubリポジトリをクリックしたら、もう立ち上がってる。それだけや。

Cloudflareでやろうと思ったら、1日分の作業が待ってるで。CloudflareのWorkerテンプレートから始めないんやったら、もうアウトや。Wranglerのスタート地点から始めないんやったら、グッドラック、楽しめや。

それでも、CloudflareがCloudflare PagesからCloudflare Workersへの移行を行ったとき、静的アセットの隣でAPIエンドポイントを提供してお互いを潰さないようにするのに通った地獄の量。3人のCloudflare社員がデバッグを手伝おうとしてくれた。全員間違ってたで。

そこにあるはずのないバンドルにランダムなハッシュを追加してる理由を理解するために、Wranglerのソースコードを読まなあかんかった。Wranglerで作業してる人たちよりも、わしの方がCloudflareのデプロイプロセスを理解してたポイントがまじであったんや。これを理解しようと必死やったからな。

価値がないって言ってるんやないし、みんなのいくつかのことには簡単やないって言ってるんやない。わしが言ってるのは、わしが作ってるソフトウェア、バックエンドとフロントエンドがあって、お互いに関係しなあかんもんは、かなりの努力なしではCloudflareでうまく動かんっていうことや。

FluidComputeとコスト比較

クソ、環境変数は2週間前まで動かんかった。文字通り先週まで、彼らの環境についての代替的な考え方を使わなあかん、ついに環境変数サポートを追加するまではな。

せやから、そのすべての摩擦に耐える気があるんやったら、Cloudflareは大丈夫やで。でもVercelも大丈夫や。そして今、fluid computeでの価格差があって、これについてはたくさんの動画で話したから、興味があってまだ見てないんやったら見てくれ。Vercelは自分でラムダを動かすより安いんや。

その発言がアホに聞こえるんやったら、fluid computeを理解してないから、その動画を見るべきか、他のもんの上により良いソリューションを構築できるってことを認めたくないかのどっちかや。前は最も高い左から最も安い右っていうコストのスペクトラムがあったとしたら、以前はVercel、Lambda、5ドルVPS、Cloudflareやった。

Fluid Computeで起こったクレイジーなことは、Vercelがここに移動したことや。多くの異なるワークロードでは5ドルVPSよりまだ高いけど、Lambdaよりは安いねん。なぜかというと、AWSでは1つのLambdaが1つのリクエストを解決するけど、Vercelでは1つのLambdaが生きてる間にできるだけ多くのリクエストを解決するからや。

彼らがその抽象化レイヤーを構築したんや。Vercelは今安くなった。多くの異なるスケールでめっちゃ理にかなってる。そしてノード、無限のスケールアップとダウン、信じられないプレビューデプロイメントとそこでの体験、その他話したすべてのことが欲しいんやったら、めっちゃ価値があるで。

まだ、好きに宣伝マンって呼んでくれ。Vercelはわしが話してきた個別企業よりも多くの金を使わせたで。以前のスポンサー取引で手にクソをつかまされてたからな。せやから、これを信じてるから言ってるんや。Vercelから離れることは悲しい日になるやろうし、正直に言うと重く検討してた。

T3 chatで直面してた継続時間でどんなにひどい請求になるかを見たとき、退出する準備をしてたんや。でもfluid computeが起こって、請求を90%下げてくれた。今はそんなに気にしてない。わかるやろ。

せやから、Vercelにいる。しばらくは続けるで。

データベース：Convexへの完全移行

今度は、過去数ヶ月間ずっと見てきた人は既に知ってるけど、そうでない人には大きな驚きになるかもしれんやつについて話さなあかん。DBホストとDBがある。これらはわしにとって今同じなんや。

上から始めよう。Convexにやられた。こんな日が来るとは思わんかった。4年前にあの連中にめっちゃ文句言ってたからな。以前はConvexの代わりに、全然違うセットのものを使ってた。

せやから、Planet Scale上のMySQLを使って、PrismaかDrizzle、主にDrizzleを通してアクセスしてた。それからtRPCでエンドポイントを定義してた。ライブ更新が必要やったら、PusherかWebSocketに入れて、それからクライアント上でReact Queryを使ってこれら全部をまとめてた。

Convex側では何も変えんかったことに注意してくれ。MySQLや他のSQLの代わりにConvexを使う。Planet Scaleや他のホストの代わりにConvexを使う。PresmaみたいなORMの代わりにConvexを使う。tRPCや他のAPI定義レイヤーの代わりにConvexを使う。ライブ更新レイヤー用のPusherの代わりに、組み込まれたConvexを使ってる。そしてReact Queryの代わりに、組み込まれたConvexのuse queryとuse mutationを使ってる。

クソ、違う名前にしてくれたら良かったのに。でもそういうもんや。いくつかクセがあるけど、ほとんどの場合はめっちゃ良い。特に、楽観的更新パスは彼らにとって信じられないほどや。

T3スタックからの脱却とその理由

こんなことをするとは思わんかった。なぜかというと、わしがT3スタックを好きな理由の大部分、そもそも作った理由は、そのモジュラーな性質やからや。要点は、欲しい部分を選んで、いらない部分は無視して、違うものが欲しい部分は変更できることや。そしてわしは全部をConvexに変えた。

これをまたConvex礼賛動画にしたくないし、そうしないのはめっちゃ難しい。まじで、最近パーティーでめっちゃ楽しいで。でも要点は分かるやろ。Convexが必要なところ全部に入れていこう。Convex、Convex。Convex層にないものが必要なときはまだtRPCを使ってる。正直、最近はそんなに起こらんけどな。

DBホスト、Convex。まあ、Convexである必要があるところ全部に当てはまったと思う。でも認証レイヤーについては考えてるかもしれんな。Convexには認証ないのか？あるけど、彼らはそれを嫌ってるんや。彼らとたくさん話した。彼らは自分たちの認証パッケージを誇りに思ってない。

なんとなく動くで。わしは動くようにできんかった。どれだけ彼らのせいでどれだけわしのせいかはわからんけど、他のほぼすべての選択肢を使う方がめっちゃ簡単やった。

認証レイヤーの選択肢

その選択肢を分解した方がええやろな。認証レイヤー。取れる主な2つのパスはサービスかパッケージや。完全に自分でやることもできる。それがどんなにアホかは理解してもらえると思うで。自分でやったら間違う認証の部分がたくさんあるからな。パッケージを使うべきや。

信じられへんかもしれんけど、わしは最近この両方をかなり深く使ってきた。パッケージには、DAXとSSTクルーによるopen authみたいな選択肢がある。彼らはopen codeも作ってる。next authもあって、今はAuth.jsとして知られてる。Auth.jsでは大変な目に遭ったで。最近は勧めん。

Lucia authもあったけど、今は死んだ。触ったらあかん。クールなドキュメント、学ぶべき良いものはあるけど、使ったらあかん。それから最も重要なのがBetter Authや。Better Authはめっちゃ良い。わしは投資家でもあるから、バイアスを考慮してくれ。すぐにもっと詳しく話すで。

サービス側では、Auth0がある。Auth0は使わんでくれ。でももっと良い選択肢があって、それもまた両方ともスポンサーや。ClerkとWorkOSや。この側が話しやすいから、ここから始めるで。

ClerkとWorkOSの比較

簡単に言うと、認証をできるだけ速く動かすことが目標で、組織管理、サブスクリプションと支払い処理、ユーザーがクリックしてすべての情報を出してプロフィールをカスタマイズしたりできるコーナーの小さなボタン、そういったタイプのものすべてを含む必要な良いものすべてが欲しいんやったら。認証について考えたくなくて、支払いとすべてが処理されて動くようにしたいんやったら、Clerkがあなたの生活をめっちゃ良くしてくれるで。

わしはまだほとんどのプロジェクトをClerkにデフォルト設定してる。新しいものを作って認証が必要なとき、Clerkがそこでの最も幸せなパスや。

せやから、支払いからユーザーが見るコンポーネントまですべてを処理してもらいたくて、実装したいもののほとんどに簡単なパスがあって、本当に良い取引が含まれてる合理的な価格（2回現れるまでユーザーがユーザー制限にカウントされないという事実のように）が欲しいんやったら。1回現れてその月の残りに再び現れなかったら、ユーザーセッションの最初の24時間は無料や。25時間後に現れたらカウントされる。でも1回サインインして二度とないなら、ユーザー制限にはカウントされない。めっちゃ寛大やな。

ランダムなユーザーの急増で金がかかるのを防いでくれるから、そのポリシーはめっちゃ好きや。

WorkOSの企業向け機能

WorkOSは企業の準備ができてたいときに勧める。あなたが企業会社やからやなくて、企業に売るかもしれんからや。SAMLとOctaとか、管理ポータルで処理してるすべての他のクソを扱いたいんやったら、チャンネルでたくさん広告を見たことがあるやろうけど、WorkOSがその会社やで。

あなたよりも認証を気にしてる会社と仕事したいときのソリューションや。認証をセットアップすることが仕事の人がいる会社が、自分の会社で使えるようにあなたのサービスに統合したいとき、WorkOSがそのクソ全部を処理する断然最も簡単な方法や。

せやから、始めたばかりでClerkに組み込まれたサブスクリプション機能がめっちゃ良いから支払いを処理してもらいたいなら、Clerkって言うで。まじで、T3 Chatを始めたときにあったらめっちゃ楽やったのに。組み込まれたコンポーネントから恩恵を受けて、最も重要なのは、アプリの構築に戻りたいなら。これらがClerkを選ぶ理由や。

WorkOSは少し違う。企業に売りたい。SAML、Octa、これら他のものすべてにうんざりしてる。そしてもちろん、OpenAI、Cursor、その他みたいなサイズまでスケールするソリューションが欲しい。そう、OpenAI、Cursor、その他めっちゃたくさんの会社がWorkOSを使ってる。Planet Scale、Vercel、わしらが話してる他のものたくさんが全部WorkOSを使ってる。

これでこの2つの間で決めるのがかなり簡単になることを期待してる。サービスルートを行きたいならな。でも物事を複雑にする新しいプレイヤーがいる。Better Authや。

Better Authの将来性

Better Authはめっちゃ興味深いソリューションや。一方では、next openauth等に匹敵するか比較できる、認証レイヤーを構築するためのより良いオープンソースのパッケージセットを意図してる。でも彼らはサービスを構築して収益化などを計画してるYCが支援したスタートアップでもある。

わしはBetter Authの未来にめっちゃワクワクしてる。だから投資したんや。彼らは何をしてるか知ってる。今めっちゃクールなものを構築してる。クラウドプラットフォームはない。Better Authを別のデータベース、たぶんアプリですでに使ってるデータベースに付けることが期待される。Betterは合理的に使うであろうほとんどすべてのデータベースで動く。

ほとんどのウェブフレームワークで動く。クソすべてのサポートがある。Betterはめっちゃ良いけど、ConvexやWorkOSみたいなホストされたプラットフォームがないから、他のホストされたプラットフォームへの統合が基本的にあなたの問題になる。つまり、Convexみたいなものにとっては、あなたの問題や。

ありがたいことに、これは作業されてる。ConvexもBetter Authも、ここでのハッピーパスを作ることに重く投資してるのは確実に知ってる。Convexについてめっちゃクールなことの1つは、データベースとAPIレイヤーで生きてほしい振る舞いの構造であるコンポーネントの概念や。コンポーネントって言うときは、Reactのものを意味してるんやない。似てるけど、ちょっと違う。

Convexのコンポーネントはワークプールのようなタスクを並列化したいけど一定量までしかない場合の振る舞いの構造や。10個のタスクしか同時に動けないようにしたいなら、彼らのワークプールコンポーネントをインストールできて、データベースにサブテーブルみたいなものを立ち上げてすべてを管理してくれる。

それはダッシュボードの小さなドロップダウンにあって、Convexクエリやミューテーションで使えるコードやロジックの部分も提供してくれる。ConvexのBetter Authパッケージは、コンポーネントを使ってConvexでBetter Authを実装してるんや。めっちゃワクワクする。

npm installして、app.config.tsファイルに2行コード追加したら、今Better Authと必要なテーブルとものすべてが、わしが何も維持することなくConvexに統合されるという考えや。めっちゃめっちゃワクワクする。今テンプレート作りたいなら、これが足りない部分やから。

Convexの開発体験

T3 Chatのコードベースみたいなものを取っても、PNPM install、PNPM run devで、まだConvexにサインインしてなかったら、「続けるにはConvexにサインインする必要がある」ってリンクがポップアップする。それをやる。わしのチームかどうかは関係ない。Convexプロジェクトのすべての設定はConvexフォルダーだけやからな。

わしのimage studioプロジェクトがここにある。わしのConvex設定がここや。モデル、わしのスキーマがある。プロジェクトのテーブル定義がここや。ただここにある。アクセスできる異なるモデルがここにある。これは全部、これらすべてによって実行されるソースコードなんや。

ここで足りない唯一の部分は、Convexエンドポイントを通して叩いてるサービス用のAPIキーやな。具体的には、この場合、わしのAI生成がすべて起こってるFalだけや。

これはすべてコードとして生きてるから、わしのConvexにアクセスする必要はない。AWSやこれら他のもののわしの設定にアクセスする必要はない。npm installとrun devを実行するだけ。ConvexのランダムなGitHubアカウントにサインインしたら準備完了や。

でも認証を追加したいとなったら、すぐにそんなに簡単やなくなる。認証をデータベース自体に欲しいんやったら、たくさんのスキーマを定義する必要があるし、認証をどこか他の場所に欲しいんやったら、ダッシュボードにたくさんの時間をかける必要がある。

コードファーストアプローチの重要性

わしのツールセットの尖った目標の1つは、構築するときにダッシュボードでの時間を避けることや。構築が終わってからアナリティクスダッシュボードですべての時間を過ごすのは構わんけど、プロジェクトを更新するためにUIをナビゲートする必要がないようにしたいんや。

わしがそれを嫌いやからでもあるし、ソースコードがすべての振る舞いのソースやからという理由でもある。でもAIもそれの方がめっちゃ得意やからでもある。Supabaseダッシュボードを雰囲気でコードしてみてくれ。

だからMCPを全部持ってるんや、変更する唯一の方法やから。そしてそれらのダッシュボードを持ったら、扱わなあかんコードベースにない状態のかたまりもある。その部分は特にわしを恐怖に陥れるで。プロジェクトを違う時間に実行して、コードベースに実際にはない設定のどこかに依存してるために完全に違う動作をする可能性があるなんて。それはまじに恐ろしいで。

わしがスタックを設計する方法の大部分は、そういうタイプのものを避けることなんや。でも今、認証はそういうもののうちの1つや。どこかから取得する必要があるから。ConvexプラスBetter Authは、わしがここで探してるソリューションを約束してくれる。すべての認証管理がConvexデプロイメントの一部になるだけや。

それがどういう見た目かはちょっとカオスや。ユーザーオブジェクトから来るかもしれんものを処理するために追加しなければならないすべてのフィールドを見てくれ。アカウント分離検証二要素認証、これすべては基本的にプロジェクトのすべてのユーザーに必要や。

わしが認証サービスを好きな理由の1つは、このクソ全部を扱わんでええからや。でもBetter AuthとConvexの統合がもっと安定したら、これはめっちゃめっちゃ良くなるで。そしてわしはめっちゃワクワクしてる。このコードのどれもあなたのコードベースに生きることもないからな。これは全部彼らのパッケージから来るだけや。

そしてこれらテンプレートのどれでもdev コマンドを実行してConvexを設定するときに、これらは全部自動的に定義される。

Better AuthとConvexの将来

せやから、近い将来、わしがcreate T3 appみたいなものを再びやって、それをもっと頑張るんやったら、Better AuthとConvexがもっと安定したハッピーパスになったときに起こると思う。そしてこれがConvexも賭けてるパスやっていうのも知ってる。彼らはもう自分たちの認証コンポーネントを維持したくないねん。

Better Authにそれをやってもらって、本当にハッピーな統合ストーリーを持ちたいんや。そして、もしStripeの部分も理解したら、めっちゃめっちゃ良くなるで。

支払いシステムの実装

ところで、支払い部分について話すべきやろな。構築したって、支払いもらえんかったら意味ないやろ？支払い。ストレートに言うで。Stripeを使ってないんやったら、無責任やってるで。

明確にするけど、必ずしもStripeを直接使うって意味やないで。他にもたくさん選択肢があるから。わしのCTOがAutumnにめっちゃ興奮してる。YCが支援した会社で、アプリで人々ができることと支払いできることのすべての価格とすべての設定をautumn.config.typescriptファイルとして設定させてくれて、それからdevとprod両方の設定とすべてのデータ管理、同期、ユーザーが良い状態にあることを確認することをあなたのために処理してくれるんや。

Autumnはめっちゃめっちゃ有望や。オープンソースでもあって、わしがStripe webhookで通ってきたクソ全部を処理してくれる。多くのあなたが知ってるように、Stripeで理性を保つ方法についての動画とGitHubリポジトリ全体をやった。

Stripeとの過去の経験

これがめっちゃうまく行ったから、StripeがCEOとの全社会議でわしを講演に招待してくれたんや。彼らはわしのフィードバックを真剣に受け取ってくれてるし、まだ何らかの作業をしてるのは確実やと思う。でもわしは待つことに疲れた。多くのあなたと同様にな。このプロジェクトについて無限の良いフィードバックをもらった。

5K以上のスターがあって、ほぼ毎日誰かがこれについて感謝して連絡してくる。正直、Stripeに起こった最高のもののうちの1つになった。今、正しくやるパス、webhookを管理するパス、物事の同期を保つパス、すべてがあなたのデータベースをめちゃくちゃにするのを防ぐパスがあるからな。めっちゃ良い。

アプリケーションデータの分離

一般的に言って、わしがアプリケーションDBを持ってるとき、そこにあってほしいデータは率直に言ってアプリケーションデータや。わしがアプリケーションDBに欲しくないものは、アプリケーションデータやないものや。それは認証データみたいなものや。次にアプリDBでクソセッショントークンについて考えなあかんときは、クソ農場に引っ越すわ。そのクソはもうやったで。それは別の場所の別の関心事や。

今T3 chatでは、アプリの他のすべてから完全に分離されたKVを通してopen authで認証してる。わしらの認証レイヤーは、トークンの受け渡しを管理するだけで、Cloudflare上で動く自分たちが所有する分離されたマイクロサービスや。そして他のすべてはConvex上のデータベースでT3 chat内で行われる。

将来的には、企業に売りたいし、そのパスがめっちゃ簡単になるから、たぶんWorkOSに移ると思う。でも今のところ、そのデータを遠くに保ってる。

支払いデータの分離戦略

今こんな話をしてる理由は、支払いデータについても同じことを思ってるからや。今、あなたのサブスクリプション状態、支払いの状態、すべてそれに関するデータは、T3 chat上のわしらのConvexデータベースに住んでない。すべてを簡単なKVに保ってる。ユーザーサブスクリプションの状態を使ってる。そしてwebhookが来たときはいつでも、それを更新する。

そしてユーザーがそれをリクエストして持ってないときはいつでも、ダブルチェックしてその時にKVに書く。これは全部Stripeの推奨事項に詳しく書かれてる。バニラStripeをやりたいなら、使わんくても読むことを強く勧める。実装方法が、当たるであろうすべての異なる面倒なエッジケースとバグとクソと合ってるかを確認するためやからな。Stripeのwebhookは、まあ、何かやからな。それ以上は言わんけど。

PolarとAutumnの選択肢

すべてそれを言ったけど、PolarとAutumnみたいなソリューションにますます興味がある。認証のクソと扱いたくないのと同じように、このクソとも扱いたくないねん。この両方はわしにとってめっちゃめっちゃ興味深いプロジェクトや。決定する前に少なくともこの2つを見ることを勧める。

この部分も気をつけてや。ユーザーが物に支払いをするのを難しくするソリューションは欲しくない。これはアプリの最も重要な部分や、支払いを管理することは。この部分を台無しにしたらあかん。余分にケアを置け。そして、テンプレートに何かを組み込むだけやないのはクソやねん。そんなに簡単やないから。でもするんやったら、あの連中をいじめて必要なことを何でもやらせることができるから、たぶんAutumnを入れる。

Clerkの支払いソリューション

関係なく、これらすべてはStripeの上に構築されてる。それに固執することを勧める。あ、そうそう、Clerkのここでのソリューションも良いで。せやから、まだ認証ソリューションを選んでなくて、ユーザーがサブスクライブする人で、めっちゃ直接的な一対一の関係みたいなものが欲しいなら、Clerkがそれをあんまりお金をかけずにめっちゃ簡単にしてくれる。本当に良い選択肢。チェックしてみて。

アナリティクス：PostHog

何が残ってるかな？アナリティクス。でかいやつやな。そしてわしの答えは、そんなにでかくない。PostHog。この連中をめっちゃ気に入ったから、スポンサーになるようにいじめたんや。PostHogを4年近く使ってる。フィーチャーフラグ、セッションリプレイ、その他製品構築に必要なすべてのオープンソースアナリティクスツールセットや。主にアナリティクスを使ってる。

実験とフィーチャーフラグの部分をたまに使うこともある。AIアナリティクスも好きやけど、既存のアナリティクス部分のラッパーがほとんどや。この連中にめっちゃ満足してる。他の選択肢はどれも好きやない。

PlausibleとPostHogの使い分け

plausibleでたまにやることもまだある。この連中もかなり気に入ってる。オープンソースでもある。Elixirベースで全部やから、クールやけど、ウェブアナリティクスだけやねん。そしてウェブアナリティクスと製品アナリティクスは全然違うものや。

製品アナリティクスは、何人のユーザーがこれらのフローを通って、どこで離脱するかを理解することや。ユーザーベースで何でも知りたいなら、製品アナリティクスが欲しいんや。一般的にどのページに人が行くか、一般的にどのソースから来るかを知りたいなら、plausibleみたいなものが理にかなう。

PlausibleはGoogle Analyticsみたいなもんの代替や。PostHogはmixpanel、amplitude、これらすべてのめっちゃ重いアナリティクスプラットフォームの代替や。

製品アナリティクスとウェブアナリティクスの違いを知らんなら、たぶん製品アナリティクスが欲しいんやろ。違いを知ってて、ウェブアナリティクスが欲しいことを知ってるなら、plausibleはめっちゃクール。ユーザーがサインインしないなら、たぶんplausibleが欲しい。ユーザーがサインインするなら、たぶんPostHogが欲しい。とは言え、PostHogも最近ウェブアナリティクス系のもんもたくさん作ってるから、選ぶのがもっと難しくなってる。PostHogで間違いはないと思うで。

セキュリティ関連：キャプチャとレート制限

キャプチャ、レート制限などについて続けよう。これについては意見があるで。他の人が聞いてきたから、ここに入れることにしたんや。まだhCaptchaを使ってる。どのくらい続けるかはわからんけどな。一般的に彼らと話してて変な感じがするんや。

T3 chat用の広告の割引をくれるような取引をめっちゃ切りたがってるんやけど、それは重複のない異なるビジネスやし、それを説明しようとしたら、わしに対して怒ったような感じになるんや。せやからそれは最悪やった。その上、良い体験にするために自分でめっちゃたくさんのクソを実装せなあかんかった。

そしてドキュメントが超不明確やった。偽陽性率はreCAPTCHAのときより大幅に低くなったし、統合はreCAPTCHAよりも若干マシやったけど、どれも良い開発者体験に近くもなかった。

Vercel Bot IDの優位性

T3 chatはすでにこれでどこに向かうかわかってる。VercelのBot IDはめっちゃめっちゃ良い選択肢や。明らかに、すでにVercelにいる場合にしか役立たんけど、Vercelにいるなら、かなりクレイジーやで。

Cloudflareについて擁護することはたくさんある。Cloudflareについて好きやないこともたくさんある。Turnstileはめっちゃクソショーや。良心的にそれを言わずに言及することはできんで。

Turnstileについて言及するときは、どんなにクソな体験かを確実に認識してもらわなあかん。開発者にとってもユーザーにとっても。大きなCloudflareロゴでページ上にTurnstileウィジェットを表示してないなら、失敗する確率は40%くらいある。見えないモードはクソ動かんし、見えないから見えるへの昇格パスもない。

せやからもうクソや。現在の状態でTurnstileを使うことは誰にも勧められん。作業してることは知ってるけど、クソショーや。これらの選択肢のうち、Turnstileはビジネス投資、たくさんの新ユーザー、その他たくさんを失わせた。Turnstileはわしらにとってクソショーやった。避けることを強く勧める。

開発者体験も台無しにするで。devでオンにしてると、あなたが本当のクライアントにいるかどうかを知るためにデバッグフラグを持ってるかどうかをテストするためにランダムにクソをJSに注入するんや。Turnstileで大変な目に遭った。2時間の動画ができるで。ここで切るわ。ただクソだってことを知っておいてくれ。それ以上は言わん。Turnstileがクソだってことをもっと詳しく学ぶには、わしのキャプチャ動画を見てくれ。

Bot IDのクールなところは、TurnstileとhCaptchaやreCAPTCHAみたいなもんの間のバランスを見つけたところや。Turnstileの利点は完全に無料みたいなところや。企業プランに行かせる前に、異なるサイト用に一定数のウィジェットしか持てんけど、セットアップしたら欲しいだけのユーザーを無料で認証できる。

hCaptchaやreCAPTCHAみたいなものはかなり高い。1000リクエストあたり1ドル請求される。ここで面白いのは、両方の選択肢があることに気づいたかもしれん。無料のbasic analysisがある。これはTurnstileの代替や。

そしてVercel上のBot ID用のdeep analysisがあって、1000チェックあたり1ドルでhCaptchaやreCAPTCHAにめっちゃ匹敵する。せやから両方ある。異なるルートでどちらをプログラム的に変更するのをより簡単にする作業もしてる。明らかに彼らはわしらを移行させたがってるし、正直にわしもめっちゃ移行したいから、彼らとたくさん話してる。

今日構築してたら、これを選んでたと思う。そして統合がたぶん最高の部分や。他のすべてのソリューションと比較して、めっちゃシンプルな統合や。reCAPTCHA v3を動くようにするために、たぶん1000行のJS書いて、動かんかったいろんなパッケージをデバッグして、2日かけて正気をチェックせなあかんかった。それより簡単やって誰かが言うなら、その実装は壊れてるで。約束する。

Bot IDの簡単な統合

Bot IDでは、next configに行く。Bot IDでラップする。そして今instrumentationクライアントで認めるときに、異なるルートと該当ルートの異なるメソッドを保護するように指定できる。そして今終了や。今クライアントはすべて処理される。

ReactコードのどこかにBot IDクライアントを置かなあかんかもしれん。ルート上にあるだけや。そして今、誰かがそれらの保護されたルートの1つに行ったり、それらの1つにリクエストを送ったりするときはいつでも、すべてをあなたのために処理してくれる。パーツ間の変なプラグインはない。コンポーネントを使って、設定を作って、終わりや。

そして確認する準備ができたら、const verification equals await check bot IDや。もしverification is botなら失敗させる。めっちゃ良いで。めっちゃコミカルに良い。

セキュリティに関する補足質問への回答

誰かがJSを切ってもBot IDは動くかって聞いた。いや、JSを切ったら何もクソ動かんやろ。アンチDOS層を置くんかって？まともなソリューションのほとんどは、あなたのためにそれを処理してくれる。DOS保護のためにCloudflareを前に置くか、さらに良い自分たちで作ったものを作るかや。

VercelのファイアウォールはCloudflareよりも今の方が良いで。せやからそこにあるやつにめっちゃ満足してる。そして、明確にするけど、DOS保護とbot保護は違うものや。DOS保護は、明らかに偽のトラフィックの大きな急増があったとき、あなたのコードが叩かれる前にブロックすることを確認することや。

Bot保護は、あなたのコードが叩かれたときに、ユーザーが人間かどうかを検証して、自動化されて何かを送ったりしたりするのを防ぐことや。せやからT3 chatみたいなもんでは、ほとんどのエンドポイントにbot保護を置かん。ユーザーデータを取得しようとしてたり、データベースで何かを更新しようとしてたりするとき、それらのもんでbotかどうかはチェックしない。

でも高いもの、わしらの場合はメッセージ生成をしようとしてるときに、高いものが自動化されてスパムされないことを確認したいから、そのときにキャプチャチェックを実行するんや。そしてこれは苦労して学んだで。

Arcjetという選択肢

これ全部について見てるもう1つの会社がある。最近のスポンサーで、わしの古い投資でもある。すべてのピースをまとめるのに時間がかかったけど、今は絶対にやり遂げた。そして再び、T3 Chatを作ったときに存在してほしかったもののうちの1つや。

Arcjetは異なるクソすべての痛みのないセキュリティや。他のほとんどのソリューションより統合するのがめっちゃ良い。bot検出、レート制限、メール検証、DOS保護、このクソ全部をやりたいなら。めっちゃ良いSDKですべて持ってる。

arcjetヘルパーを定義できる。detect botルールを定義できる。せやからこれはbotかどうかをチェックする。検索エンジンみたいな特定のカテゴリを許可することも選択できる。ユーザーが特定の数のことしかやってないことを確認するトークンバケットも持てるし、ユーザーをどうやって識別するかも選択できる。わかるやろ。

アプリケーションでセキュリティレイヤーを定義するプログラム的な方法として、めっちゃクールや。この連中はめっちゃ気に入ってる。クールなもの作ってる。まだチェックしてないなら、めっちゃチェックすることを勧める。スポンサーにさせて、投資した理由があるんや。めっちゃクールやと思う。

セキュリティソリューションのまとめ

すべてそれを言ったけど、Vercelにいないなら、hCaptchaかArcjet、Vercelにいるなら、Bot IDはめっちゃ有望やで。DOS保護は、VercelかCloudflareにいないなら、あなたの問題や。自分で理解してくれ。レート制限。レート制限のすべてのユースケースはめっちゃ違う。あなたの問題や。

現在のスタック構成のまとめ

それがコアや。データベースにConvexを使って、再びConvexがリアルコードをデプロイするから、アプリレイヤーにConvexを使ってる。ほとんどのものが今そこで行われてる。Next.jsでエンドポイントをそんなに定義しなくなった。でもいろんな理由で必要なときはまだtRPCに手を伸ばす。

認証レイヤーはめっちゃ変わる。近いうちにBetter Authを期待してる。そうでなければ、ClerkかWorkOS。なぜかはもう説明した。クライアントフレームワークはReactプラスViteかNext。静的ページが欲しいならNext、そうでないならVite。Tanstack Startもめっちゃ近いうちに来る。

スタイルシステム。TailwindとShadcn。なぜかは他の動画を見てくれ。パッケージ管理。PNPM。bunでモノレポがもっと良く処理されるようになったら、もっと真剣に考える。それまでは、PNPMに問題ない。めっちゃ満足してる。わしを失望させることがほとんどないソフトウェアの数少ない部分の1つや。

バックエンドホスト、まだVercel、すべてのウェブアセット用でもある。めっちゃ便利やで。データベースホストはConvex。めっちゃ便利。彼らがそれらすべてのレイヤーをわしのためにやってくれる。そして今ConvexはPlanet Scaleの上に構築されてる。Planet Scaleはわしの昔のお気に入りのデータベースホストやった。せやから、自分でやることなく、Planet Scaleから得られるであろうすべてのスピードとスケールの恩恵を得られる。

アナリティクスとアナリティクスホストはPostHog。キャプチャレート制限などはVercel Bot IDかhCaptchaかArcjet。支払いはStripeかもちろんその上に構築された代替品、AutumnかPolar。

ファイルアップロード

最後にもう1つここで。ファイルアップロード。みんなこれに何を使ってるかは知ってるやろうと思う。Upload Thing。Convexのソリューションはかなり良いって言うで。Convexでの問題は、公開ファイル対プライベートファイルを全然処理しないことや。

Upload Thingはもっと包括的なファイル管理とアップロードソリューションや。Better AuthがConvexの認証よりも大幅に良いのと似てる感じやと思う。違いは、どちらのツールを使ってもファイルアップロードを動かすのに設定する必要がないことや。認証を動かすのは何を使っても設定がめっちゃ必要やけどな。

Upload Thingはユーザーのファイルアップロードに最高の体験を提供して、該当ファイルを取得して、プライベートファイルを管理して、たくさんのファイルにスケールして、ファイルアップロードが完了したときのDXを作って、すべてその他、Upload Thingが帯域幅をクソにすることなく断然最高のソリューションになるで。

Convexのファイルアップロードも良いけどな。実際、今作ってるimage studioでは、追加する1つ少ないもので、めっちゃ簡単にやれたから、Convex認証を使ってる。

これがどこで設定されるかも知ってる。よく見ると、Upload Thingを使うべきやったって気づく。画像を取得して、正しいHTTPレスポンスを得たことを確認して、blobを変換して、ファイルサイズが適切に注釈されてることを確認する、このコード全部。わしらはUpload Thingでこれ全部を処理する。URLを渡してくれたら、ファイルを処理するで。

せやから、これにはUpload Thingを使うべきやったと思う。でも少なくともcontext.storage.storeでblobを呼び出して、context.storage.getURLでURLを取得できる。これも前に話したもんやけど、取得するURLは永続的なURLや。一時的な署名付きURLとかそういうものは本当にできん。せやからチェックとバランス。

その他の技術要素

上記すべての目標は、これらすべての部分でどんな答えを出しても使えることや。でもこれらの部分に行くことができる。モノレポは必要悪や。まだめっちゃ良くなってほしいと思ってる。Turbo repoがめっちゃ良くしてくれた。まだわしが欲しいところにはないけど、少なくとも前のような地獄やない。

モバイル。みんな知ってるやろうけど、ExpoとReact Nativeをめっちゃ長い間使うで。そしてReact Native Expoアプリの本当に良いショーケースが欲しいなら、注目しといてくれ。T3 Chatは他のすべてのAIチャットアプリより良くなるし、React Nativeで作られる予定や。

Effect、必要なら。Effectにやられ始めてる。価値はわかるけど、十分な問題も引き起こしてる。率直に言って、Effect系のもんを見るのはコードベースでわしがもう詳細にいないから問題を引き起こしてるときだけや。Juliusがコードベースをeffectifyしてるときまでには、もうマネジメントポジションに移らなあかんようになってるからな。

でもEffectは信じられないソフトウェアや。たくさんのことができる。エラー管理についてめっちゃ良くしてくれた。そしてクソ、トレースを内観できるもの、世代中やユーザーリクエスト中に起こったすべてのことを見るためにアクセスできるUIを、無料でEffectから吐き出してるAxiomのホテルのトレースだけで、信じられんで。

せやから絶対にわしらの価値があった。KVストア、KVの使用はいつも何か特定の統合もんやとわかる。T3 chat用に今使ってるKVはopen auth用のworker KV。せやからあの分離された認証もんがある。理想的には、それが必要ない認証ソリューションを持ってる。Stripe storage用にも1つ使ってる。これはupstashや。Autumn、Clerk、Polarみたいな支払いプロバイダーがそれを処理してくれるから、それも必要ない。

せやから再び、必要ならってことや。そしてIDE、まだCursorや。毎日どんどん関係なくなってるとわかる。他のツールが追いついてきてる。wind codeとかrue codeとかclientとかその他がVS Codeを本当に良くしてる。

C-Pilotが今オープンソースで、エディタでうまく動かすもんのどんどん多くが拡張機能でアクセスできるという事実。IDE空間でたくさんの進歩がなされてるけど、Cursorがまだわしの最高の体験や。最も信頼できて、最もたくさんのことをやってくれるやつや。

CLI全般ではt-maxが大好きやし、CLIでプロジェクトを管理するのも好きやけど、そこでコードを書くのは好きやない。Vimの人やなかった。せやからCloud Code、Open Code、Aider、CodeEx、その他すべてには興味ない。

そして最後の1つやと思う。バックグラウンドエージェント。それについてのわしの答えはTBD。現在のソリューションのどれにも満足してない。ほとんど試したけど、わしには良くなかった。将来的に何か持てるかもしれんけど、今のところ、meh。

チーム効率化ツール

チーム効率をもっと上げるために常に使ってる他のもんがたくさんある。すべてのコミュニケーション用のDiscord、すべてのコードレビュー用のgraphite、該当コードレビューでフィードバックを残すためのcode rabbit、その他めっちゃたくさん。必ずしもわしのスタックやないもんについてすでにめっちゃ深く行った。

価値と焦点をここに留めておきたい。わしが構築することを勧める部分と、今日構築することを個人的に選ぶ部分。そしてもう一度、この要点は、すべてのプロジェクトでコピペして使うべきってことやない。この要点は、わしがスタックに使う部分をどう考えるかを示して、わしが手を伸ばしがちなやつを見て、どの部分があなたに役立ってどの部分がそうでないかを理解することや。

まとめと哲学

このスタック全体を取って、コピペして使って成功を見つけたなら、めっちゃ嬉しい。でも、あんまり必要やない部分を削除したり、あなたのニーズに基づいてものを交換したり、スタックに必要なことは何でもすることについて悪い気持ちになることは絶対にないで。

それの要点はモジュラーであることや。すべての部分が交換して相互変更されることを意図してる。通っていく間に示したように、構築してるもんに応じて異なる部分をどう交換するかも見せた。人にわしのスタックをコピーしてもらうより、この方法でスタックについて考えてもらう方がめっちゃ興味がある。構築しようとしてるものと、それらの部分をどう組み立てるかを中心にしたよりモジュラーなアプローチ。

これが今日わしがそれらを組み立てた方法で、去年やった方法とは全然違うし、3年前にやった方法とも全然違う。そして期待してるのは、このもの構築の方法があなたにも役立つことや。これが役立ったことを期待してる。次にどのデータベースに移るかを理解するのが待ちきれんな。

コメント

タイトルとURLをコピーしました