GREE Tech Conference 2020 で発表された資料です。 https://techcon.gree.jp/2020/session/Session-2

1. NuxtJS + REST APIで
運用中サービスをNuxtJS + GraphQL
に変更したことによる光と影
アウモ株式会社 エンジニアチームマネージャー 村田翔

2. 自己紹介
2
• 名前
• 村田 翔
• 担当
• サーバーサイド兼フロントエンドエンジニア
• メインはRuby on Rails
• aumo歴
• 3年弱(サーバーサイドでは最古参)
• 旅行好きなのもあって、aumoに長らく在籍

3. 3
ⓘ Start presenting to display the poll results on this slide.
aumoはご存知ですか？

4. • おでかけ領域をメインに、旅行やグルメ情報をお届けするメディア
• アプリ
• Webサービス
aumoはご存知ですか？
4
記事サイト 比較サイト <- 今回NuxtJS + GraphQLに変更した対象

5. 5
記事 × SNS
iOS
Android

6. 6
記事 × ユーザー生成コンテンツ

7. 7
記事 × ユーザー生成コンテンツ × ホテル × 宿泊プラン横断検索

8. 8
記事 × ユーザー生成コンテンツ × グルメ

9. 9
記事 × ユーザー生成コンテンツ × レジャー・ショッピング

10. 1.なぜREST APIからGraphQLに変更したのか
2.GraphQL化して見えたこと
• 光
• エンドポイント
• 仕様変更
• 影
• N+1
• エラーハンドリンク
• ログ解析
今日お伝えすること
10

11. 1.なぜREST APIからGraphQLに変更したのか
2.GraphQL化して見えたこと
• 光
• エンドポイント
• 仕様変更
• 影
• N+1
• エラーハンドリンク
• ログ解析
今日お伝えすること
11

12. 12
ⓘ Start presenting to display the poll results on this slide.
GraphQL使っていますか？

13. • バックエンド
• Ruby on Rails
• REST API
• GraphQL
• graphql
• graphql-batch
• graphiql-rails
• フロントエンド
• NuxtJS
• ログ監視
• Papertrail
• Sentry
構成
13

14. 構成
14
Amazon EC2 Amazon EC2ELB
サブドメインで
3サイトを同一インスタンスに搭載
フロントエンド バックエンド

15. 構成
15
Amazon EC2 Amazon EC2ELB
サブドメインで3サイト搭載
• middlewareでFQDN毎にパスチェック
• 各トップページはFQDNを元にコンポーネント出しわけ
• 各詳細ページはNuxtJSのディレクトリ規約に沿って設置
フロントエンドでのサイト分割

16. ● エンドポイントを極力増やしたくない
● 工数削減
16

17. 初期から3サイト作成
という要件なのかというと...
17

18. 初期要件
18
• ホテルの比較サイトを作りましょう
• 単一サイトなので既存の記事サイト同様にバックエンドはREST API
でいいか

19. • グルメのサイトも作りましょう
• バックエンドはAPIのエンドポイント増やして対応すればいいか
要件追加
19

20. 要件追加
20
• レジャー・ショッピングのサイトも作りましょう
• さらに別ジャンルで展開する可能性出てくるなこれ🤔
• APIのエンドポイントを都度増やしていくのは何だかなぁ

21. 要件追加
21
• 各サイトを巡回されるような動線になる要素欲しいですね
• 各サイト用に用意しているAPIエンドポイントそれぞれ修正いるな
• API多いと作業煩雑だし、また類似の要件追加くるだろなこれ 🤔

22. そこで...
22

23. • クエリ言語
• エンドポイント単一
• 必要な情報だけ取得できる
• クエリで指定したフィールドのみ返却される
• Facebook社が2012年から開発
• 採用している組織はFacebook、GitHub、PayPalなど数百を越す
GraphQLとは
23

24. 各サイトで必要な情報を共通のエンドポイントで
網羅できるのは、実装が楽になりそうな予感！
※新しい技術を取り入れたい欲有あり
24

25. 実際にREST API -> GraphQL化してみた
25

