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
Search
kyo
October 15, 2022
Programming
1.5k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
作って学ぶ GraphQL
Go Conference mini 2022 Autumn IN Sendai の発表スライドです。
GraphQL についてまとめてみました。
kyo
October 15, 2022
More Decks by kyo
See All by kyo
GoとWasmでつくる軽量ブラウザUI
keyl0ve
0
870
Go言語で行うメール解析
keyl0ve
0
2k
Gopher Enablement Internship
keyl0ve
0
910
Other Decks in Programming
See All in Programming
torikago - Ruby::Boxで照らすモジュラモノリスの実行境界
se4weed
1
350
AI時代のPHPer生存戦略 ~「言語、もうなんでもよくない?」に本気で向き合う~
vivion
0
300
AI時代に設計が 最大の生産性レバーになる 意図駆動開発とデータを消さない設計|Don't Delete Your Data or Your Intent — Design as the Deepest Lever in the AI Era
tomohisa
1
730
What's New in Android 2026
veronikapj
0
250
【QA Test Talk Vol.8】AI-DLC による Whole Team Approach の加速
pkshadeck
PRO
0
120
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
550
人間の目はかわらない、だからJPEGは30年もつ
yuzneri
12
18k
複数の Claude Code が"放置"されてしまう問題をCLI ダッシュボードを自作して解決した話
sumihiro3
1
670
その節約、円になってますか?
isamumumu
1
700
関東Kaggler会_NVIDIA_Nemotron_コンペ_振り返り
rick_ds
0
480
夏だ!祭りだ!祭りとはドメインモデリングでは?
ryugen04
0
190
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
540
Featured
See All Featured
BBQ
matthewcrist
89
10k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
240
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
119
120k
We Have a Design System, Now What?
morganepeng
55
8.3k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.9k
The World Runs on Bad Software
bkeepers
PRO
72
12k
WCS-LA-2024
lcolladotor
0
790
Tell your own story through comics
letsgokoyo
1
1k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.8k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.9k
Transcript
作って学ぶ GraphQL Go Conference mini 2022 Autumn IN SENDAI Kyo
Sato
Shopify No-Code Mobile-App VIP Appify ってなに?
Contents - 自己紹介 - GraphQL について - 終わりに
Contents - 自己紹介 - GraphQL について - 終わりに
- GraphQL について理解を深めたかった - GraphQL を導入することで得られる メリットについて整理したかった - Appify で使用されている技術
理由
自己紹介
自己紹介 Name: きょー。 HN: Keyl0ve Hobby: 温泉、旅行、食べ歩 Univ. : 会津大学
B3
GraphQLについて 目標: - GraphQL という技術を広める - 実際にサーバを立てて試してもらう
GraphQL - Facebook - OSS - API のために作られた クエリ言語 -
既存のデータに対するクエリ を実行するランタイム
GraphQL のメリット -クライアントはスキーマをもとに、 欲しいフィールドだけをリクエストできる -リレーションがある値は一度のリクエストで 取得できる -スキーマをもとに開発するので型の不一致が 起きない
GraphQL のメリット -クライアントはスキーマをもとに、 欲しいフィールドだけをリクエストできる -リレーションがある値は一度のリクエストで 取得できる -スキーマをもとに開発するので型の不一致が 起きない
GraphQL のメリット -クライアントはスキーマをもとに、 欲しいフィールドだけをリクエストできる -リレーションがある値は一度のリクエストで 取得できる -スキーマをもとに開発するので型の不一致が 起きない
REST vs GraphQL https://qiita.com/shunp/items/d85fc47b33e1b3a88167
REST vs GraphQL HTTP requests HTTP responses GET /api/user?id=1 GET
/api/address?user_id=1 { ”id” : 1, “name” : “user1” } { ”street” : “Aoba street”, “city” : “Sendai city” }
REST vs GraphQL HTTP requests HTTP responses GET /api/user?id=1 GET
/api/address?user_id=1 { ”id” : 1, “name” : “user1” } { ”street” : “Aoba street”, “city” : “Sendai city” } 2回 API を叩いてる!!
REST vs GraphQL HTTP requests HTTP responses GET /api/user?id=1 GET
/api/address?user_id=1 { ”id” : 1, “name” : “user1” } { ”street” : “Aoba street”, “city” : “Sendai city” } 2回 API を叩いてる!!
REST vs GraphQL HTTP requests HTTP responses POST /graphql query
{ user(id: 1){ id } } { ”user” : { “id”: 1, } }
REST vs GraphQL HTTP requests HTTP responses POST /graphql query
{ user(id: 1){ id name } } { ”user” : { “id”: 1, “name”: “user1” } }
REST vs GraphQL HTTP requests HTTP responses POST /graphql query
{ user(id: 1){ id name address{ street city } { ”user” : { “id”: 1, “name”: “user1”, “address”: { “street”: “Aoba street”, “city”: “Sendai city” } } }
REST vs GraphQL HTTP requests HTTP responses POST /graphql query
{ user(id: 1){ id name address{ street city } { ”user” : { “id”: 1, “name”: “user1”, “address”: { “street”: “Aoba street”, “city”: “Sendai city” } } } 1 回 API を叩くだけで良い
GitHub の repository を取ってくる REST https://api.github.com/users/Keyl0ve/repos GraphQL https://api.github.com/graphql
GitHub の repository を取ってくる REST https://api.github.com/users/Keyl0ve/repos GraphQL https://api.github.com/graphql 通信の効率は GraphQL
の方が上
GraphQL のメリット -クライアントはスキーマをもとに、 欲しいフィールドだけをリクエストできる -リレーションがある値は一度で取得できる -スキーマをもとに開発するので型の不一致が 起きない
強い型付けが採用されている - パラメータの定義には、スキーマ 定義言語(SDL)が使用されてい る - クライアントに公開されるすべて のAPIはSDLで記述されている
GraphQL のデメリット - クエリが複雑になる可能性 - クエリ伝播の問題につながるかもしれ ない - 学習の難しさ -
特にスキーマの設計
クエリ伝播の問題、スキーマ設計の難しさ query { user(id: 1){ id name address{ street city
history{ people awards{ year{ awardName personName } } sample{ sample sample sample } sample{ sample
クエリ伝播の問題、スキーマ設計の難しさ query { user(id: 1){ id name address{ street city
history{ people awards{ year{ awardName personName } } sample{ sample sample sample } sample{ sample スキーマを把握していないと、サーバー にとって非常に時間のかかる処理のクエ リを送ってしまう可能性がある
GraphQL サーバを立てよう - gqlgen を使ってサーバ 立ててみた - request から respons
まで
https://qiita.com/Keyl0ve/items/e88b83c13fb86b7c9908 GraphQL、gqlgen を使って サーバ を立てる
終わりに GraphQL、REST 使い分け の判断が重要
Thanks for listening !! Twitter: Keyl0ve_