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
1.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
620
よちがや.rb案内スライド
highwide
1
570
Other Decks in Programming
See All in Programming
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
520
Pulsar2 を雰囲気で使ってみよう
anoken
0
240
CI改善もDatadogとともに
taumu
0
170
Honoをフロントエンドで使う 3つのやり方
yusukebe
7
3.4k
Domain-Driven Transformation
hschwentner
2
1.9k
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
130
Unity Android XR入門
sakutama_11
0
170
Serverless Rust: Your Low-Risk Entry Point to Rust in Production (and the benefits are huge)
lmammino
1
140
第3回 Snowflake 中部ユーザ会- dbt × Snowflake ハンズオン
hoto17296
4
380
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
210
Amazon S3 TablesとAmazon S3 Metadataを触ってみた / 20250201-jawsug-tochigi-s3tables-s3metadata
kasacchiful
0
180
Software Architecture
hschwentner
6
2.1k
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.2k
Agile that works and the tools we love
rasmusluckow
328
21k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Code Reviewing Like a Champion
maltzj
521
39k
Side Projects
sachag
452
42k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
A better future with KSS
kneath
238
17k
We Have a Design System, Now What?
morganepeng
51
7.4k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
350
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
980
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それぞれの事情をいったりきたりすることがスキーマ定 義をより良くしていく感覚がある チームの知見を持ち寄ることで"いったりきたり"しつつ、自身のスキルセットとし てももっといったりきたりできるようになっていきたい...!
ありがとうございました!!