Laravel + Lighthouseで始める低コストなGraphQL入門

PHP Conference Japan 2020 Re:born
https://phpcon.php.gr.jp/2020/
#phpcon #phpcon2020 #track4

Session Abstract
https://fortee.jp/phpcon-2020/proposal/cfc59cee-8ab9-4b2b-9e42-002ae5b84023

Transcript

1. Laravel + Lighthouseで始 める低コストな GraphQL入門
2. Introduction 2
3. コメントお待ちしてます！ Twitter ▹ #phpcon2020 ▹ #phpcon ▹ #track4 Discord ▹ track4--4-b-laravel-lighthouse 3
4. Introduction GraphQLの知識はどれぐらいありますか？ ▹ 名前は知ってる ▹ そこそこ知ってる ▹ 実装したことある 4
5. Introduction 今回の仕様だとGraphQL良さそうじゃない？ とか… 詳しくは知らんけどGraphQL良いらしいから それで作ってよ とか… 5
6. Introduction でも自分、RESTしか触ったことないし… そもそもGraphQLってなに…？ 6
7. Introduction （できれば使い慣れた言語で） 開発できる方法を知っておきたい 7
8. Introduction そんなあなたのために 8 × Lighthouse
9. Lighthouse ▹ Laravelのライブラリ ▹ GraphQLを導入可能 9
10. Introduction 特徴 めっちゃ簡単 10
11. このセッションの対象聴者 11
12. 対象聴者 ▹ チュートリアルやってみた！ ▹ 簡単なCRUDできた！リレーションもできた！ ▹ めっちゃ便利！！ 12 でも実際に開発するには どうすればいいの…？ と悩んでいる方
13. “ このセッションで 得られるもの 13
14. Outcome in Session PHPerが自信を持って GraphQLを選ぶために必要な 判断材料 14
15. Step 0. Today’s Contents
16. Today’s contents ▹ GraphQLの概要（3分） ▹ Lighthouseの特徴（5分） ▹ Sample code（3分） ▹ 実戦での実装方法（7分） 16
17. 今日触れないこと NOT today’s contents GraphQLの詳細な説明 Lighthouseのチュートリアル Subscriptionに関して 17
18. 注意 本資料は2020/12/12時点での内容です ▹ Lighthouse v4.18.0 ▹ 近々v5.0.0がくる（v5.0-beta-1） 18
19. Step 1. What is GraphQL?
20. GraphQLとは？ ▹ クライアント/サーバー通信のための言語仕様 ￭ インターネットのための問い合わせ言語 ￭ Facebookが2015年に開発 ▹ 取得過剰や取得不足などのRESTの問題を解決 20
21. RESTの主な問題点 取得過剰 必要のないデータまで取得してしまう 取得不足 リレーション先のデータを取得しようとすると複数リク エストが必要 21
22. “ GraphQLを選ぶ際の 注意点 22
23. GraphQLは RESTの代わりになるわけではない GraphQLを選ぶ際の注意点 23
24. GraphQLとREST GraphQLとRESTの使い分けが大事 RESTが適合しない状況に対応するために作られたの がGraphQL ▹ 一対多, 多対多の関係が多い ▹ データの依存関係のネストが深い ▹ 公開API or エンドポイントが多い 24
25. GraphQLとREST GraphQLとRESTの使い分けが大事 RESTが適合しない状況に対応するために作られたの がGraphQL ▹ 一対多, 多対多の関係が多い ▹ データの依存関係のネストが深い ▹ 公開API or エンドポイントが多い 25 マッチしないならRESTを使った方が良い ※ ※諸説あり。
26. 取得過剰や取得不足を解決 RESTとは上手く使い分ける 26 Step 1. Summery GraphQLの概要
27. Step 2. Features of Lighthouse
28. Lighthouseの特徴 SDL First Laravel Friendly Optimized for Eloquent 28
29. Features of Lighthouse 29 SDL First
30. SDL First ▹ SDL = Schema Definition Language ￭ → スキーマ定義言語 ￭ 拡張子: .graphql ▹ Directiveで簡単に実装 ￭ スキーマに追記することで様々な機能が追加可能 ￭ コードすら書かなくていい場合もある 30
31. 31 SDL オブジェクトを定義 QueryやMutationで オブジェクトに対する ふるまいを定義 Query：Read Mutation：Create, Update, Delete Subscription：WebSocket
32. 32 Directive リレーションを定義 ペジネーションを追加 バリデーション定義 create機能を実装 認証機能を実装
33. Features of Lighthouse 33 SDL First Laravel Friendly
34. Laravel Friendly Laravelの機能がだいたい全部使える ▹ GraphQLはエンドポイントが単一（ POST /graphql） ▹ RouteとControllerはSDLが受け持つ 34
35. 35 Route REST Global Middleware Middleware schema Resolver Model /graphql /others Lighthouse @method
36. 36 Route REST Global Middleware Middleware schema Resolver Model /graphql /others Lighthouse Directive ・CRUD ・Validation ・Authentication ...etc @method
37. 37 Route REST Global Middleware Middleware schema Resolver Model /graphql /others Lighthouse Directive ・CRUD ・Validation ・Authentication ...etc @method 実質RouteとControllerの役割 全体構造はMVCと大差ない
38. Features of Lighthouse 38 SDL First Optimized for Eloquent Laravel Friendly
39. Optimized for Eloquent 既存のEloquentモデルをそのまま使え る ▹ リレーション定義 ▹ 独自のメソッドを追加 39
40. 40 Optimized for Eloquent リレーション定義 ▹ 自動で紐づけてくれる
41. 41 Optimized for Eloquent 独自メソッドの追加 ▹ Modelに定義するだけで呼び出せる ▹ 自由に引数を渡すことも可能
42. SDL First GraphQLのスキーマファースト Optimized for Eloquent 既存のEloquentモデルを活用し、 最適化されたデータベースクエリをすぐに作成可能 Laravel Friendly Laravelの上にGraphQLサーバーを構築するため、 使い慣れた概念や機能を利用可能 42 Step 2. Summery Lighthouseの特徴
43. Step 3. Sample code
44. Schema ▹ Object：データ定義 ▹ Query：読み取り ▹ Mutation：更新 ▹ Subscription：リアルタイム通信 44
45. Object 45 Object定義 Modelと一対一 ▹ クライアントが参照するデータ構造 ▹ Modelと一対一
46. Query 読み込み系 ▹ users: 複数取得 ▹ user: 単体取得 46 users list取得（ペジネーション付き） user get取得（ID指定可能）
47. Mutation 書き込み系 ▹ Create ▹ Update ▹ Delete 47
48. 48 Create create Directiveを追加 Mutation: 書き込み系処理 引数を設定
49. 49 Create mutationのくくりに入 れてリクエスト 作成されたデータが レスポンス
50. Schema CRUDできた！ 50
51. Schema Lighthouse 完全に理解した 51
52. 52 schema.graphqlしか書いてない…？
53. ビジネスロジック どうすればいいの？
54. Step 4. Implementation Method
55. 実戦での実装方法 ▹ ロジックはResolverかMethod ▹ レスポンスは必ずModel ▹ できる限りDirectiveを使う 55
56. Resolver and Method ▹ Resolver ￭ 独自のクエリを定義 ▹ Method ￭ 独自のカラムを追加 56
57. の前に 全体像の把握 57
58. 58 Route REST Global Middleware Middleware schema Resolver Model /graphql /others Lighthouse Directive ・CRUD ・Validation ・Authentication ...etc @method
59. 59 Route REST Global Middleware Middleware schema Resolver Model /graphql /others Lighthouse Directive ・CRUD ・Validation ・Authentication ...etc @method ビジネスロジックの置き場所
60. Resolver Use case ▹ そのクエリ自体に対するロジック ▹ 複数のカラム・データが影響しあう処理 60
61. 61 Resolver クエリの引数からIDを取得 Queryを作成 @fieldでResolverのメソッドを指定 よしなに処理して、 Modelを返す
62. Method 62 Use case ▹ テーブルに存在しないカラムを追加 ￭ そのカラム内だけで処理が完結するもの ▹ 取得したオブジェクトや独自の引数を指定 可能
63. 63 Method カラムを追加 参照するUserモデル内のメソッドを指定 引数はルートオブジェクトを指定可能 引数も指定可能
64. レスポンスは必ずModel 64 ▹ モデル名を参照してモデルとオブジェクトを紐づ けている ▹ 配列や無名クラスでも返せるが困ることがたくさ ん ￭ GraphQLのInterface型やUnion型 ￭ リレーションの自動参照
65. できる限りDirectiveを使う ▹ なんでも揃ってる便利ツール ￭ 実装コストを減らす ▹ 既存のDirectiveで解決できない問題をResolver やmethodで実装する ￭ シンプルで保守性が高くなる 65
66. できる限りDirectiveを使う Directiveも馴染みのあるものばかり ▹ @all, @find ▹ @create, @update, @upsert, @delete ▹ @where, @whereBetween ▹ @hasMany, @belongsToMany ▹ @ordarBy ▹ @with ...and more 66
67. Directiveの欠点 数が多い！ ▹ 60個以上 ▹ ただしメインで使うのは10個弱 67 最低限だけ覚えればOK
68. Resolver and Method ビジネスロジックを実装 Use Directive できる限りDirectiveを使って実装コストを削減 Model Base Modelでデータをやりとり 68 Step 4. Summery Implementation method
69. “ Summarize GraphQLの概要 Lighthouseの特徴 実戦での実装方法 69
70. 開発できる！ 70 必要な情報が集まった ↓
71. 最後に 今回触れなかったこと ▹ GraphQLの設計 ▹ Validate, Error Handling, Test 71
72. GraphQLの重要度 設計 72 実装 7：3 Lighthouse 実装を楽にして設計に時間をかけられるよ うにする
73. GraphQLの設計 設計は設計で勉強する必要がある （データベース設計を思い浮かべてもらえれば） おすすめ書籍 初めてのGraphQL --Webサービスを作って学ぶ新世 代API 73 参照：https://www.oreilly.co.jp/books/9784873118932/
74. 最後に Lighthouseで GraphQLを はじめよう！ 74
75. THANKS! 良きGraphQL開発を！ Yumemi.inc Daisuke Endo | あきの/D-En 　 @DddEndow
76. おまけ 76
77. 77 GraphQL Client ▹ 初めてGraphQL触る人におすすめ ￭ Altair GraphQL Client ▹ 使い慣れたツールで ￭ Insomnia REST Client ￭ POSTMAN ▹ あまりおすすめはしない ￭ GraphQL Playground
78. Interface & Union 78 Interface 元の型を継承 Union 複数の型を統括 返り値に指定可能
79. Step n. Design pattern
80. How to start GraphQL? 実装するために必要なものは揃った ▹ GraphQLの概要 ▹ Lighthouseの特徴・知識 ▹ 実戦で使うための設計パターン 80
81. GraphQLの重要度 設計 81 実装 7：3
82. GraphQLの重要度 設計 82 実装 7：3
83. GraphQLの設計 83 1. オブジェクト データ構造の定義 2. クエリー クライアントが実行する操作
84. Object & Query 84 User Post Comment Object Relation Query (Mutation) posts user comments post user comments request client
85. Object & Query 85 User Post Comment Object Relation Query (Mutation) posts user comments post user comments request client RDSと考え方は一緒 クライアント向けのDB設計
86. Object設計のポイント 86 ▹ クライアントへリソースをどう見せるか（許可する か）を意識する ▹ 正規化は大事 ▹ 必ずしもサーバー側のテーブルと同じ構造である 必要はない（でもできる限り揃えた方が楽）
87. Object設計のアンチパターン 87 レスポンス毎にオブジェクトを作る ▹ 正規化できてない ▹ 同じテーブルに対して複数のオブジェクトが参照するため、複雑 になる
88. Query設計のポイント 88 ▹ Objectに対してどんなデータアクセスを許可するか で考える ￭ 使い方はクライアント次第 ▹ SQLと同じように考えて問題ない ￭ CRUD
89. Query設計のアンチパターン 89 クライアントのページ毎にクエリを作ってしまう ▹ 同じデータは同じ場所、同じクエリからのみ取得する ▹ 一つのデータに対して複数のクエリからアクセスできてはいけな い
90. 90 Design pattern User Post Comment client どんなjoinを許可する か どんなクエリを許可する か クライアントに対して どんなJoin、どんなクエリを許可するか ▹ 同じデータは同じところから取得する （正規化） ▹ どんなクエリを叩くかはクライアント次第 Query 90
91. 91 Design pattern User Post Comment client どんなjoinを許可する か どんなクエリを許可する か クライアントに対して どんなJoin、どんなクエリを許可するか ▹ 同じデータは同じところから取得する （正規化） ▹ どんなクエリを叩くかはクライアント次第 Query 91 クライアント向けのRDB設計 インターフェースがAPIなだけ
92. Q＆A
93. Q1. Q. subscription(websocket)はどうなの？ A. PusherやWebsocketサーバー立てればできるけどけ ど、インフラのことを考えるとかなり面倒。 リアルタイム通信を主軸にするならnode.jsやgo、 AWS Appsyncの方がいいと思います。 93
94. Q2. Q. 本番環境のスキーマ定義が更新されない。 A. schema.graphqlは自動でキャッシュされる。 devならLIGHTHOUSE_CACHE_ENABLEをfalse に、本番では更新したらキャッシュを削除して再生成 すること。 94
95. Q3. Q. @middlewareについて注意点ある？ A. V5.0で廃止されることになった。 認証は@authや@guardに、その他はカスタムディレ クティブを作成して定義 95
96. Q4. Q. うまくエラーハンドリングできないんだけど。 A. 専用のエラーハンドラーやExceptionの定義方法があ るのでそれを使用してください。 また基本的にエラーでもHTTP Statusは200で返るの で注意が必要です。（apolloクライアントなど使ってい れば自動でやってくれそうな気もするけど） 96