Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
why we should go with GraphQL
Search
Yan | 近藤智哉
December 12, 2023
Technology
0
98
why we should go with GraphQL
Yan | 近藤智哉
December 12, 2023
Tweet
Share
More Decks by Yan | 近藤智哉
See All by Yan | 近藤智哉
how frontend is constructed
mtyk_15
0
22
Efficient Feature Implementation Using Type Merging
mtyk_15
0
1.1k
DataloaderのGraphQLを超えた活用を考えてみた
mtyk_15
1
150
Other Decks in Technology
See All in Technology
一億総業務改善を支える社内AIエージェント基盤の要諦
yukukotani
9
2.7k
機械学習を「社会実装」するということ 2025年冬版 / Social Implementation of Machine Learning November 2025 Version
moepy_stats
4
2.1k
私も懇親会は苦手でした ~苦手だからこそ懇親会を楽しむ方法~ / 20251127 Masaki Okuda
shift_evolve
PRO
4
540
IPv6-mostly field report from RubyKaigi 2026
sorah
0
250
Digitization部 紹介資料
sansan33
PRO
1
6.1k
Master Dataグループ紹介資料
sansan33
PRO
1
4k
プロダクトマネジメントの分業が生む「デリバリーの渋滞」を解消するTPMの越境
recruitengineers
PRO
2
180
MAP-7thplaceSolution
yukichi0403
2
240
あなたの知らないDateのひみつ / The Secret of "Date" You Haven't known #tqrk16
expajp
0
110
事業部のプロジェクト進行と開発チームの改善の “時間軸" のすり合わせ
konifar
9
2.7k
"なるべくスケジューリングしない" を実現する "PreferNoSchedule" taint
superbrothers
0
130
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
980
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
225
10k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Why You Should Never Use an ORM
jnunemaker
PRO
60
9.6k
Building Adaptive Systems
keathley
44
2.9k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
54k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.8k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Transcript
結局 GraphQL は何がいいのか? Yan
本⽇の資料は Speaker Deck にて公開しています 撮影等ご⾃由に!
今⽇お話すること 1. ⾃⼰紹介 3. GraphQL の特徴 5. GraphQL だからできたこと
1. ⾃⼰紹介 近藤 智哉 (@mtyk_15) Kondo Motoya GraphQL / React
(バックエンド‧フロン トエンドを担当することが多いです) エン‧ジャパン株式会社 → 株式会社 RevComm → Kalonade 株式会社 → SHE 株式会社 🥰 旅⾏
GraphQL 触ったことありますか?
GraphQLとは APIを開発するためのQuery⾔語
3. GraphQL の特徴 グラフ構造がベースになっているクエリ⾔語 ‧クライアントで必要な情報だけ取得できる Schema ベースで開発できる ‧Schema ⾃体に表現⼒がある ‧Schema
をクライアント間 (Backend/Frontend) で共有できる
3. GraphQL の特徴 グラフ構造がベースになっているクエリ⾔語 User を Node として name, email
が Leaf になっている。 type User { name: String! email: String! }
3. GraphQL の特徴 グラフ構造がベースになっているクエリ⾔語 このように他の Node を Leaf として 追加できる。
type Event { title: String! published_at: String! host_user: User }
3. GraphQL の特徴 グラフ構造がベースになっているクエリ⾔語 フロントエンドからは必要な情報 だけを取得できる。 query { getEvent(id: String)
{ title host_user { name } } }
3. GraphQL の特徴 Schema ベースで開発できる - Schema⾃体に表現⼒がある。 Built-inの String, Int,
Float, Boolean, IDといったScalarの他に、独⾃でScalarを定義するこ とができる。 これはバリデーションロジックを含むので、Serializer や Validator としても利⽤できる。 type User { id: ID! name: String! email: String! url: URL! published_at: DateTimeISO! }
3. GraphQL の特徴 Schema ベースで開発できる - Schema⾃体に表現⼒がある。 SchemaにDirectiveを追加することで、クライアントに対して情報や処理を追加できる。 type User
{ id: ID! name: String! email: String! url: URL! @deprecated(reason: "この項目は Event.url に移動しました") published_at: DateTimeISO! }
3. GraphQL の特徴 Schema ベースで開発できる - Schema をクライアント間で共有できる Schema を元に型を⽣成できる。
TypeScript の型を⽣成できるので、Schema を信頼して開発できる。 Schema Entity や Service レベルの型を⽣成 APIClient の型を ⽣成
GraphQL だからできたこと
3. GraphQL だからできたこと Fragment colocation を利⽤した拡張性の⾼いフロントエンド開発 GraphQL の仕様⾃体が Layered Architecture
と相性が良い
3. GraphQL だからできたこと Fragment colocation を利⽤した拡張性の⾼いフロントエンド開発 ‧Component ごとに Fragmentを定義し、Pageで⼀括取得する⽅法 ‧メンテコスト低くオーバーフェッチングを防ぐことができる
3. GraphQL だからできたこと GraphQL の仕様⾃体が Layered Architecture と相性が良い ‧Schemaを設計すると、 Entity
や Service のIFが⼿に⼊る。
GraphQL 良さそうですよね 😃