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入門.pdf
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
spycwolf
November 19, 2024
Technology
350
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
アプリエンジニアのためのGraphQL入門.pdf
spycwolf
November 19, 2024
More Decks by spycwolf
See All by spycwolf
デザインシステムを利用したSwiftUIによるアプリ開発事情
spycwolf
1
880
Other Decks in Technology
See All in Technology
2026TECHFRESH畢業分享會 - Lightning Talk - 打造精準高效的 MCP 設計模式與測試實務
line_developers_tw
PRO
0
720
JSAI2026 オーガナイズドセッションOS-27「不動産とAI」趣旨説明 / JSAI2026 Organized Session OS-27 “Real Estate and AI”: Statement of Purpose
ykiyota
0
220
Kubernetesにおける学習基盤とLLMOpsの概要
ry
1
230
MIERUNE JCT 発表資料「宇宙から伊能忠敬ごっこ」
syuchimu
0
200
LLMにもCAP定理があるという話
harukasakihara
0
280
Dario Amodi『Policy on the AI Exponential』を理解する
nagatsu
0
210
作って終わりにしない タイミーのセマンティックレイヤー育成の現在地
chanyou0311
3
2.1k
実装は速くなった、レビューはどうする? ― 自身のレビューをAIで再現させるサーヴァントエンジニアリングのすゝめ / Implementation got faster. So what about reviews? — An invitation to Servant Engineering: Recreating your own code reviews with AI
nrslib
8
4.6k
Snowflakeと仲良くなる第一歩
coco_se
4
410
On-behalf-of Token exchange with AgentCore Identity
hironobuiga
2
140
手塩にかけりゃいいってもんじゃない
ming_ayami
0
240
【Cyber-sec+】経営層を"動かす"ための考え方
hssh2_bin
0
120
Featured
See All Featured
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
160
Scaling GitHub
holman
464
140k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
720
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
370
The SEO identity crisis: Don't let AI make you average
varn
0
490
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
250
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Information Architects: The Missing Link in Design Systems
soysaucechin
0
970
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
420
Git: the NoSQL Database
bkeepers
PRO
432
67k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
310
Transcript
アプリエンジニアのための GraphQL⼊⾨
note inc. ‧2024年2⽉にnoteにジョイン ‧note Appチームリーダー ‧2015年〜モバイルアプリを専⾨に扱うようになる ‧それ以前はPHPやRubyでのバックエンド開発がメイン Spycwolf Kota KANEKO
2
note inc. GraphQLとは https://graphql.org/ • API のクエリ⾔語であり、既存のデータを使⽤してそれらのクエリを実⾏するた めのランタイムです。GraphQL は API
内のデータの完全でわかりやすい説明を 提供し、クライアントが必要なものだけを正確に要求できるようにします。 • GraphQL クエリを API に送信すると、必要なものだけが正確に取得されます。 それ以上でもそれ以下でもありません。GraphQL クエリは常に予測可能な結果 を 返します。 • GraphQL クエリは、1 つのリソースのプロパティにアクセスするだけでなく、そ れらの間の参照もスムーズに追跡します。⼀般的な REST API では複数の URL か らの読み込みが必要ですが、GraphQL API では 1 回のリクエストでアプリに必要 なすべてのデータを取得します。
note inc. GraphQLとの出会い • GraphQLは元々Facebookの内部で開発されたもので、2015年に⼀般に公開さ れ、その後、2018年に現在のGraphQL Foundationに移譲された • 2017年に新規アプリサービスの開発に伴い、当時のチームメンバーとGraphQL の導⼊を決めた
• APIとクライアントアプリとを並⾏してゼロから開発するタイミングで、関係す るエンジニア4⼈全員がAPIもアプリも両⽅を開発していった GraphQL導⼊の判断 • 実装する前段階の設計についてほぼ検討する箇所がない • REST APIは会社ごと、チームごとに設計が異なり、新規に開発するにも設計部分 に検討が必要そうだった • 単純に新しいものを使ってみたかった!
note inc. 当時の感想 • 当時はまだ細かい配慮が必要ではあったが、とにかく直感的に実装しやすい • indexとshowの区別を厳密に考慮しなくても後々困ることが少ないため、クライ アント側の画⾯要件が固まっていなくてもAPI側の開発を進められる • REST
APIに対しても当時からCodegeneratorはあったが、Apolloが扱いやすい • Grapiqlのようなプレイグラウンド環境が標準で備わっていて、クライアントか らのスキーマ確認&レスポンス確認がしやすい サーバーサイドの開発に慣れていないモバイルアプリエンジニアで も実装しやすい!
note inc. 覚えておくべきことはたった3つ
note inc. Schemaを定義する • 取得系はQuery、更新系はMutationという概 念 • 基本的にはリソースごとに取得できるカラム 情報を定義する •
ここで定義するスキーマは、そのままクライ アントからクエリとして指定できるものにな る • QueryもMutationもinputとして引数を設定 できる • 基本的にはこれだけ
note inc. Resolverを定義する • Resolverはリソースとスキーマとの関連を定 義する • データベースから取得したデータをそのまま スキーマに当てはめる場合が多いが、取得し たデータを加⼯して返却する場合もある
• UseCase的なレイヤー
note inc. Serviceを定義する • データベースとのやり取りは別定義にする ケースが多い • ここで定義したデータ取得する、もしくは更 新系の処理を⾏う •
Repository、DataSource的な役割
note inc. プロジェクトの覗きかた • graphqlはエンドポイントが1つなので、/grapql というディレクトリを探す • その配下に schema や
resolver などが⾒つかるはず • データリソースへのアクセスは resolverから辿れるはず • レスポンスを確認したいときは schema のネーミングから、該当する resolver を探す • resolver の定義を確認すれば何をしているのか、どこからデータを持ってきてい るのか、どこでデータを処理しているのかがわかるはず
note inc. 実際にプロダクトで扱うには3つ だけ理解しておけばいいなんてこ とはありません!
note inc. 普段あまりAPIの実装をしたこと がない⽅もチャレンジしてみてく ださい
Thank you !