tRPCとgRPCの違いは?
tRPC と gRPC はどちらも RPC(Remote Procedure Call) のフレームワークですが、目的や実装方式が大きく異なります。
比較項目 | tRPC | gRPC |
---|---|---|
主な用途 | TypeScript / JavaScript 向けの RPC フレームワーク(Node.js のフルスタック開発向け) | マイクロサービス、言語間通信、分散システム向け |
通信プロトコル | HTTP + JSON | HTTP/2 + Protocol Buffers(バイナリ通信) |
データフォーマット | JSON(デフォルト) | Protocol Buffers(protobuf) |
型の自動補完 | TypeScript による型安全が強み(Zodを活用) | protobuf スキーマによる型定義 |
リアルタイム通信 | WebSocket や SSE を併用可能(直接は非対応) | ストリーミング対応(双方向通信が可能) |
言語サポート | TypeScript に特化(フロントエンド&バックエンドで統一) | C++, Java, Go, Python, Rust など多言語対応 |
導入の容易さ | 超簡単(TypeScript 環境ならすぐ使える) | やや複雑(protobuf の定義やコード生成が必要) |
パフォーマンス | JSON なので 比較的遅い | バイナリ通信なので高速(軽量で低レイテンシ) |
1: tRPCとは?
✅ 概要
• TypeScript に特化した 超シンプルな RPC フレームワーク。
• フロントエンド(React, Next.js)とバックエンド(Node.js, Express, Next.js API)で統一した型管理が可能。
• REST API の代替として、API をより簡潔に定義できる。
✅ 特徴
• TypeScript の型がサーバーとクライアントで自動で同期
• スキーマ定義不要(gRPC のように protobuf を定義する必要なし)
• JSON 形式のデータを HTTP 経由でやり取り
• フルスタック開発向け(Next.js, React, Node.js)
• GraphQL のように柔軟な API を定義できるが、GraphQL よりも軽量
- コード生成やランタイムの肥大化なしで、エンドツーエンドの方安全なAPIを書くことができる。(これで、package.jsonでgRPCの最新バージョンを更新し忘れて、自動生成されたコード内でlint時に大量の方エラーが発生するのを防げるよ)
📌 tRPC サーバー(Node.js / Express)
import { initTRPC } from "@trpc/server";
import { createHTTPServer } from "@trpc/server/adapters/standalone";
const t = initTRPC.create();
const appRouter = t.router({
greet: t.procedure.input((val: string) => val).query(({ input }) => {
return `Hello, ${input}!`;
}),
});
const server = createHTTPServer({ router: appRouter });
server.listen(3000);
📌 tRPC クライアント(React / Next.js)
import { createTRPCProxyClient, httpBatchLink } from "@trpc/client";
const client = createTRPCProxyClient({
links: [httpBatchLink({ url: "http://localhost:3000" })],
});
async function fetchGreeting() {
const response = await client.greet.query("Alice");
console.log(response); // "Hello, Alice!"
}
✅ tRPC のメリット
• TypeScript の型を統一できる(型の自動補完)
• スキーマ(protobuf, GraphQL スキーマ)が不要
• フルスタック開発(Next.js, React, Express)に最適
• GraphQL よりも軽量 & シンプル
- gRPCとは?
✅ 概要
• Google が開発した RPC フレームワーク
• HTTP/2 + Protocol Buffers(protobuf) を使用した 超高速・軽量なバイナリ通信
• 異なる言語間での通信を最適化(C++, Go, Python, Rust, etc.)
• ストリーミング通信に対応
✅ 特徴
• HTTP/2 を利用して通信を最適化
• Protocol Buffers(protobuf)を使ったバイナリ通信(JSON よりも圧縮率が高く、高速)
• リアルタイムストリーミング(双方向通信)が可能
• マイクロサービス間の通信に最適
• 多言語対応(C++, Java, Python, Go, Rust など)
✅ gRPC の基本的な実装
📌 gRPC サーバー(Python)
import grpc
from concurrent import futures
import example_pb2
import example_pb2_grpc
class MyService(example_pb2_grpc.MyServiceServicer):
def GetGreeting(self, request, context):
return example_pb2.GreetResponse(message=f"Hello, {request.name}!")
server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
example_pb2_grpc.add_MyServiceServicer_to_server(MyService(), server)
server.add_insecure_port("[::]:50051")
server.start()
server.wait_for_termination()
📌 gRPC クライアント(Python)
import grpc
import example_pb2
import example_pb2_grpc
channel = grpc.insecure_channel('localhost:50051')
stub = example_pb2_grpc.MyServiceStub(channel)
response = stub.GetGreeting(example_pb2.GreetRequest(name="Alice"))
print(response.message) # "Hello, Alice!"
✅ gRPC のメリット
• JSON よりも軽量で高速なバイナリ通信
• 異なるプログラミング言語間で通信できる
• ストリーミング(双方向通信)に対応
• マイクロサービス間の通信に最適
- tRPC と gRPC の使い分け
項目 | tRPC | gRPC |
---|---|---|
主な用途 | TypeScript フルスタック開発(Next.js, Express) | マイクロサービス、異言語通信 |
データ形式 | JSON(デフォルト) | Protocol Buffers(バイナリ通信) |
通信プロトコル | HTTP + JSON | HTTP/2 + バイナリ |
型の管理 | TypeScript の型が自動で同期 | protobuf で定義 |
パフォーマンス | JSON を使うため比較的遅い | バイナリ通信で高速 |
リアルタイム通信 | WebSocket / SSE を併用可能(直接は非対応) | 双方向ストリーミングが可能 |
多言語対応 | TypeScript のみ | C++, Python, Go, Rust など多言語対応 |
導入のしやすさ | 超簡単(スキーマ不要) | やや複雑(protobuf 必要) |
✅ どちらを使うべきか?
1. tRPC を使うべき場合
• TypeScript / JavaScript のプロジェクト(Next.js, React, Express)
• フロントエンドとバックエンドの型を統一したい
• 設定を簡単に済ませたい
2. gRPC を使うべき場合
• マイクロサービス間通信(異なる言語間で通信する)
• リアルタイムストリーミングが必要
• 大規模な分散システム
✅ 結論
• tRPC は「TypeScript 界の gRPC」みたいなものだが、gRPC ほどのパフォーマンスはない。
• gRPC は「超高速・低レイテンシ」な通信が可能で、異言語間の通信に強い。
• tRPC は「簡単な TypeScript のフルスタック開発」に最適。
Discussion