構築のための基盤。

すべての製品が繰り返す作業

新しい製品は特定の問題から始まります。最初の数週間は多くの場合ずっと特定らしくありません：セッション、ワークスペースレコード、サブスクリプション状態、バックグラウンド処理、メール配信。これらの部品が協調するまで、製品は有用なことができません — どれも抽象的には解決済みの問題であり、具体的には統合リスクです。

supastack はその繰り返される作業に居場所を与えます。Next.js Web アプリと Expo モバイルアプリが、基盤インフラのために TypeScript パッケージを共有します。目標は、製品が他人のドメインモデルを継承せずにそれらの境界を設定できるほど十分に理解可能にすることです。

どの部品も単独では難しくありません。コストはそれらの連携にあります — 権限にならなければならない支払い、ワークスペーススコープにならなければならないセッション、閉じたノート PC を生き延びなければならないタスク。製品が失敗するのは足りない機能ではなく、継ぎ目です。

なぜ一度、正しく作るのか

共有インフラの論拠は、その作業があなたのレベルに足りないからではありません — 繰り返される作業は一度、丁寧にやる価値があるということです。共有モジュールでうまく実装されたワークスペース境界は、その上に作られるすべての製品を守ります。製品ごとに即興された同じ境界は、興味深く危険な形でずれた、ニアミスの集合になります。

保守も集中します。プロバイダー API は変わり、認証ライブラリは進化し、課金の意味論はずれます。それらの変更が一か所に届くとき — キットのモジュールドキュメントが追跡しています — 修正はプロジェクトごとに学び直されるのではなく伝播します。単一の製品についてトレードを量っているときは、スターターキットかゼロからかが同じ理屈を買うか作るかの決定に適用しています。

共有インフラはレビューも集中させます。一か所にある境界は、ネガティブケース・リプレイイベント・テナント間の試行を一度厳密にテストできます — 5 つの再実装がそれぞれ正しかったことを祈る必要はありません。キットがテストスイートに投資する理由の一部です：共有コードへの信頼を維持する方が、プロジェクトごとに稼ぎ直すより安いからです。

各モジュールに一つの責任を

認証は誰がリクエストをしたかを確立します。ワークスペースはその人がどのレコードに届くかを決めます。課金は支払い状態を記録し、権限は能力が利用可能かに答えます。これらの関心事を分離しておくことで、成功した支払いリダイレクトが認可の決定になるのを防ぎます。

同じ規律がバックグラウンド処理に適用されます。共有 JobRunner コントラクトは enqueue・status・cancel を約束します。Trigger.dev がワークフロー動作を所有します。小さなインターフェースは境界が見えるときに価値を持ちます。リトライやスケジューリングを汎用メソッドの背後に隠すと、システムの推論が難しくなります。

Better Auth が認証に答えます。Postgres と Drizzle がレコードを保持します。Stripe または Lemon Squeezy が支払い状態を報告します。どれも他のモジュールの仕事に器用さを求められていません — 継ぎ目は推論できるほど狭いままです — そして基盤はその継ぎ目と同じだけしか信頼できません。

製品のための余地を残す

リードフロー、ドキュメントエディター、リサーチアシスタントは同じ認証・課金モジュールを使えます。それらのレコード、言語、フローは異なったままです。製品固有のロジックは消費側コードベースに属し、基盤へ結びつける設定とともにあります。

その分離は実際的な保守の決定でもあります。ワークスペース分離への修正は再利用可能であるべきです。ある製品がリードを評価する方法の変更は、他のすべての製品への新しい要件になるべきではありません。

それが基盤とテーマの違いです。テーマは維持するか取り替えるかできる見た目を与えます。基盤は荷重を担う決定 — 誰が認証を所有するか、レコードがどうスコープされるか、支払いがどこでアクセスになるか — を与え、製品はそれを回避するのではなく上に構築します。プロジェクト構成ガイドが一方の終わりともう一方の始まりを示しています。

一つの完全なフローから始める

ローカル参照フローから始めます：ログインし、アクセスを検査し、タスクを送信し、その結果を読みます。fake とローカルアダプターにより、決定的なテストがプロバイダーへの有料リクエストなしで経路を実行できます — 5 分クイックスタートが端から端まで実行します。次に製品が実際に必要とする本番統合を設定します。

ローカル受け入れと本番受け入れは異なる質問に答えます。合格したローカルテストは制御された条件下でのアプリケーションの振る舞いを確立します。実際の認証永続化、プロバイダー配信、デプロイ、デバイス動作は依然として独自の検証が必要です。製品が成長するにつれてその区別を見えるままに保ちます。

基盤はゆっくりとその名を稼ぎます：1 つ目より速く出荷される 2 つ目の製品の中で、そして 5 つのコードベースではなく 1 つのモジュールを直す保守日の中で。それが supastack の背後にある賭けであり — 各モジュールが課せられる基準でもあります。

このアプローチの背後にある質問

このアプローチの下にはいくつかの質問があり、率直に答える価値があります。

supastack はテンプレートですか、フレームワークですか？ — コントラクトで結ばれたモジュールの基盤です。製品コードは Starter Core の外に置かれ設定で接続するので、機能をフォークせずにプラットフォームを更新できます。
共有インフラは製品を画一的にしませんか？ — 共有されるのは配管だけです。レコード・ワークフロー・言語は製品コードベースに残ります — 顧客が実際に見える部分はあなたのもののままです。
製品自身のコードはどこから始まりますか？ — その製品だけが持つレコードとワークフローからです。基盤はユーザーを認証しデータをスコープしますが、見込み客が何かは知りません。
なぜモノレポですか？ — Web・モバイル・デスクトップアプリがその下のパッケージと一緒に変われるように：1 つの型システム、1 つのテストゲート、リポジトリ間のずれなし。
Web アプリだけ必要な場合は？ — 購入するのは基盤です。モバイルとデスクトップは採用しても無視してもよい面です。不要なアプリを出荷させられることはありません。