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.7k
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
1.2k
About Rails ConnectionPool
highwide
0
190
How about today's coffee?
highwide
0
480
How to choose "best of the best"
highwide
1
730
A question about private method testing
highwide
0
3.4k
A life-changing innovation for my work-style by IoT
highwide
0
660
a-code-to-rhyme
highwide
3
640
よちがや.rb案内スライド
highwide
1
590
Other Decks in Programming
See All in Programming
Claude Codeの使い方
ttnyt8701
1
130
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
290
複数アプリケーションを育てていくための共通化戦略
irof
10
4k
関数型まつりレポート for JuliaTokai #22
antimon2
0
130
CursorはMCPを使った方が良いぞ
taigakono
0
150
Cursor AI Agentと伴走する アプリケーションの高速リプレイス
daisuketakeda
1
120
イベントストーミングから始めるドメイン駆動設計
jgeem
4
870
iOSアプリ開発で 関数型プログラミングを実現する The Composable Architectureの紹介
yimajo
2
210
社内での開発コミュニティ活動とモジュラーモノリス標準化事例のご紹介/xPalette and Introduction of Modular monolith standardization
m4maruyama
1
130
DroidKnights 2025 - 다양한 스크롤 뷰에서의 영상 재생
gaeun5744
3
300
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
240
Select API from Kotlin Coroutine
jmatsu
1
180
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Documentation Writing (for coders)
carmenintech
71
4.9k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.5k
Raft: Consensus for Rubyists
vanstee
140
7k
Automating Front-end Workflow
addyosmani
1370
200k
4 Signs Your Business is Dying
shpigford
184
22k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Building Adaptive Systems
keathley
43
2.6k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
For a Future-Friendly Web
brad_frost
179
9.8k
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それぞれの事情をいったりきたりすることがスキーマ定 義をより良くしていく感覚がある チームの知見を持ち寄ることで"いったりきたり"しつつ、自身のスキルセットとし てももっといったりきたりできるようになっていきたい...!
ありがとうございました!!