26. 1.なぜREST APIからGraphQLに変更したのか
2.GraphQL化して見えたこと
• 光
• エンドポイント
• 仕様変更
• 影
• N+1
• エラーハンドリンク
• ログ解析
今日お伝えすること
26

27. エンドポイント
27
[GET] /api/v1/hotels
[GET] /api/v1/hotels/{hotel_id}
[GET] /api/v1/hotels/search
[GET] /api/v1/gourmets
[GET] /api/v1/gourmets/{gourmet_id}
・
・
・
ルーティング追加して、
コントローラー追加して、
ビュー追加して・・・
• サイト追加毎に増えていくエンドポイント...

28. • エンドポイント単一
エンドポイント
28
[GET] /api/v1/hotels
[GET] /api/v1/hotels/{hotel_id}
[GET] /api/v1/hotels/search
[GET] /api/v1/gourmets
[GET] /api/v1/gourmets/{gourmet_id}
・
・
・
ルーティング追加して、
コントローラー追加して、
ビュー追加して・・・
[POST] /graphql
スキーマとフィールド更新のみ
×

29. • 各サイトの詳細ページに周辺施設情報の要素追加したい
画面仕様変更への対応
仕様変更
29

30. • REST APIの場合
• バックエンド
• 対象エンドポイントのレスポンスに要素追加 or エンドポイント追加
• フロントエンド
• 新規要素表示
• エンドポイント追加の場合は新たに呼び出し追加
各サイトの詳細ページに周辺施設情報の要素追加したい
仕様変更
30

31. • GraphQLの場合
• バックエンド
• スキーマとフィールド更新
• フロントエンド
• 新規要素表示
• クエリに新規で追加する要素を追記
各サイトの詳細ページに周辺施設情報の要素追加したい
仕様変更
31

32. 追加の場合はあまり工数的にかわらなそう 🤔
各サイトの詳細ページに周辺施設情報の要素追加したい
仕様変更
32

33. • REST APIの場合
• バックエンド
• 対象のエンドポイントのレスポンスから削除 or エンドポイント追加
• フロントエンド
• 要素削除
各サイトの詳細ページに周辺施設情報の要素削除したい
仕様変更
33

34. 各サイトの詳細ページに周辺施設情報の要素削除したい
仕様変更
34
• GraphQLの場合
• バックエンド
• そのまま
• フロントエンド
• 要素削除

35. 各サイトの詳細ページに周辺施設情報の要素削除したい
仕様変更
35
• 要素削除の場合はフロントエンドの修正だけでいける
• バックエンドは対象の要素をクエリで指定されない限り、その要素を
取得する処理は走らないため無駄が出ない

36. 1.なぜREST APIからGraphQLに変更したのか
2.GraphQL化して見えたこと
• 光
• エンドポイント
• 仕様変更
• 影
• N+1
• エラーハンドリンク
• ログ解析
今日お伝えすること
36

37. • スキーマ毎にクエリが走る
associationが適切なタイミングでeager loadされていない
N+1
37

38. • loadの該当fieldを要求されたときだけeager loadが走り、事
後でWHERE INされる
graphql-batchを導入
N+1
38

39. • フロントエンドでレスポンスステータスによるエラーハンドリ
ングができない
GraphQLは常にレスポンスステータス200を返却する
エラーハンドリング
39
×

40. • catchの中でerror関数を呼ぶ
レスポンスステータスによるエラーハンドリングは行わない
エラーハンドリング
40

41. • エンポイントが単一なため全て request_uri: /graphql
• レスポンス速度の調査などで問題箇所の洗い出しが困難
リクエストパス毎の解析ができない
ログ解析
41

42. • リクエストボディ毎に分けることで呼び出し箇所の分類できる
• レスポンス速度などに問題がある箇所の特定できる
リクエストボディまでログに出力する
ログ解析
42

43. まとめ
43

44. ● エンドポイントを極力増やしたくない
○ 同じ情報を複数サービスで使い回す場合に有効
● 工数削減
○ 画面要件が頻繁に変わるサービスでは効果高い
44
達成
達成

45. 45