はじめてのGraphQLスキーマ設計

0b5b1bd90f68883f7df1146c86e87c59?s=47 rikuson298
September 04, 2019

 はじめてのGraphQLスキーマ設計

GraphQLのよいスキーマ設計についてです。

0b5b1bd90f68883f7df1146c86e87c59?s=128

rikuson298

September 04, 2019
Tweet

Transcript

  1. はじめての GraphQLスキーマ設計 2019/9/5 フロントエンドNight #1@ギフティ A1A株式会社 住奥 陸

  2. 2 自己紹介 Name Company Career Twitter Other 住奥 陸(すみおくりく) A1A株式会社(エイワンエイ)

    ワークス → ジラフ → A1A @rikuson298 フロント, バックエンド, データモデリングなどア プリ開発を担当
  3. 3 Vision A1A(社名の由来) B2B をワンランク上に

  4. 4 技術スタック Frontend Backend API

  5. 5 はじめに GraphQLといえば 何を思い浮かべるでしょうか?

  6. 6 GraphQLといえば スキーマ定義の型付けによる 堅牢な開発

  7. 7 GraphQLといえば スキーマ駆動開発による 開発効率の向上

  8. 8 GraphQLといえば GraphQLではスキーマ定義によって フロントとバックエンドの依存を減らせる

  9. 9 GraphQLといえば 良いスキーマ設計されていれば...

  10. 10 これから話すこと メリットを効果的に享受するための スキーマ設計のポイントを説明します。

  11. 11 Agenda 1. 実装の詳細を含めない 2. ビジネスロジックを提供する 3. まとめ

  12. 12 サンプルの説明 簡単なカンバンツールの実装を例に説明します(Trelloみたいな)

  13. 13 サンプルのテーブル構造 List - id - title Card - id

    - label - list_id
  14. 14 サンプルのスキーマ

  15. 15 Agenda 1. 実装の詳細を含めない 2. ビジネスロジックを提供する 3. まとめ

  16. 16 サンプルに仕様追加 カードにタグを設定できる仕様に

  17. 17 サンプルのテーブル構造 List - id - title Card - id

    - label - list_id CardTag - id - card_id - tag_id Tag - id - title 追加
  18. 18 スキーマ設計:NGパターン テーブル構造をそのまま スキーマに反映する

  19. 19 スキーマ設計:NGパターン CardTagは多対多を実現する 関連テーブルであるため 機能には関係がない

  20. 20 スキーマ設計:NGパターン また、多対多の実装方法が 変更された際に修正が必要に

  21. 21 スキーマ設計:NGパターン 実装の詳細をスキーマに含めると バックエンドの実装変更によって フロントエンドが影響を受けやすくなってしまう

  22. 22 スキーマ設計:GOODパターン Card 型に tags フィールドを追加する

  23. 23 スキーマ設計:GOODパターン 関連テーブルを挟まないので フロント側で扱いやすくなる

  24. 24 スキーマ設計:GOODパターン 実装の詳細が含まない ↓ バックエンドの実装変更による影響を受けづらい

  25. 25 Agenda 1. 実装の詳細を含めない 2. ビジネスロジックを提供する 3. まとめ

  26. 26 サンプルに仕様追加 カードが作成から一定期間経過すると変色し、通知される仕様に

  27. 27 サンプルのテーブル構造 List - id - title Card - id

    - label - list_id - created_at
  28. 28 スキーマ設計:NGパターン Card 型のフィールドに created_at のみ追加する

  29. 29 スキーマ設計:NGパターン カードを変色させるために created_at を元に 一定期間経過したかを判定する ビジネスロジックをフロントに持つ必要がある

  30. 30 スキーマ設計:NGパターン 一方、カードの変色を通知するために バックエンドでも同じビジネスロジックが必要に

  31. 31 スキーマ設計:NGパターン created_at のみ提供する ↓ バックエンドとフロントエンドで ビジネスロジックの二重管理になりバグの温床に

  32. 32 スキーマ設計:GOODパターン Card 型のフィールドに created_atをもとに一定期間をど のくらい経過したか判定した corrosion_rateを提供する

  33. 33 スキーマ設計:GOODパターン 統一の corrosion_rate を元にカードの変色と 変色通知を実装できる

  34. 34 スキーマ設計:GOODパターン バックエンドにビジネスロジックを統一でき フロントエンドとの二重管理を防げる

  35. 35 Agenda 1. 実装の詳細を含めない 2. ビジネスロジックを提供する 3. まとめ

  36. 36 まとめ • 適切なスキーマ設計により、バックエンドとフロントエンドの依存を 減らせて幸せになれる • スキーマに実装の詳細を含めない ◦ 安直にテーブル構造と同じにするのはダメゼッタイ •

    ビジネスロジックも提供する ◦ ロジックの二重管理から開放される
  37. 37 We Are Hiring! A1A