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

by rikuson298

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

4 技術スタック Frontend Backend API

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

14 サンプルのスキーマ

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

17 サンプルのテーブル構造 List - id - title Card - id - label - list_id CardTag - id - card_id - tag_id Tag - id - title 追加

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

37 We Are Hiring! A1A