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スキーマ設計の悩みどころ/My concerns about GraphQL s...
Search
Takahiro Uchiyama
August 31, 2022
Programming
0
1.5k
GraphQLスキーマ設計の悩みどころ/My concerns about GraphQL schema design
2022年8月31日にGraphQL TokyoでLTした資料です。
Takahiro Uchiyama
August 31, 2022
Tweet
Share
More Decks by Takahiro Uchiyama
See All by Takahiro Uchiyama
日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード / Architectural Decision Records
highwide
24
18k
停止性問題と数 / Halting problem and number
highwide
0
1k
About Rails ConnectionPool
highwide
0
170
How about today's coffee?
highwide
0
460
How to choose "best of the best"
highwide
1
670
A question about private method testing
highwide
0
3.3k
A life-changing innovation for my work-style by IoT
highwide
0
650
a-code-to-rhyme
highwide
3
610
よちがや.rb案内スライド
highwide
1
570
Other Decks in Programming
See All in Programming
DevFest - Serverless 101 with Google Cloud Functions
tunmise
0
140
個人アプリを2年ぶりにアプデしたから褒めて / I just updated my personal app, praise me!
lovee
0
310
月刊 競技プログラミングをお仕事に役立てるには
terryu16
1
1.3k
Azure AI Foundryのご紹介
qt_luigi
1
260
Amazon ECS とマイクロサービスから考えるシステム構成
hiyanger
1
190
JavaScriptツール群「UnJS」を5分で一気に駆け巡る!
k1tikurisu
8
1.3k
SRE、開発、QAが協業して挑んだリリースプロセス改革@SRE Kaigi 2025
nealle
1
3.4k
Kubernetes History Inspector(KHI)を触ってみた
bells17
0
110
2024年のkintone API振り返りと2025年 / kintone API look back in 2024
tasshi
0
180
オニオンアーキテクチャを使って、 Unityと.NETでコードを共有する
soi013
0
390
Fibonacci Function Gallery - Part 2
philipschwarz
PRO
0
230
AWS re:Invent 2024個人的まとめ
satoshi256kbyte
0
150
Featured
See All Featured
A designer walks into a library…
pauljervisheath
205
24k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
3
380
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
11
900
VelocityConf: Rendering Performance Case Studies
addyosmani
327
24k
Scaling GitHub
holman
459
140k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
A Tale of Four Properties
chriscoyier
157
23k
The Invisible Side of Design
smashingmag
299
50k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
GraphQLとの向き合い方2022年版
quramy
44
13k
Transcript
GraphQLスキーマ設計の悩みどころ @highwide 2022.08.31 #GraphQLTokyo LT
自己紹介 highwide (内山 "高広") schema stichingを利用したRails(graphql-ruby)とnode(ApolloServer)によるマイクロサ ービス開発をやっている Backend開発を主業務にしつつ、Frontend(React)も書く 最近のマイブームは、ダイエットと、2歳半の息子と一緒にプラレールをすること
おしごと with GraphQL Webアプリケーション開発で、事業ドメインごとに分割された開発チームの1つに所属 iOS: 2名 / Android: 1名 /
Web Frontend: 1名 / Backend: 2名の計6名 個々人の志向性に基づく職能横断的な取り組みをやっていこうという取り組みの中、チ ーム内でのロールによる垣根は低め そんな感じなので、チーム一丸となってのGraphQLスキーマの設計がやりやすい 特に最近は、いわゆる「スキーマ駆動開発」を意識できていると思う 実装の初期段階で、PdMが書いたProduct Backlog Itemをチームみんなで見ながら、あ あでもないこうでもないと言いながらスキーマ設計をやっている
スキーマ駆動開発 一言でいうと: 「実装する前にGraphQLスキーマ決めちゃおうぜ」開発 一言で言わないと: qsonaさんの資料: GraphQL を活用したスキーマ駆動開発の実践 https://speakerdeck.com/qsona/schema-driven-development-with-graphql 自分でも多少はWeb Frontendを書くので、これが圧倒的に良いものだとわかる
GraphQLスキーマさえ決まっちゃえば、graphql-codegenでTypeScriptの型を生成 できるし、collocationを意識したQueryに対応した型をそのままReact Component のPropsにして...みたいなことができる! 一方で、そんなスキーマ設計手法をとる中で、実際に自分が感じた難しさなどを今日は 話していきたい
たとえばこんなユーザーストーリーを考えてみる カレー屋の業務システム 「カレー屋の業務システムって何?」は、今日は禁句です 普段は店舗で営業をしているが、年に数回、音楽フェスなどのイベントに出店すること で大きな利益を稼いでいる 店舗運営者は出店に向けた予定管理が大事なので、まずは業務システム上で出店予定を 登録/閲覧/更新/削除できるようにしたい
そのうえで、こんな仕様にしたい...! "出店予定"は「開始日」と「終了日」に加えて、 「イベント種別」(ex: "Fuji Pop Festival" "Autumn Sonic" など)」を持つ "出店予定"は一覧画面上、「過去の予定」「直近の予定」「今後の予定」(直近1件よりも
未来)でグルーピングされて表示される 「直近の予定」には「あと◦日」という表示がされ、さらに現在が出店期間なら「出店 期間中」、出店1ヶ月前なら「出店準備期間中」というラベルを表示させる
スキーマ設計悩みどころ ① 画面からの"要請"に応えるインターフェースを考える段階で、どう永続 化されるべきかというロジック/DB設計を頭の中で行う必要がある
スキーマ設計悩みどころ①: "画面"と"永続化"の同時考慮 "出店予定"は「開始日」と「終了日」に加えて、「イベント種別」(ex: "Fuji Pop Festival" "Autumn Sonic" など)」を持つ 予定登録するときの"イベント種別"って、どうやって扱う?
クライアントは文字列で扱えるかもしれないけど、「イベント」そのものを永続化すべ きリソースとして扱った方がいいかも? 「数年間の出店売上をイベントごとにまとめて比較する」みたいな話が今後出てく るかもしれないし... と、なるとスキーマ定義的には、イベント種別のidを送ってもらうべき? フォームにプルダウンで出てくるイベント種別名はどうする? 要件にはないけどイベント種別自体を管理画面からCRUDできるようにすべき?
スキーマ設計悩みどころ ② フロントエンドとバックエンド、どっちでやる?
スキーマ設計悩みどころ②: FE/BEどっちでやる? "出店予定"は一覧画面上、「過去の予定」「直近の予定」「今後の予定」(直近1件より も未来)でグルーピングされて表示される Backendは全ての"出店予定"を返すことのみに徹して、グルーピングはクライアントで やってもらう? ただ、View ComponentとQueryのcollocationを意識するならば、グルーピングごとに Queryできた方が良くない? たとえば「今後の予定」と「過去の予定」で表示すべき項目が違うならば、
Componentも変わってくるし...。
スキーマ設計悩みどころ②: FE/BEどっちでやる? 「直近の予定」には「あと◦日」という表示がされ、さらに現在が出店期間なら「出店 期間中」、出店1ヶ月前なら「出店準備期間中」というラベルを表示させる 「あと◦日」や「出店期間中」「出店準備期間中」の算出はFE/BEどっちがやる? タイムゾーンまたぐようなサービスだと、Backendで「あと◦日」の計算やりにく いけど大丈夫だっけ? 「出店準備期間は1ヶ月である」はビジネスロジックだしBackendに持たせたいよね? BEが算出する前提だと、GraphQL使ってるんだから画面の項目応じてTypeにfield増や してもいいよね?
じゃあ「出店期間中」「出店準備期間中」はenumにする?それぞれBooleanのfieldにす る?
あれこれ見てきて... と、ここまで見てきたように、比較的シンプルに思われるCRUDの作成でも結構悩みど ころは多い ここまでの「悩み」については、それぞれ明確に1つの答えが出るようなものでもな く、こういった観点でチームで議論していくのが大事だと思っている 振り返ってみるとこうやって言語化できても、チームで議論するための"叩き台"を作っ てるときや、作ってくれた"叩き台"をもとに議論しているときに、立ち止まれるかとい うと難しい もちろん、中には「GraphQLでなくても」「スキーマファーストでなくても」というも のはあるが、GraphQLという技術がスキーマファーストを実現できたおかげで、こんな
悩みどころに遭遇するタイミングが(良くも悪くも)早くなったのではないか
いまの自分のスタンス スキーマファーストで決めたスキーマも、「一度決めたスキーマでも、リリースまでに 変わる可能性がある」という共通認識をチームで持つのが大事そう ときにはスキーマファーストにこだわりすぎず、ある程度Backend実装を書いておくこ とで、"叩き台"の精度が上がるときもありそう GraphQLスキーマという、インターフェース境界について考えつつも、境界のみに思い を馳せることはできず、FE/BEそれぞれの事情をいったりきたりすることがスキーマ定 義をより良くしていく感覚がある チームの知見を持ち寄ることで"いったりきたり"しつつ、自身のスキルセットとし てももっといったりきたりできるようになっていきたい...!
ありがとうございました!!