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 schema design
Search
Takahiro Uchiyama
August 31, 2022
Programming
0
1.1k
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
22
14k
停止性問題と数 / Halting problem and number
highwide
0
740
About Rails ConnectionPool
highwide
0
150
How about today's coffee?
highwide
0
450
How to choose "best of the best"
highwide
1
560
A question about private method testing
highwide
0
2.8k
A life-changing innovation for my work-style by IoT
highwide
0
620
a-code-to-rhyme
highwide
3
530
よちがや.rb案内スライド
highwide
1
560
Other Decks in Programming
See All in Programming
dbtのドメイン分割による データ基盤の改善とDigdagとの連携
sakama
0
280
PostmanでAPIの動作確認が楽になった話
h455h1
0
170
⼤規模⾔語モデルの拡張(RAG)が 終わったかも知れない件について
nearme_tech
23
15k
Prepare for Jakarta EE 11 - Performance and Developer Productivity
ivargrimstad
0
770
ADRを一年運用してみた/adr_after_a_year
hanhan1978
7
2.4k
Fragment Composition of GraphQL
quramy
6
950
SwiftUIで使いやすいToastの作り方 / How to build a Toast system which is easy to use in SwiftUI
lovee
3
140
TYPO3 v13 – The road to LTS: What's new and new APIs
luisasofie_xoxo
0
200
検証も兼ねて個人開発でHonoとかと向き合った話
hanetsuki
1
900
Let's learn code review
riofujimon
1
220
R言語の環境構築と基礎 Tokyo.R 112
bob3bob3
0
270
使ってみよう Azure AI Document Intelligence
kosmosebi
2
310
Featured
See All Featured
Practical Orchestrator
shlominoach
182
9.7k
GraphQLとの向き合い方2022年版
quramy
32
12k
Teambox: Starting and Learning
jrom
128
8.4k
BBQ
matthewcrist
80
8.8k
Testing 201, or: Great Expectations
jmmastey
28
6.4k
Building Your Own Lightsaber
phodgson
99
5.7k
Gamification - CAS2011
davidbonilla
76
4.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
357
22k
Code Review Best Practice
trishagee
55
15k
Become a Pro
speakerdeck
PRO
11
4.5k
The Brand Is Dead. Long Live the Brand.
mthomps
49
28k
Raft: Consensus for Rubyists
vanstee
132
6.3k
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それぞれの事情をいったりきたりすることがスキーマ定 義をより良くしていく感覚がある チームの知見を持ち寄ることで"いったりきたり"しつつ、自身のスキルセットとし てももっといったりきたりできるようになっていきたい...!
ありがとうございました!!