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.6k
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.1k
About Rails ConnectionPool
highwide
0
190
How about today's coffee?
highwide
0
470
How to choose "best of the best"
highwide
1
720
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
580
Other Decks in Programming
See All in Programming
"使いづらい" をリバースエンジニアリングする UI の読み解き方
rebase_engineering
0
110
當開發遇上包裝:AI 如何讓產品從想法變成商品
clonn
0
2.6k
JVM の仕組みを理解して PHP で実装してみよう
m3m0r7
PRO
1
250
ワンバイナリWebサービスのススメ
mackee
10
7.5k
バランスを見極めよう!実装の意味を明示するための型定義 TSKaigi 2025 Day2 (5/24)
whatasoda
2
780
がんばりすぎないコーディングルール運用術
tsukakei
1
190
CRUD から CQRS へ ~ 分離が可能にする柔軟性
tkawae
0
230
Efficiency and Rock 'n’ Roll (Really!)
hollycummins
0
600
人には人それぞれのサービス層がある
shimabox
3
470
RubyKaigi Hack Space in Tokyo & 函館最速 "予習" 会 / RubyKaigi Hack Space in Tokyo & The Fastest Briefing of RubyKaigi 2026 in Hakodate
moznion
1
130
DevTalks 25 - Create your own AI-infused Java apps with ease
kdubois
2
130
UPDATEがシステムを複雑にする? イミュータブルデータモデルのすすめ
shimomura
0
260
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
94
13k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
15
890
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Fontdeck: Realign not Redesign
paulrobertlloyd
84
5.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
42
2.3k
Practical Orchestrator
shlominoach
188
11k
Writing Fast Ruby
sferik
628
61k
We Have a Design System, Now What?
morganepeng
52
7.6k
Designing for Performance
lara
608
69k
The Power of CSS Pseudo Elements
geoffreycrofte
76
5.8k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
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それぞれの事情をいったりきたりすることがスキーマ定 義をより良くしていく感覚がある チームの知見を持ち寄ることで"いったりきたり"しつつ、自身のスキルセットとし てももっといったりきたりできるようになっていきたい...!
ありがとうございました!!