結局のところ、T3 Stackを採用するメリットとは何なのか？：フルスタックフレームワーク、T3 Stack入門（終）（1/3 ページ）

バックエンドも合わせて開発しようとするフロントエンドエンジニアに向けて、フルスタックフレームワークT3 Stackを解説する本連載。最終回はユーティリティーファーストのCSSフレームワーク「Tallwind CSS」のチュートリアルを紹介、さらにApp RouterでtRPCを活用する手法についても解説し、Server Actionsの利用、tRPCの比較などを行う。

[上原潤二，NTTテクノクロス]

　NTTテクノクロス上原です。第4回では、ユーティリティーファーストのCSSフレームワーク「Tailwind CSS」について解説しました。今回は、チュートリアルの中で、App RouterでtRPCを活用するコード例を解説し、「Server Actions」と比較します。

T3 StackとTailwind CSS

　Tailwind CSSには、初見ではデメリットに見える点があり、正直なところとっつきにくいのですが、そのような課題を軽減したり解決したりするためのツールや技法も用意されています。そして、習熟すると、スタイルシートを別ファイルに分けないことのメリットが非常に大きく感じられてきます。特に試行錯誤や微調整を繰り返す開発の場合は効果が絶大です。

　もちろん、Tailwind CSSはどんなプロジェクトにも、誰にでも向いているソリューションではありませんし、既存の方法とのギャップも大きく初期の学習コストも高めです。

　問題はそれがどんなプロジェクトに向くか、自分が参加するプロジェクトに向くかどうかです。今回は、T3 Stackがターゲットとしているプロジェクトにおいて、Tailwind CSSの特徴がどのように適合するのかを見ていきたいと思います。

［コラム］祝！　tRPC-OpenAPI連携の復活

　本連載の第2回ではtRPCで定義されたリモートプロシジャをOpenAPI（Swagger）準拠のREST APIで呼び出せるようにするtrpc-openapiを紹介しました。しかし残念なことに、その後trpc-openapiは開発が止まり、Create T3 Appに含まれるtRPC 11はREST APIとして呼び出す標準的な手段がなくなっていました。しかし最近になって、幸いなことにtrpc-openapiをフォークする新プロジェクトtrpc-to-openapiが開始され、こちらを使用することでtRPC 11および最新のCreate T3 Appで生成されるプロジェクト構成においてREST API呼び出しができるようになりました（2024年12月現在）。

　プロジェクトにもよりますが、開発の当初はクライアント側はTypeScriptだけでよいと考えていても、状況変化により後からREST APIでのサーバ機能呼び出しが必要になることは可能性としてはあり得る話です。サードパーティーからの呼び出しにおいてはできるだけ他言語からの呼び出しも許容したいところです。ですので、REST APIで呼び出せることはtRPCひいてはT3 Stackの可用性と運用性にとって大きな利点と言えます。

　なお、今回の連載のサンプルコードを含めて、trpc-to-openapiのCreate T3 App（7.38.1）での追加設定およびサンプルコードを筆者のGitHubリポジトリで公開していますので、参考にしてください。

なぜT3 StackでTailwind CSSが採用されているのか

　T3 StackにおいてTailwind CSSが選定されていることの意味を考えてみます。前提として、本連載の第1回で示したように、T3 Stackは以下のような条件で有効性を特に発揮できるフレームワークです。

• TypeScriptやNode.jsなどフロントエンド開発の技術で構成されているために、クライアントサイドとデータベース（DB）アクセスを含むサーバサイドの両方を同じ技術、言語で型安全に開発できる
• UI（ユーザーインタフェース）中心で機能を検討でき、実際に操作するユーザーからのフィードバックを受けて、サーバとクライアントの両方にまたがる機能も型安全に迅速に開発できる

　このことをチーム構成の面から見ると、専門のサーバサイドエンジニア、専門のDBエンジニアといった役割分担を作らずに、コミュニケーションコストが低めな小人数のチームで開発を回す、というイメージが湧きます。

　だとすると、デザインの専門家であるデザイナーがいて、デザインに関わる修正や追加のたびにデザイナーにCSS修正を依頼するという分担方法はT3 Stackを最適に使いこなせるチーム構成ではないのかもしれません。いずれにせよ、エンジニアがデザインを即座に修正できる方法がT3 Stackでは必要なのです。さらに、デザイナーに頼らずにデザインシステムを実装したり、改善を続けたりしやすいことが、T3 Stackの想定には合っているように思えます（デザインシステムの開発が全てのプロジェクトで必要になるわけではないでしょうけれども）。

　このことを踏まえて、Tailwind CSSには他のスタイル設定の技術と比べると以下のような特徴があります。

比較対象	例	Tailwind CSSと比べて
CSS Modules	CSS Modules	・デザイナーはCSSを書いて、プログラマーはそれを呼び出して使用するという役割分担に向いている ・Tailwind CSSはCSSとコード間を移動することなく1カ所で即座に修正できるコロケーションが優れている
CSS-in-JS	Emotion、styled-components	・自前のデザインシステムを提供するために有用なCSSへの制約機能がない
UIコンポーネントライブラリ	Chakra UI、MUI	・UIコンポーネントライブラリが提供する、既定義のデザインシステムを採用することになる。自前のデザインシステムを提供するために有用なCSSへの制約機能がない ・Tailwind CSSはReact Server Component（RSC）のサーバコンポーネントで問題なく動作するが、Chakra UIの現バージョンv2やMUIなどはサーバコンポーネントでは現時点では動作しない（サーバコンポーネントに対応するPanda CSS、Kuma UIなど代替的なものはある）

　T3 StackのWebサイトの「その他のオススメ」のページには、例えばChakra UIも推奨の一つとして列挙されており、T3 Stackで構築するアプリケーションでそれらを使えないわけではありません。その上で、Tailwind CSSはCreate T3 Appで選択するだけで使える今のところ唯一の選択肢です。

　なお、余談ですが、Tailwind CSSのパレットやサイズ指定の意味などについては、Tailwind CSSの共同開発者でもあるAdam Wathan氏による書籍「Reactoring UI」を読むと分かる部分があります。Refactoring UIは、エンジニアがデザイナーに頼らず、開発者から見た視点で優れたUIデザインを実現する方法を紹介していて、T3 StackでTailwind CSSが採用されている理由につながるものがあると感じます。併せて参考にされることをお勧めします。