in-process GraphQL のすすめ #ginzajs

Transcript

1. in-process GraphQL のすすめ 2026-08-17 ginza.js #11 @izumin5210
2. whoami @izumin5210 LayerX バクラク事業部 (2022-09 -) Platform Engineering 部 Enabling チーム / Dev Infrastructure チーム Staff Software Engineer バックエンドや Web フロントエンドが専門 ISUCON14 4位 好きなリポジトリは vercel-labs/wterm © LayerX Inc.
3. 単に「GraphQL の API サーバをデプロイしてフロントエンドから叩く」以上の GraphQL の使い方を紹介します © LayerX Inc. 3
4. 前提 | GraphQL サーバの構成要素 © LayerX Inc.
5. 前提 | GraphQL サーバの構成要素 GraphQL サーバの構成要素 NestJS Pothos GraphQL, GraphQL Nexus, TypeGraphQL, graphql-js SDL (*.graphql) Schema Definition @graphql-codegen/ typescript-resolvers Resolver Execution Engine Apollo Server Envelop Execution Middleware graphql-http, GraphQL Yoga Transport Adapter Hono, Express, Fastify, Next.js, … Transport ※ @izumin5210 による独自の分類です © LayerX Inc. https://speakerdeck.com/izumin5210/graphql-server-technology-selection 5
6. GraphQL を Next.js に乗せる © LayerX Inc.
7. GraphQL を Next.js に乗せる API が引くのは サーバ・クライアントの論理的な境界線 GraphQL がもたらすのは、view と presentation logic の間の契約 それは物理的に異なるサーバである必要はない 同一プロセスに置いても、境界線はそのまま引ける 開発チームが小さい場合など、 初期はデプロイメントを1つにまとめると運用負荷が抑えられる © LayerX Inc. 7
8. GraphQL を Next.js に乗せる GraphQL Yoga を Next.js に乗せる GraphQL Yoga: The Guild 製の GraphQL サーバライブラリ 層でいうと Transport Adapter Envelop（Execution Middleware）も同梱 スキーマの作り方にも、下の HTTP サーバにも依存しない 実体は Request を受けて Response を返す関数 ひとつ yoga.fetch(request) © LayerX Inc. で実行できる スキーマ + resolver graphql-js GraphQL Yoga HTTP サーバ Schema Definition Resolver Execution Engine Execution Middleware Transport Adapter Transport 8
9. GraphQL を Next.js に乗せる Route Handler にそのまま乗る Yoga の interface は Fetch API の / Next.js の Route Handler もまったく同じ interface Request © LayerX Inc. Response 9
10. GraphQL を Next.js に乗せる Transport が Next.js になっただけ スキーマ + resolver graphql-js GraphQL Yoga Next.js Route Handler Schema Definition Resolver Execution Engine Execution Middleware Transport Adapter Transport 差し替わったのは一番外側の層だけ。中身はどのデプロイ形態でも同じ © LayerX Inc. 10
11. GraphQL を Next.js に乗せる 運用が増えてから切り出せばいい 初期はデプロイするのが Next.js だけで済む 監視・デプロイ・権限まわりの 面倒が増えない 切り出すときも、 差し替わるのは Transport だけ スキーマと resolver はそのまま © LayerX Inc. 11
12. RSC / SSR から GraphQL を直接呼ぶ © LayerX Inc.
13. RSC / SSR から GraphQL を直接呼ぶ Transport を飛ばして直接実行する スキーマ + resolver execute({ schema, document, … }) yoga.fetch(request) → → graphql-js GraphQL Yoga Next.js Route Handler 必要な層だけ着けて、その層を直接呼べばよい © LayerX Inc. Schema Definition Resolver Execution Engine Execution Middleware Transport Adapter Transport 13
14. RSC / SSR から GraphQL を直接呼ぶ RSC — yoga.fetch yoga.fetch Request を直接呼ぶ はグローバルの fetch ではなく、Yoga インスタンスのメソッド を渡すとその場で GraphQL が走り、 Response が返る Server Component は async 関数なので、これを await するだけ © LayerX Inc. 14
15. RSC / SSR から GraphQL を直接呼ぶ SSR — Apollo Client の YogaLink Apollo Client の API はそのまま。差し替わるのは link だけ Client Component と同じ書き味のまま、サーバ側でも実行できる © LayerX Inc. 15
16. メール・Slack から呼ぶ © LayerX Inc.
17. メール・Slack から呼ぶ メールも Slack も、Web ページと同じ view 出てくるものは同じ 「表示用の氏名」「ステータスの表示名」「金額の書式」… 本質的に同じ presentation logic が使われるはず ならば Web frontend と同じ方法論が使えるはず © LayerX Inc. 17
18. メール・Slack から呼ぶ Web frontend の方法論をそのまま持ち込む ① component 指向で view を組む jsx-slack — Slack Block Kit react-email — メール HTML vercel/chat — チャット UI fragment colocation もそのまま ② presentation logic は API の裏に隠蔽されている 表示のためのロジックは、Web frontend 向けの resolver にすでにある 「この view に何が必要か」の宣言 （query + DataLoader）ごと再利用できる GraphQL が in-process で呼べればオーバーヘッドを最小にしつつ再利用できる © LayerX Inc. 18
19. メール・Slack から呼ぶ component が自分の依存データを宣言する © LayerX Inc. https://speakerdeck.com/izumin5210/using-typescript-plus-jsx-outside-of-web-frontend-number-tskaigikansai 19
20. メール・Slack から呼ぶ 呼び出し側 メールなら render(<ReportEmail data={data.contentReport} />) に変わるだけ © LayerX Inc. 20
21. まとめ © LayerX Inc.
22. まとめ in-process GraphQL のすすめ GraphQL サーバは層に分解できて、Transport は一番外側の層でしかない API が引くのは論理的な境界線。物理的に分けなくても成立する Next.js に相乗りさせれば、デプロイメントを増やさずに始められる 必要な層だけ着けて、その層を直接呼べる RSC / SSR、そしてメール・Slack のような push 型 view からも 結果として「view のためのデータ取得と presentation logic」を、 Web frontend の外へほぼコストゼロで持ち出せる © LayerX Inc. 22