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
黒柳シャチ子
June 22, 2024
Programming
710
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ゼロから始める型安全なGraphQL開発
PHPConference福岡2024LT登壇資料
黒柳シャチ子
June 22, 2024
Other Decks in Programming
See All in Programming
これからAgentCoreを触る方へトレンドはGatewayです
har1101
6
500
為什麼你並不需要ViewModel / No, you don't need a ViewModel
lovee
1
300
FDEが実現するAI駆動経営の現在地
gonta
2
200
AI がコードを書く時代における新卒エンジニアの仕事風景 (2026) / New Graduate Engineers in the Era of AI Coding (2026)
sushichan044
0
230
2年かけて Deno に DOMMatrix を実装した話 / How I implemented DOMMatrix in Deno over two years
petamoriken
0
110
エンジニア向け会社紹介/Findy Company Profile
findyinc
6
360k
php-fpmのプロセスが枯渇した日-調査・対処・そして本当にやるべきだったこと-
shibuchaaaan
0
130
「正の参照」と 「負の導出」で組む ハーネスエンジニアリング
cottpan
1
150
Apache Hive: そしてCloud Native Lakehouseへ
okumin
1
170
全PRの83%がAIレビューだけでマージできるようになった開発組織はその後どうなったか
athug
0
300
PHP Application における Kubernetes 内 gRPC 通信
ganchiku
0
530
yield再入門 #phpcon
o0h
PRO
0
720
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.9k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
WCS-LA-2024
lcolladotor
0
750
Marketing to machines
jonoalderson
1
5.6k
Mobile First: as difficult as doing things right
swwweet
225
10k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
620
Claude Code のすすめ
schroneko
67
230k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.5k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.8k
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.3k
Music & Morning Musume
bryan
47
7.3k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Transcript
ゼロから始める 型安全なGraphQL開発 with Laravel + Lighthouse + TypeScript 黒柳シャチ子 /
髙山 伶
・黒柳シャチ子 / 髙山 伶 (@shachi_daikon55) ・所属: ディップ株式会社 ・バイトルなどのWEBアプリ開発 / 3年目
・PHP / TypeScript / AWS … 自己紹介
今日伝えたいこと
GraphQLを使った スキーマ駆動開発
めっちゃいいぞっ 👍
GraphQL使うなら Laravel + Lighthouse
めっちゃいいぞっ 👍
GraphQLでの型安全な 開発体験の良さを
ぜひ皆さんにも伝えたい!!
そんなLTです
まずは GraphQLおさらい
RESTの手法と 比較しながら説明
APIサーバー RESTの場合 クライアント “/users/1” エンドポイント毎に決め られた処理を実行
APIサーバー RESTの場合 クライアント “/users/1” しかしuser情報のうち ”name”しか必要としない場合 エンドポイント毎に決め られた処理を実行
APIサーバー RESTの場合 クライアント “/users/1” ここの取得データが余分 エンドポイント毎に決め られた処理を実行
APIサーバー RESTの場合 クライアント “/users/1” ここの取得データが余分 エンドポイント毎に決め られた処理を実行 リソースのオーバー・アンダーフェッチ
GraphQLの場合
APIサーバー クライアント “/graphql” エンドポイントは一つだけ 必要なデータ のみを クライアントが指定して取得 できる 取れたデータは ”name”だけ
どうやってクライアントは クエリを作るの?
GraphQLでは必ず スキーマと呼ばれる 型を伴ったデータリソースを定義 = I/F まずGraphQLで定義する スキーマ(I/F)を参照
まずGraphQLで定義する スキーマ(I/F)を参照
まずGraphQLで定義する スキーマ(I/F)を参照 この型の、
まずGraphQLで定義する スキーマ(I/F)を参照 このフィールドが欲しい
まずGraphQLで定義する スキーマ(I/F)を参照 User型はこの二つのクエリで提供されている
まずGraphQLで定義する スキーマ(I/F)を参照 User型はこの二つのクエリで提供されている このデータを取得するクエリは
このような形で組み上げられる
このような形で組み上げられる
APIサーバー クライアント 必要なデータ のみを クライアントが指定して取得 できる 取れたデータは ”name”だけ
APIサーバー クライアント 必要なデータ のみを クライアントが指定して取得 できる 取れたデータは ”name”だけ 必要なリソースを柔軟に指定できる オーバー・アンダーフェッチを防げる
APIサーバー クライアント 必要なデータ のみを クライアントが指定して取得 できる 取れたデータは ”name”だけ それが GraphQL
以上GraphQLの 前提知識おさらい
開発体験的に嬉しい点 (クライアント)
・ 欲しいデータを component毎に分けて記述できる ・生成ツールを使って、 GraphQLスキーマの型を クライアントでも利用できる 開発体験的に嬉しい点 (クライアント )
・ 欲しいデータを component毎に分けて記述できる ・生成ツールを使って、 GraphQLスキーマの型を クライアントでも利用できる 開発体験的に嬉しい点 (クライアント ) 簡単に型安全に開発できちゃう
✅
・ 欲しいデータを component毎に分けて記述できる ・生成ツールを使って、 GraphQLスキーマの型を クライアントでも利用できる 開発体験的に嬉しい点 (クライアント )
クエリするデータを component単位で記述する User詳細画面の componentたち UserName.tsx UserEmail.tsx
クエリするデータを component単位で記述する User詳細画面の componentたち UserName.tsx UserEmail.tsx 欲しい
じゃあUser詳細画面でまとめて取得してあげようか User 詳細画面の componentたち UserName.tsx UserEmail.tsx 分配
じゃあUser詳細画面でまとめて取得してあげようか User 詳細画面の componentたち UserName.tsx UserEmail.tsx 分配 ただこれ、
じゃあUser詳細画面でまとめて取得してあげようか User 詳細画面の componentたち UserName.tsx UserEmail.tsx 分配 親 component (page)が
子 component で必要なデータを 知ってなきゃいけない。。。
じゃあUser詳細画面でまとめて取得してあげようか User 詳細画面の componentたち UserName.tsx UserEmail.tsx 分配 もしcomponentの 必要なデータが変わった場合、
じゃあUser詳細画面でまとめて取得してあげようか User 詳細画面の componentたち UserName.tsx UserEmail.tsx 分配 そのcomponentを使っているすべての pageでクエリの書き換えが必要になる 🤨
そこで、
Fragment Colocation という仕組みを使用 UserName.tsx UserEmail.tsx component毎に 欲しいデータを定義
Fragment Colocation という仕組みを使用 UserName.tsx UserEmail.tsx 要は componentたちは 各々欲しいデータを自ファイル中で主張
分配 page側でそのFragment(主張)をまとめる
分配する時 pageは子の欲しいデータについて 関心を持たない 分配
分配する時 pageは子の欲しいデータについて 関心を持たない 分配 欲しいデータの情報が componentの中に閉じる
分配する時 pageは子の欲しいデータについて 関心を持たない 分配 バリ改修しやすい 👍
さらに、
・ 欲しいデータを component毎に分けて記述できる ・生成ツールを使って、 GraphQLスキーマの型を クライアントでも利用できる 実際の開発体制での嬉しみ (クライアント )
GraphQL codegen で GraphQLクエリの型を TypeScriptで使う
UserName.tsx UserEmail.tsx GraphQL codegenを使うと
UserName.tsx UserEmail.tsx Fragmentやクエリを元に GraphQLから型を自動生成してくれる Fragmentを元に、 型を自動生成 Fragmentを元に、 型を自動生成
このFragmentと 型の自動生成を組み合わせると
もし必要なデータに 変更があったとしても User詳細画面の componentたち UserName.tsx UserEmail.tsx 欲しい 追加で 欲しい
componentの Fragmentを追記して UserEmail.tsx 追記
codegenの型生成コマンド を実行するだけで
APIのデータ取得内容を変えられちゃう! 分配 追加取得 できちゃう
それだけで APIのデータ取得内容を変えられちゃう! 分配 追加取得 できちゃう 型のエラーも起きません ✅ API連携での余計な型エラーとは おさらば
それだけで APIのデータ取得内容を変えられちゃう! 分配 追加取得 できちゃう 超簡単に型安全に APIと連携できちゃう ✅
クライアント側はわかったけど サーバー側は難しいのでは?
APIサーバー RESTの場合 クライアント “/users/1” エンドポイント毎に決め られた処理を実行 “/posts” 処理1 処理2
GraphQLの場合
APIサーバー クライアントが何かは あんまり関係ない スキーマのフィールド毎に 決められた処理を実行 ・・・
APIサーバー クライアントが何かは あんまり関係ない スキーマのフィールド毎に 決められた処理を実行 ・・・ めんどくさそう ?
APIサーバー クライアントが何かは あんまり関係ない スキーマのフィールド毎に 決められた処理を実行 ・・・ 大丈夫ですよ 😏
Lighthouseが あるからねぇ!
Lighthouse Laravelフレンドリーな GraphQL FW https://lighthouse-php.com/
Lighthouse APIサーバー Lighthouseのサーバーに スキーマを設置して動作 ・・・
スキーマに直説解決処理を記載していく ・・・ Lighthouse APIサーバー
Lighthouseの強力なスキーマ解決能力 ・ モデル・カラムと名前が一致するスキーマは デフォルトでその値を返してくれる ・ディレクティブ と呼ばれる使い回しの効く備え 付けのスキーマ解決処理が豊富 ・複雑なスキーマの解決は、リゾルバー にまと められる
先ほどのUser型 の実装を考える
これが
こう!
ディレクティブ を使えばシンプルに Lighthouse備え付けの ディレクティブ リレーション id引数一致のUserモデ ルを取得
ディレクティブが ついてないものは自動解決 Userモデルのid, name, emailのカラム値を取得
APIサーバー Lighthouseのおかげで 少ない処理 で多くのフィールドを解決 ・・・
APIサーバー Lighthouseのおかげで 少ない処理 で多くのフィールドを解決 ・・・ 👍 手軽に始められる 👍 ディレクティブのおかげで記述量少なく済む 👍
スキーマファーストなので、 スキーマ駆動開発しやすい
APIサーバー Lighthouseのおかげで 少ない処理 で多くのフィールドを解決 ・・・ PHPerの皆さん LighthouseでGraphQL 触り始めてはいかがでしょう?
APIサーバー Lighthouseのおかげで 少ない処理 で多くのフィールドを解決 ・・・ 触りましょうよ!!!!
いかがだったでしょうか
「なんかよくわからないけど、 面白そうだ!」
そう思っていただけたら 幸いです🙏
まとめ ・ GraphQL + TypeScriptは、すごく簡単に型 安全なAPI連携ができる ・Laravel + Lighthouseはスキーマの解決が 楽。記述量が少なく済む。
・GraphQLの開発は一度仕組みを整えると改 修がほんとにしやすい
カジュアル面談やってます! https://hrmos.co/pages/dip-net/jobs/phperkaigi-dip
ご清聴ありがとうございました!