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 / graphql server technology selection
Search
Masayuki Izumi
April 19, 2024
Programming
4
940
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / graphql server technology selection
tsukiji.graphql x ハッカー鮨
https://tsukiji-graphql.connpass.com/event/314173/
Masayuki Izumi
April 19, 2024
Tweet
Share
More Decks by Masayuki Izumi
See All by Masayuki Izumi
Next.js App Router を例に考える、技術選定・技術との距離感 #技術選定_findy / findy 2024-01-24
izumin5210
13
5.3k
雑なコード生成のすすめ #nihonbashijs 8 / zatsu-code-generation
izumin5210
0
46
React Server Components で複雑さに立ち向かう #コンポーネント_findy / findy 2023-10-04
izumin5210
10
2.8k
みんなで育てる GraphQL スキーマ, それを支える Protobuf / GraphQL and Protobuf #tech_stand
izumin5210
7
3.4k
GraphQL 導入の反省と再挑戦 / jsconf jp 2021
izumin5210
11
8k
HTTP クライアントを作ろうとして学ぶ、使いやすいインタフェース / #GoCon_Sendai 2020
izumin5210
7
5k
個人の・組織の Go 筋を強化する / Gophers Code Reading Party
izumin5210
1
310
今あらためて読み直したい Go 基礎知識 その2 / golang.tokyo #25
izumin5210
10
9k
CLI ツール開発を支える技術 2019春 / Techniques that support building CLI tools, 2019 Spring
izumin5210
8
3.4k
Other Decks in Programming
See All in Programming
Criando a Woovi em uma semana
daniloab
0
120
TSKaigi 2024 - 新サービス Progate Path の演習で TypeScript を採用して見えた教材観点からの利点と課題
makotoshimazu
1
230
Productivity is Messing Around and Having Fun
hollycummins
1
190
RustでAWS Lambda functionをいい感じに書く
taiki45
2
160
TypeScript 関数型スタイルでバックエンド開発のリアル
naoya
49
16k
RaaP
ksss
0
160
TypeScriptの型とパフォーマンス (TSKaigi 2024)
ypresto
14
5.2k
TypeScript Custom GitHub Action Development Tips
peaceiris
5
850
ServerAction で Progressive Enhancement はどこまで頑張れるか? / progressive-enhancement-with-server-action
takefumiyoshii
6
520
slow types ってなんだろう?
karad
0
210
Exploring Type-Informed Lint Rules in Rust based TypeScript Linters
unvalley
3
650
Embedding it into Ruby code
soutaro
2
420
Featured
See All Featured
Designing with Data
zakiwarfel
96
4.8k
Debugging Ruby Performance
tmm1
70
11k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
84
45k
Adopting Sorbet at Scale
ufuk
69
8.6k
Rails Girls Zürich Keynote
gr2m
91
13k
How to train your dragon (web standard)
notwaldorf
75
5.2k
Embracing the Ebb and Flow
colly
80
4.2k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Producing Creativity
orderedlist
PRO
338
39k
Scaling GitHub
holman
457
140k
Designing Experiences People Love
moore
136
23k
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 サーバ技術選定を教えてください