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
LayerX(バクラク)とGraphQL
Search
Matsumoto Toshi
February 08, 2024
1
800
LayerX(バクラク)とGraphQL
Matsumoto Toshi
February 08, 2024
Tweet
Share
More Decks by Matsumoto Toshi
See All by Matsumoto Toshi
20240511_TSKaigi 2024 スポンサーセッション LayerX 松本駿
toshi1127
2
1.1k
新規プロダクトで 爆速開発を実現するために意識したこと
toshi1127
0
1.6k
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
Agile that works and the tools we love
rasmusluckow
327
21k
Designing for Performance
lara
604
68k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Designing for humans not robots
tammielis
250
25k
A better future with KSS
kneath
238
17k
Faster Mobile Websites
deanohume
305
30k
Transcript
© 2024 LayerX Inc. LayerX(バクラク)とGraphQL 2024/02/08 LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは?運用実践LT @toshi1127
2 © 2024 LayerX Inc. 今日話すこと LayerX(バクラク)とGraphQL バクラクはおかげさまで3周年を迎えました。 その過程でのシステム構成の変遷 や
バクラクでなぜGraphQLを導入したのか 運用してみてのメリット/デメリットを発表します。
3 © 2024 LayerX Inc. 自己紹介 松本駿 2019年株式会社リクルート 新卒入社 不動産情報サイトSUUMOの新規機能開発やパフォーマンス改善、技術的負債の解消などを経験。
9ヶ月の副業を経て、 2022年2月株式会社LayerX 中途入社 バクラクビジネスカードとバクラク電子帳簿保存の バックエンドとフロントエンドを担当。 趣味 車 Github: toshi1127 Twitter: toshi11274
© 2024 LayerX Inc. 4 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 バクラク事業 企業活動のインフラとなる法人支出 管理(BSM)SaaSを開発・提供
Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン 事業紹介
5 © 2024 LayerX Inc. バクラクのビジネスドメイン
6 © 2024 LayerX Inc. 半年に1つプロダクトを投入しているコンパウンドスタートアップ
7 © 2024 LayerX Inc. バクラクのシステム構成の変遷 〜2021年3月 - BE(REST API) -
Go - go-swagger - FE ◦ TypeScript ◦ Vue2(Option API) ◦ Vuex3
8 © 2024 LayerX Inc. REST APIによるプロダクト開発で起きた問題 BE側の問題 - 1画面で必要な情報を1回で取得できないため、複数回の通信が必要
◦ アンダーフェッチ - バクラクではリレーションされたレスポンスを返すことでできるだけ解消 ◦ ユースケースによって使用しない不要なデータまで取得してしまう ▪ オーバーフェッチ ◦ REST APIの仕様, BEのロジックが、クライアントUIの都合に引きずられ見通しが悪い
9 © 2024 LayerX Inc. BEのコードの見通しの悪さ 一覧取得のAPIでは、リレーションされたレスポンスを返す実装が冗長 部署を持つユーザー情報の一覧を返す GET /usersのAPIがあった場合に
n+1を解決するために個別にQueryを書く必要がある https://tech.layerx.co.jp/entry/2021/04/12/121427
10 © 2024 LayerX Inc. REST APIによるプロダクト開発で起きた問題 FE側の問題 - 仕訳に必要なマスタ情報をVuexで状態管理(都度取得しなくて良いようにキャッシュしていた)
◦ リソースごとにテンプレート的な実装を多くしていた ▪ Loading, Error Handling ◦ (Vuexならではだけど) Vue側で型が当たらない問題や文字列のタイポで動かなくなる問題も ◦ 更新, 作成した結果を状態管理漏れ
11 © 2024 LayerX Inc. バクラクのシステム構成の変遷 〜2022年8月 プロダクトごとのGraphQL APIとFEが通信する構成 -
BE(GraphQL API) - Go - gqlgen - FE ◦ TypeScript ◦ Vue2 or React
12 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて REST APIによるプロダクト開発で起きた問題は解消された - アンダーフェッチ,
オーバーフェッチ問題→画面に必要なデータは過不足なく一度で取得可能 - リレーションされたレスポンスを返すためのコードがシンプルに - Model Resolverでリレーションされたデータの解決を容易にできる
13 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて REST APIによるプロダクト開発で起きた問題は解消された - Apolloを採用しFetchしたデータ管理が目的をしていたVuex不要になり、コードがシンプルに
- swr, TanStack Query, RTK Queryでも似たメリットは享受できる
14 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて 加えて採用してよかったこと(BEに関して) - 再利用性が高くて生産性が良い、同じModelへのリレーションを解決したくなった時の実装がほぼない -
DocumentというModelの担当部署(Group)を取得する処理を追加したくなった場合の例 - 特定のFieldの解決にコストがかかる場合、FieldResolverとして処理を分けることで要求された時のみ処理される様にできる - Presigned URLを返す処理など
15 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて 加えて採用してよかったこと - スキーマ定義がシンプルで考えることが少ない -
HTTP リクエストメソッド / ステータスコードがあるわけではない - GraphQL Inspectorで後方互換性の確認ができ安全にリリースしやすい - 逆に検知できないとschemaのvalidationエラーになってしまうので検知する仕組みはおすすめ - (従来の開発から継続してだけど)スキーマ駆動開発でチーム開発する際に背中を預けやすい - レビュー工程を設計段階で行えるので大きな手戻りが起きにくい - スキーマから生成されたコードに実装を加えていくので設計から齟齬が起きない
16 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて 工夫必要だった点 - パフォーマンスモニタリングやトラブルシュートしやすい様にするためには一工夫必要 -
RESTの時のものを横展開はできず、別途自分たちで実装する必要がある - 同じエンドポイントにPOSTリクエストが来るので、単純にレスポンスタイムを集計できない - GraphQLのクエリ情報(クエリ名やパラメータなど)が取得できない
17 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて プロダクトごとにGraphQL APIを提供することで起きた問題 - 前提
- 半年に1つプロダクトを投入しているコンパウンドスタートアップ - 連携そのものがプロダクトであり、競合優位性を作っていくことになる - プロダクトをまたいであらゆるリソースにアクセスする必要がある - このままそれぞれのプロダクトのGraphQL APIエンドポイントとフロントエンドが通信する場合 - ちょっとずつ形の異なる GraphQL スキーマがプロダクトの数だけ存在することによる、認知負荷 の増大リスク - フロントが複数のプロダクトのエンドポイントを叩いてるケースも
18 © 2024 LayerX Inc. 現在はEnablingチームによるLayeroneプロジェクトが発足 - Enablingチーム - プロダクト開発チームとの協業を通じて、新たな障害や課題を仕組み化を伴って解決するチーム
- https://tech.layerx.co.jp/entry/2023/12/19/104004 - Layeroneプロジェクトが発足
19 © 2024 LayerX Inc. Layeroneの目的 layerone目指す状態
20 © 2024 LayerX Inc. API Gateway Patternを採用 GraphQLでGatewayを実装 -
フロントエンド(Webapp, Mobile)が参照する エントリーポイント を統合し、すべてのリソースにアクセ スするアーキテクチャに - GraphQLを採用 - リソース解決が非常に容易である - 多様なフロントエンド(Webapp, Mobile)から、様々なコンテキストでアクセスが来る - リソースのオーナを各microserviceにできる
21 © 2024 LayerX Inc. まとめ - GraphQLを導入することで ◦ アンダーフェッチ,
オーバーフェッチ問題が解消 ◦ リレーションされたレスポンスを返すためのコードがシンプルに - コンパウンドスタートアップなので、連携そのものがプロダクトであり、プロダクトをまたいであらゆるリ ソースにアクセスしやすくするために - リリース3年の中で日々アーキテクチャが進化している - その時々に応じて変化できているのは、羅針盤に示されていることが浸透しているからだなと感じた (Bet Tecnhologyや型に投資する、No じゃなきゃ Go といった部分)
22 © 2024 LayerX Inc. We're hiring 一緒に挑戦する仲間を募集中です! - 採用ページ
- https://jobs.layerx.co.jp/ - カジュアル面談 - https://open.talentio.com/r/1/c/layerx/pages/68950