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を採用するなら
Search
KazukiHayase
January 31, 2025
Technology
2
420
もし今からGraphQLを採用するなら
KazukiHayase
January 31, 2025
Tweet
Share
More Decks by KazukiHayase
See All by KazukiHayase
Goでテストをしやすくするためにやったこと
kazukihayase
1
750
GraphQLクライアントの技術選定 2023冬
kazukihayase
9
6.4k
Introduction and Insights of the Hasura-based Architecture
kazukihayase
0
860
自分だけが頑張るのをやめて、フルスタックなチームを作る
kazukihayase
2
2.5k
Goでテンプレートからファイルを自動生成するCLIを作る
kazukihayase
0
1.2k
生産性が上がり続けるチームを作るための第一歩
kazukihayase
4
3.7k
GraphQLにおけるクライアントキャッシュ戦略
kazukihayase
0
2.8k
MUIをベースにしたデザインシステムの構築
kazukihayase
0
500
Hasuraを活用するためのTips集
kazukihayase
0
33k
Other Decks in Technology
See All in Technology
ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making
snoozer05
PRO
17
3.4k
LambdaとSQLiteでシステム構築
ogadra
1
140
ココナラのセキュリティ組織の体制・役割・今後目指す世界
coconala_engineer
0
200
Agentic AI時代のプロダクトマネジメントことはじめ〜仮説検証編〜
masakazu178
0
270
Autify Company Deck
autifyhq
2
41k
実践!生成AIのビジネス活用 / How to utilize Generative AI in your own business
gakumura
1
200
20250122_個人向けCopilotどうなん
ponponmikankan
0
200
HCP Terraformで実現するPlatform Engineering/nikkei-tech-talk-29
nikkei_engineer_recruiting
0
210
製造業とソフトウェアは本当に共存できていたのか?品質とスピードを問い直す
takabow
14
4.6k
教師なし学習の基礎
kanojikajino
3
320
【Λ(らむだ)】アップデート機能振り返りΛ編 / PADjp20250127
lambda
0
110
あなたの興味は信頼性?それとも生産性? SREとしてのキャリアに悩むみなさまに伝えたい選択肢
jacopen
5
2.3k
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Being A Developer After 40
akosma
89
590k
Side Projects
sachag
452
42k
Raft: Consensus for Rubyists
vanstee
137
6.7k
Producing Creativity
orderedlist
PRO
343
39k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
3k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
Become a Pro
speakerdeck
PRO
26
5.1k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Transcript
もし今からGraphQLを採用するなら BuriKaigi 2025 2025. 02. 01
3 自己紹介 早瀬和輝(@KazukiHayase) • 2021年BuySell Technologies入社 • 開発2部 販売グループ EXSチーム
• PjM / テックリード • Go / TypeScript / React / GraphQL • 酒 / ポケカ(ポケポケ) / アニメ / 映画 • 大学が金沢なので、富山にはよく来ていた
4 本セッションについて • GraphQLと周辺技術における技術選定の実例 • 上記を踏まえた上で、今ならどのような構成にするか 話すこと • GraphQL自体の紹介 •
GraphQL関連以外の技術選定の詳細 話さないこと
5 本セッションについて GraphQLの選定の実例を通じて、 今後GraphQLを採用する際の参考にして欲しい
01 02 03 04 05 目次 Index プロダクト特性と全体構成 GraphQL採用の振り返り 周辺ライブラリの技術選定の振り返り
もし今ならどのような構成にするか まとめ
プロダクト特性と全体構成 01
事業紹介 買取・販売の循環を実現する総合リユースビジネスを展開しています。 お客様のニーズに合わせた各種買取・販売チャネルで、自宅に眠るさまざまな不要なものを、誰かの必要なものへと変えています。
プロダクト群「バイセルリユースプラットフォーム Cosmos」の開発が進行中 リユースに必要なすべての機能を提供する「リユースプラットフォーム Cosmos」の開発が進行中です。 Cosmosを活用して、バイセルグループ全体での業務効率改善やデータドリブン経営の深化を目指しています。 リユースプラットフォームCosmos 自社開発のリユース特化業務基幹システムでありサービス群の集合体 買取申込 買取・査定 在庫管理
販売 多様なチャネルで収益最大化 CRM -顧客対応- 買取種別に応じた最適なシステム構築 Visit -訪問買取- Store -店舗買取- Promas -商材マスタ- Appraisal -専門査定- Stock -在庫管理- EXS -販売管理- Core -会員管理- Portal -データ利用- Pocket -データ基盤- 買取 専門チームによる真贋・査定と連携 査定 申込 効率的な顧客対応 在庫 在庫管理の最適・効率化 販売 データ 各事業プロセスにある データを一元管理 :基幹システム
10 EXSについて EXSとは複数のECサイトへの出品・受注業務を一元管理するWebアプリ 各ECサイトの仕様差異を吸収することで、ユーザーの業務をEXSのみで完結させる
11 プロダクト特性 • BtoBシステムで、認証されたユーザーのみが利用 • 外部サービスとの連携が非常に多く、それらを非同期で処理する • 一括出品・受注処理が主な機能で、検索機能と一括操作が重要 • 主にPCで利用され、将来的にはモバイルにも対応予定
12 チーム体制 • エンジニアは5〜10名 ◦ 比較的ジュニアメンバーが多い • スクラムを採用 • 開発領域は分割していないが、状況によって分割することもある
13 技術スタック インフラ Google Cloud、PostgreSQL、 Cloud Run、Elasticsearch バックエンド Hasura、Go、gqlgen、GORM フロントエンド
React(Next.js)、TypeScript、 Apollo Client、GraphQL Code Generator
14 全体構成図
15 全体構成図 • Hasuraは簡単なCRUDを担当 • 同期コンテナはHasuraでは行えない複雑な処理を担当 • Hasura↔同期コンテナはRemote Schemaという機能で連携 フロントエンド↔バックエンドの通信はGraphQL
16 全体構成図 • 非同期コンテナへはCloud Tasks経由でリクエスト • 外部サービスとの連携は非同期コンテナで実行 同期コンテナ↔非同期コンテナの通信はREST
GraphQL採用の振り返り 02
18 GraphQLを採用してみて 総合的に判断してGraphQLを採用して良かった • データフェッチの柔軟性 • 型安全性 • 契約としてのスキーマファースト •
Fragment ColocationによるUXとDXの両立 GraphQLの代表的なメリットを享受できている
19 GraphQLのデメリットについて GraphQLの代表的なデメリット • Queryの自由度の高さ ◦ 高負荷なリクエストを簡単に実行できる • スキーマ設計の難しさ •
学習コストの高さ
20 Queryの自由度の高さ レビューとLinterの2軸で危険なQueryの実行を防止 レビュー スキーマ定義とQueryの両方を テックリード2人が必ずレビューを行う Linter graphql-eslintで Queryのネストなどを自動的に制限
21 Queryの自由度の高さ リファインメントの時点で、スキーマやQueryの定義はチケットを分解している
22 スキーマ設計の難しさ プロダクトの特性もあり、スキーマはそこまで肥大化していない モール連携などのコアロジックは非同期コンテナで実装されており、 プロダクト全体の規模に対して、必要なGraphQL APIの数は多くない
23 スキーマ設計の難しさ 連携先を追加する場合も、引数の追加のみでGraphQLスキーマの変更は不要
24 スキーマ設計の難しさ ドメイン的に商品と注文という大きな2つのオブジェクトがあり、 基本的にそれらにフィールドが追加されていく そのため、グラフ構造の複雑化よりも、オブジェクト単体の肥大化が進みやすく オブジェクトが肥大化する方が考慮するべき点が少ない スキーマの拡張の特性も設計の難易度に影響する
25 学習コストの高さ 学習コストは非常に高い 使いこなすには一定の学習期間が必要で、それを許容できる体制が必要 特にGraphQL未経験でHasuraを使用する場合は、 GraphQLとHasuraの境界が曖昧になり、混合しやすくなるので注意
26 学習コストの高さ GraphQLでより恩恵を受けるのはフロントエンドのため、 深く理解し活用を推進するフロントエンドエンジニアがチームに1人は必要 そうでなければ、総合的に見た時にデメリットの方が目立ってしまう フロントエンド の メリット バックエンド の
メリット
27 GraphQLを採用する際に考慮すると良いこと • チームにGraphQLを深く理解しているフロントエンドエンジニアがいるか • プロダクトの特性上、グラフ構造の方が肥大化しやすいか ◦ その場合は設計難易度が上がりやすい • そのチーム・プロダクトにおいて、デメリットを許容できるか
◦ 必ず想定外の事態は発生するので、それに向き合い続ける覚悟も必要 • キャッチアップ期間を確保できるか ◦ 開発初期だけでなく、その後加入するメンバーに対しても
周辺ライブラリの技術選定の振り返り 03
29 周辺技術の振り返り マッチしたもの • gqlgen • GraphQL Code Generator •
graphql-eslint マッチしなかったもの • Hasura • Apollo Client 採用した周辺技術に関して、マッチしたものとマッチしなかったものに分けて紹介
30 周辺技術の振り返り マッチしたもの • gqlgen • GraphQL Code Generator •
graphql-eslint
31 マッチしたもの - gqlgen • GoでGraphQLサーバーを構築するためのライブラリ • GraphQLスキーマから、構造体やリゾルバを自動生成してくれる gqlgenとは •
スキーマファーストで開発できる • GraphQL関連の機能が豊富 採用理由
32 マッチしたもの - gqlgen • 当初の目的のスキーマファーストを実現できている ◦ 一番最初にスキーマ設計の認識を合わせることができる ◦ フロー効率が上がる
• カスタムスカラーやカスタムディレクティブの追加も簡単 ◦ 検索した際の情報量も多い • 現状のユースケースの範囲では、特に大きな不満はない マッチした点
33 マッチしたもの - GraphQL Code Generator • GraphQLスキーマやQueryから、様々なコードを自動生成するツール • 主にTypeScriptの型定義や関連コードの生成に使用
GraphQL Code Generatorとは • スキーマファーストで開発できる • プラグインが豊富 採用理由
34 マッチしたもの - GraphQL Code Generator • スキーマファーストに関してはgqlgenに同じ • TypedDocumentNodeによる型推論の使い勝手が良い
• fragment-maskingにより、Fragment Colocationを強制できる マッチした点
35 マッチしたもの - graphql-eslint • The Guildによって公開されているESLintのプラグイン • GraphQLのスキーマやオペレーションに対してLintを実行できる graphql-eslintとは
• GraphQLに関するルールを自動で検証できる 採用理由
36 マッチしたもの - graphql-eslint • GraphQLに関するベストプラクティスなどを強制できる • カスタムルールの作成が簡単 マッチした点
37 周辺技術の振り返り マッチしなかったもの • Hasura • Apollo Client
38 マッチしなかったもの - Hasura • データベースのスキーマから、GraphQL APIを自動で構築してくれるOSS • 外部のGraphQL APIを統合するRemote
Schemaという機能もある Hasuraとは • APIの自動生成による開発速度の向上 • GUIで簡単に認可制御できる 採用理由
39 • テーブル構造がそのままGraphQLスキーマになる • 想定よりもHasuraの利用頻度が少なかった マッチしなかった点 マッチしなかったもの - Hasura 想定よりも開発速度が上がらなかった
😢
40 マッチしなかったもの - Hasura テーブル構造がそのままGraphQLスキーマになる
41 マッチしなかったもの - Hasura • Queryを定義するのに、テーブル構造の理解が必要 ◦ ピュアなフロントエンドエンジニアには難しい • 欲しい形式で取得できず、フロントエンドで整形処理が肥大化
◦ フロントエンドの実装コスト増 • テーブル設計がフロントエンド実装のブロッカーになる ◦ スキーマファーストではなくなり、GraphQLのメリットが薄れる テーブル構造がそのままGraphQLスキーマになる
42 マッチしなかったもの - Hasura • 発行されるSQLが複雑で、Queryに対応するSQLを変更することはできない ◦ 特にAggregation Queriesという、集計用のQueryが重い •
Hasuraのみで解決が難しく、同期コンテナで実装する場面が増加 想定よりもHasuraの利用頻度が少なかった
43 • Queryの定義にテーブル構造の理解が必要 • フロントエンドでのロジックが肥大化しやすい • パフォーマンスチューニングの方法が限られる ◦ e.g. インデックス追加、Query変更、インフラのスペックアップ
◦ 上記で解決できない場合は、Remote Schema等の外部実装が必要 • 大規模になると上記の問題が発生したり、設定の管理が大変になる ◦ 小〜中規模のプロダクトやPoCにはおすすめできる Hasuraを採用する際の注意点 マッチしなかったもの - Hasura
44 マッチしなかったもの - Apollo Client • GraphQLオペレーションの実行するためのGraphQLクライアント • キャッシュと状態管理に対応した包括的な状態管理ライブラリ Apollo
Clientとは • メジャーなライブラリなので情報量が多い • 学習コストが低く導入しやすい 採用理由
45 • キャッシュの必要性が低かった • 機能が豊富な反面、それに伴う課題も発生した マッチしなかった点 マッチしなかったもの - Apollo Client
要件に対してオーバースペックだった 😢
46 マッチしなかったもの - Apollo Client • 最新のデータを表示する重要性が高く、キャッシュを利用しないことが多い ◦ e.g. 検索機能、複数箇所から更新されるデータ
キャッシュの必要性が低かった
47 マッチしなかったもの - Apollo Client • キャッシュが必要な場合でも、正規化されていて欲しい場面はあまりなかった ◦ Query単位でキャッシュできていれば十分 ◦
正規化されているとキャッシュの部分更新など考慮事項が増える キャッシュの必要性が低かった
48 マッチしなかったもの - Apollo Client • 他のGraphQLクライアントと比べて開発が遅い ◦ e.g. Suspense、useFragment
• 暗黙的な挙動の把握が大変 機能が豊富な反面、それに伴う課題も発生した https://github.com/apollographql/apollo-client/issues/11151#issuecomment-1730186108
49 Apollo Clientを採用する際の注意点 • 多機能な状態管理ライブラリということを念頭におく ◦ 要件に対してtoo matchなケースは少なくない • 要件から必要な機能を逆算する
◦ Apollo Clientしか対応していない機能はそこまで多くない ◦ 最低限の機能しか使わないのであれば、他の軽量なライブラリで良い • 正規化されたキャッシュが必要かを考える ◦ 検索機能が重要な場合や、複数箇所からデータが更新される場合は扱いづらい マッチしなかったもの - Apollo Client
もし今ならどのような構成にするか 04
51 もし今ならどのような構成にするか 振り返りを基にマッチしたものそのまま採用、マッチしなかったものを変更する マッチしたもの • gqlgen • GraphQL Code Generator
• graphql-eslint マッチしなかったもの • Hasura • Apollo Client
52 もし今ならどのような構成にするか Before After Hasrua 不採用 Apollo Client urql
53 もし今ならどのような構成にするか
54 • 振り返りで話した通り、プロダクトの特性的に開発速度がそこまで出なかった • 総合的に見た時に得られるメリットよりも、運用コストの方が高くつく • 全てgqlgenで実装する方がスキーマファースト開発でき、管理しやすい Hasuraを不採用にする理由 もし今ならどのような構成にするか
55 • 現在Apollo Clientで使っている機能は備わっている • Graphcacheという正規化されたキャッシュを使うことも可能 • 正規化されたキャッシュは不要なのでRelayは候補外 urqlを採用にする理由 もし今ならどのような構成にするか
まとめ 05
57 まとめ • GraphQLはプロダクト特性やチーム体制などを総合的に判断して採用する • HasuraやApollo Clientを採用する際は今回紹介した注意が必要 • 要件を満たせるかだけでなく、過不足ない技術選定が重要 ◦
大は小を兼ねるが、運用コストは高くつく
THANK YOU