Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
はじめてのGraphQLスキーマ設計
Search
rikuson298
September 04, 2019
Technology
13
8.5k
はじめてのGraphQLスキーマ設計
GraphQLのよいスキーマ設計についてです。
rikuson298
September 04, 2019
Tweet
Share
Other Decks in Technology
See All in Technology
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
joker1007
20
9.3k
VCC 2025 Write-up
bata_24
0
140
OpenAI gpt-oss ファインチューニング入門
kmotohas
2
670
組織観点からIAM Identity CenterとIAMの設計を考える
nrinetcom
PRO
1
130
Green Tea Garbage Collector の今
zchee
PRO
2
360
Tomorrow graphlib, Let us use everybody
hayaosuzuki
0
150
pprof vs runtime/trace (FlightRecorder)
task4233
0
140
extension 現場で使えるXcodeショートカット一覧
ktombow
0
110
API提供者のためのMCPサーバー設計ガイド / MCP Server Design Guide for API Providers
yokawasa
0
240
全てGoで作るP2P対戦ゲーム入門
ponyo877
3
1.2k
避けられないI/O待ちに対処する: Rails アプリにおけるSSEとasync gemの活用 / Tackling Inevitable I/O Latency in Rails Apps with SSE and the async gem
moznion
2
1.8k
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
9k
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
51k
Unsuck your backbone
ammeep
671
58k
Bash Introduction
62gerente
615
210k
The Power of CSS Pseudo Elements
geoffreycrofte
78
6k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Large-scale JavaScript Application Architecture
addyosmani
513
110k
Building an army of robots
kneath
306
46k
Music & Morning Musume
bryan
46
6.8k
Transcript
はじめての 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 サンプルのスキーマ
15 Agenda 1. 実装の詳細を含めない 2. ビジネスロジックを提供する 3. まとめ
16 サンプルに仕様追加 カードにタグを設定できる仕様に
17 サンプルのテーブル構造 List - id - title Card - id
- 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パターン 実装の詳細が含まない ↓ バックエンドの実装変更による影響を受けづらい
25 Agenda 1. 実装の詳細を含めない 2. ビジネスロジックを提供する 3. まとめ
26 サンプルに仕様追加 カードが作成から一定期間経過すると変色し、通知される仕様に
27 サンプルのテーブル構造 List - id - title Card - id
- 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パターン バックエンドにビジネスロジックを統一でき フロントエンドとの二重管理を防げる
35 Agenda 1. 実装の詳細を含めない 2. ビジネスロジックを提供する 3. まとめ
36 まとめ • 適切なスキーマ設計により、バックエンドとフロントエンドの依存を 減らせて幸せになれる • スキーマに実装の詳細を含めない ◦ 安直にテーブル構造と同じにするのはダメゼッタイ •
ビジネスロジックも提供する ◦ ロジックの二重管理から開放される
37 We Are Hiring! A1A