動機

T3 Stackについて勉強中です。まだフワフワ。

バックエンド - フロントエンドで型定義を共有し、APIの静的型付けを実現する。
いまのところ T3 Stack最強だと思っているんですが、一つ疑問が。
「APIの汎用性はどこまで担保できる？」

大きな B to C 向け Webシステムは、SDKやらCLIの提供が一般的です。
IaaS、PaaS、SaaSと幅広く。
それによる利用促進の効果も期待できます。
これは REST APIによる恩恵の一つだと思います。

果たして T3 Stackを使ったWebシステムでも、それらの提供が可能なのか？
とそれらしいことを書きましたが、つまり「バック・フロント密結合すぎない？」って感覚を打破したいのです。*1

その他の動機「ブックマークマネージャ自炊したい欲」

ブックマークマネージャーとして buku を使っています。
CLIベースでブックマークを管理するプロダクト。
これ、シンプルかつ便利でコンセプトも良い。
ただ自分の積ん読グセがひどすぎるので、もっと自分を戒める機能が欲しいなぁと。

CLIで利用可なブックマークマネージャとしつつ、

複数デバイス (Windows / Mac / Android / iPhone etc)
複数ブラウザ (Chrome / Firefox / Edge etc)

これらからアクセスできる環境を作り、一元管理してしまいたい。*2

元はといえば、数万の単位でブックマークをしてしまう自分が全て悪いんですが、この積ん読グセは治ることはない。

注釈

*1 tRPCを利用するCLIが作れるか？のほうが正しいかもしれない。あと、gRPCを間にかませれば割と簡単に出来そうですね。
*2 buku自体は bukuserver というもので Web UI があるようです。少し前の記憶ですが Basic 認証しか使えなかったはず。。。

TakashiAihara

tRPCのドキュメントからすると、 Client側の Type AppRouter が切り分けられれば出来そう。

import { createTRPCProxyClient, httpBatchLink } from '@trpc/client';
import type { AppRouter } from '../path/to/server/trpc'; // <- ここの切り分け
const client = createTRPCProxyClient<AppRouter>({
  links: [
    httpBatchLink({
      url: 'http://localhost:3000/trpc',
      // You can pass any HTTP headers you wish here
      async headers() {
        return {
          authorization: getAuthCookie(),
        };
      },
    }),
  ],
});