Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / g...
Search
izumin5210
April 19, 2024
Programming
1.6k
5
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / graphql server technology selection
tsukiji.graphql x ハッカー鮨
https://tsukiji-graphql.connpass.com/event/314173/
izumin5210
April 19, 2024
More Decks by izumin5210
See All by izumin5210
開発体験を左右するライブラリの API 設計 - GraphQL スキーマ構築ライブラリから考える #tskaigi
izumin5210
2
1.7k
izumin5210のプロポーザルのネタ探し #tskaigi_msup
izumin5210
2
870
AI Agent の開発と運用を支える Durable Execution #AgentsInProd
izumin5210
8
2.8k
AI Agent Tool のためのバックエンドアーキテクチャを考える #encraft
izumin5210
6
2.2k
Building AI Agents with TypeScript #TSKaigiHokuriku
izumin5210
6
1.8k
Web エンジニアが JavaScript で AI Agent を作る / JSConf JP 2025 sponsor session
izumin5210
4
3.4k
AI Coding Meetup #3 - 導入セッション / ai-coding-meetup-3
izumin5210
0
3.7k
Web フロントエンドエンジニアに開かれる AI Agent プロダクト開発 - Vercel AI SDK を観察して AI Agent と仲良くなろう! #FEC余熱NIGHT
izumin5210
3
1.2k
TypeScript を活かしてデザインシステム MCP を作る / #tskaigi_after_night
izumin5210
5
930
Other Decks in Programming
See All in Programming
Observability in Practice:Grafana 與 Edge Device SRE 的那些事
blueswen
0
160
気圧・高度・GPSを記録&可視化するアプリ「Koudo」を作った話
hjmkth
1
260
Skillsは効率化、Agentsは"自分の拡張"——Builder時代のエージェント編成(CC Night 2026)
wemra
1
130
ユニットテストの先へ:テスト技法で要求・仕様を整理するJava開発実践 / Beyond_Unit_Testing_Practical_Java_Development_Techniques_for_Organizing_Requirements_and_Specifications
shimashima35
0
400
TSKaigi Night Talks 2026_TypeScriptでサプライチェーンの整合性を型に閉じ込める
geekplus_tech
0
350
Javaの型とAI時代に型が大事な理由 / java types and type in AI era
kishida
2
140
ふつうのFeature Flag実践入門
irof
7
3.9k
「なぜそう決めたのか」を残し続ける仕組み ― Notion AI カスタムエージェント × Slack連携による設計判断の自動記録 - NIKKEI Tech Talk #47
niftycorp
PRO
0
170
AIとASP.NET Coreで雑Webアプリを作った話
mayuki
0
630
セキュリティの専門家じゃなくてもできる。「セキュリティ意識」をアップデートして サプライチェーン攻撃への耐性を高めよう。
tk3fftk
5
760
Webフレームワークの ベンチマークについて
yusukebe
0
170
Claspは野良GASの夢をみるか
takter00
0
190
Featured
See All Featured
Crafting Experiences
bethany
1
180
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Limits of Empathy - UXLibs8
cassininazir
1
360
Accessibility Awareness
sabderemane
1
140
Being A Developer After 40
akosma
91
590k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
30k
First, design no harm
axbom
PRO
2
1.2k
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
160
The Pragmatic Product Professional
lauravandoore
37
7.3k
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.3k
Become a Pro
speakerdeck
PRO
31
6k
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 サーバ技術選定を教えてください