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

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

2 自己紹介 Name Company Career Twitter Other 住奥陸（すみおくりく） A1A株式会社（エイワンエイ）
ワークス → ジラフ → A1A @rikuson298 フロント, バックエンド, データモデリングなどアプリ開発を担当

3 Vision A1A（社名の由来） B2B をワンランク上に

4 技術スタック Frontend Backend API

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

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

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

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

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

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

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

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

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

14 サンプルのスキーマ

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

- label - list_id CardTag - id - card_id - tag_id Tag - id - title 追加

18 スキーマ設計：NGパターンテーブル構造をそのままスキーマに反映する

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

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

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

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

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

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

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

- label - list_id - created_at

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

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

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

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

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

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

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

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

37 We Are Hiring! A1A

Other Decks in Technology