Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / g...
Search
izumin5210
April 19, 2024
Programming
5
1.5k
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / graphql server technology selection
tsukiji.graphql x ハッカー鮨
https://tsukiji-graphql.connpass.com/event/314173/
izumin5210
April 19, 2024
Tweet
Share
More Decks by izumin5210
See All by izumin5210
Building AI Agents with TypeScript #TSKaigiHokuriku
izumin5210
6
1.3k
Web エンジニアが JavaScript で AI Agent を作る / JSConf JP 2025 sponsor session
izumin5210
4
2.4k
AI Coding Meetup #3 - 導入セッション / ai-coding-meetup-3
izumin5210
0
3.6k
Web フロントエンドエンジニアに開かれる AI Agent プロダクト開発 - Vercel AI SDK を観察して AI Agent と仲良くなろう! #FEC余熱NIGHT
izumin5210
3
970
TypeScript を活かしてデザインシステム MCP を作る / #tskaigi_after_night
izumin5210
5
830
複雑なフォームを継続的に開発していくための技術選定・設計・実装 #tskaigi / #tskaigi2025
izumin5210
14
9.4k
複雑なフォームの jotai 設計 / Designing jotai(state) for Complex Forms #layerx_frontend
izumin5210
10
3.8k
複雑なフォームと複雑な状態管理にどう向き合うか / #newt_techtalk vol. 15
izumin5210
4
4.8k
よくできたテンプレート言語として TypeScript + JSX を利用する試み / Using TypeScript + JSX outside of Web Frontend #TSKaigiKansai
izumin5210
9
6.2k
Other Decks in Programming
See All in Programming
re:Invent 2025 のイケてるサービスを紹介する
maroon1st
0
130
Go コードベースの構成と AI コンテキスト定義
andpad
0
130
AIエージェントを活かすPM術 AI駆動開発の現場から
gyuta
0
430
ローターアクトEクラブ アメリカンナイト:川端 柚菜 氏(Japan O.K. ローターアクトEクラブ 会長):2720 Japan O.K. ロータリーEクラブ2025年12月1日卓話
2720japanoke
0
730
脳の「省エネモード」をデバッグする ~System 1(直感)と System 2(論理)の切り替え~
panda728
PRO
0
100
Cap'n Webについて
yusukebe
0
140
ZOZOにおけるAI活用の現在 ~モバイルアプリ開発でのAI活用状況と事例~
zozotech
PRO
9
5.7k
Context is King? 〜Verifiability時代とコンテキスト設計 / Beyond "Context is King"
rkaga
10
1.3k
これだけで丸わかり!LangChain v1.0 アップデートまとめ
os1ma
6
1.9k
生成AIを利用するだけでなく、投資できる組織へ
pospome
2
350
実は歴史的なアップデートだと思う AWS Interconnect - multicloud
maroon1st
0
210
ELYZA_Findy AI Engineering Summit登壇資料_AIコーディング時代に「ちゃんと」やること_toB LLMプロダクト開発舞台裏_20251216
elyza
1
240
Featured
See All Featured
Visualization
eitanlees
150
16k
Context Engineering - Making Every Token Count
addyosmani
9
530
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.6k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.8k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Done Done
chrislema
186
16k
The Cost Of JavaScript in 2023
addyosmani
55
9.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
38
3k
Six Lessons from altMBA
skipperchong
29
4.1k
For a Future-Friendly Web
brad_frost
180
10k
Transcript
tsukiji.graphql GraphQLサーバの構成要素を整理する 2024-04-18 @izumin5210 Photo by Zaini Izzuddin on Unsplash
@izumin5210 ▶ バックエンドや Web フロントエンドを書きます - Go, TypeScript, React, GraphQL,
Protobuf, Connect, … ▶ API スキーマが好き ▶ ISUCON に出るのが得意 ▶ eddeee888/gcg-typescript-resolver-files と github.com/99designs/gqlgen が好き LayerX, ex-Wantedly
GraphQL Server、 何で作ってますか? …って聞かれたら、なにを答えますか? ※ Node.js での例が中心となりますが、他の言語でも通じる話をします。多分。
GraphQL サーバ、何で作ってますか? ▶ TypeScript, Go, Ruby, … ▶ NestJS, Apollo
Server, gqlgen, … ▶ graphql-yoga, graphql-ruby, … ▶ スキーマファースト, コードファースト ▶ … GraphQL Server を構成する技術にもいろいろある
そもそも「GraphQL サーバを実装する」とは ▶ GraphQL の仕様はトランスポート層に依存しない - HTTP の上で GraphQL を扱う仕様は
GraphQL over HTTP - 仕様としてはまだ Draft だが、大体の実装がこれに従っているはず ▶ なので、技術選定としてもいくつかのレイヤに分けて考えることができる - 「HTTP リクエストを受けていい感じの処理を挟みつつ GraphQL に橋渡 しをする実装」 - 「GraphQL クエリ(Operation)を受けて結果を吐き出す実装」 - …
GraphQL サーバの構成要素をレイヤに分けてみた ※ @izumin5210 が独自に分類・命名したものです。 一般的な定義が存在していたら教えてください。
▶ Schema Definition - Code-First か Schema-First か - GraphQL
スキーマを定義するのがどういう開発者かな どで、相性がいい方法が変わる ▶ Resolver - スキーマ定義手法によって Resolver 実装手法は概ね定 まる - スキーマ上の型と TypeScript 上の型がちゃんと整合す るかも重要ポイント
▶ Dependency Container - graphql-js の contextValue が実質 Dependency container
として機能する - 独自の DI 機構を持つ場合もある ▶ Execution Engine - JavaScript では基本的に graphql-js が利用される - スキーマ定義・resolver 実装・Context から GraphQLSchema インスタンスを作り、それもとにクエリ を実行する というのがどのライブラリでも共通
▶ Execution Middlwware - Persisted Query など、GraphQL の仕様の外側での 追加処理 -
Envelop は Babel 的にパーサ等の挙動を上書きする ことも可能 ▶ Transport Adapter - Transport (HTTP Server) と GraphQLSchema の 橋渡し ▶ Transport - HTTP server
この構造を理解しておくことで… ▶ 適切な技術選定の助けになるかも - e.g. いま Apollo Server は必要なのか -
e.g. 僕らのアーキテクチャに NestJS は適してるのか ▶ より良いアーキテクチャを見つける助けになるかも - e.g. GraphQLSchema が処理の本体ってことは、 これを React Server Component から呼べる…? ここでは Node.js について取り上げたが、 他の言語でも似たような分類はできるはず。たぶん。
他にも GraphQL サーバ技術選定時に考えること ▶ BFF ▶ Gateway ▶ 普通にドメインロジックめっちゃ持ってるサーバ アーキテクチャ上の立ち位置は?
他にも GraphQL サーバ技術選定時に考えること ▶ 誰が・どうやってスキーマを定義する? - 特定の言語に縛られないほうが、みんなに開かれたスキーマになる(かも) - プログラムでスキーマにメタ情報を仕込めると便利(かも) -
どういうグラフを目指すのか ▶ 安全に resolver を実装できる? - スキーマと実装の型がズレないか 開発フローは?
他にも GraphQL サーバ技術選定時に考えること ▶ (そもそも GraphQL が適するか?) ▶ … 技術選定に影響を与える要素はたくさんある。
「なぜそれなのか」に答えられるようにしておく。
おまけ: @izumin5210 は何を選ぶ? ▶ Go なら gqlgen - Schema-First +
超優秀な scaffolding ▶ Node.js なら - The Guid スタックに乗りたいので、graphql-yoga - 最近は graphql-codegen の Server Preset がいい感じ - JS にも gqlgen に負けない scaffolding が来た!? - Transport はよしなに - プロダクト立ち上げタイミングなら Next.js から配信もアリ (アーキテクチャ・言語は適切に検討したうえで…)
みなさんの最強の GraphQL サーバ技術選定を教えてください