LayerX(バクラク)とGraphQL

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

3 © 2024 LayerX Inc. 自己紹介松本駿 2019年株式会社リクルート新卒入社不動産情報サイトSUUMOの新規機能開発やパフォーマンス改善、技術的負債の解消などを経験。 9ヶ月の副業を経て、 2022年2月株式会社LayerX 中途入社バクラクビジネスカードとバクラク電子帳簿保存のバックエンドとフロントエンドを担当。趣味車 Github: toshi1127 Twitter: toshi11274

Slide 4

Slide 4 text

© 2024 LayerX Inc. 4 「すべての経済活動を、デジタル化する。」をミッションに掲げ、法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。バクラク事業企業活動のインフラとなる法人支出管理（BSM）SaaSを開発・提供 Fintech事業ソフトウェアを駆使したアセットマネジメント・証券事業を合弁会社にて展開 AI・LLM事業文書処理を中心とした、LLMの活用によるプロセスのリデザイン事業紹介

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 © 2024 LayerX Inc. REST APIによるプロダクト開発で起きた問題 BE側の問題 - 1画面で必要な情報を1回で取得できないため、複数回の通信が必要 ○ アンダーフェッチ - バクラクではリレーションされたレスポンスを返すことでできるだけ解消 ○ ユースケースによって使用しない不要なデータまで取得してしまう ■ オーバーフェッチ ○ REST APIの仕様, BEのロジックが、クライアントUIの都合に引きずられ見通しが悪い

Slide 9

Slide 9 text

Slide 10

Slide 10 text

10 © 2024 LayerX Inc. REST APIによるプロダクト開発で起きた問題 FE側の問題 - 仕訳に必要なマスタ情報をVuexで状態管理（都度取得しなくて良いようにキャッシュしていた） ○ リソースごとにテンプレート的な実装を多くしていた ■ Loading, Error Handling ○ (Vuexならではだけど) Vue側で型が当たらない問題や文字列のタイポで動かなくなる問題も ○ 更新, 作成した結果を状態管理漏れ

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

14 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて加えて採用してよかったこと（BEに関して） - 再利用性が高くて生産性が良い、同じModelへのリレーションを解決したくなった時の実装がほぼない - DocumentというModelの担当部署（Group）を取得する処理を追加したくなった場合の例 - 特定のFieldの解決にコストがかかる場合、FieldResolverとして処理を分けることで要求された時のみ処理される様にできる - Presigned URLを返す処理など

Slide 15

Slide 15 text

15 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて加えて採用してよかったこと - スキーマ定義がシンプルで考えることが少ない - HTTP リクエストメソッド / ステータスコードがあるわけではない - GraphQL Inspectorで後方互換性の確認ができ安全にリリースしやすい - 逆に検知できないとschemaのvalidationエラーになってしまうので検知する仕組みはおすすめ - （従来の開発から継続してだけど）スキーマ駆動開発でチーム開発する際に背中を預けやすい - レビュー工程を設計段階で行えるので大きな手戻りが起きにくい - スキーマから生成されたコードに実装を加えていくので設計から齟齬が起きない

Slide 16

Slide 16 text

16 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて工夫必要だった点 - パフォーマンスモニタリングやトラブルシュートしやすい様にするためには一工夫必要 - RESTの時のものを横展開はできず、別途自分たちで実装する必要がある - 同じエンドポイントにPOSTリクエストが来るので、単純にレスポンスタイムを集計できない - GraphQLのクエリ情報(クエリ名やパラメータなど)が取得できない

Slide 17

Slide 17 text

17 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみてプロダクトごとにGraphQL APIを提供することで起きた問題 - 前提 - 半年に1つプロダクトを投入しているコンパウンドスタートアップ - 連携そのものがプロダクトであり、競合優位性を作っていくことになる - プロダクトをまたいであらゆるリソースにアクセスする必要がある - このままそれぞれのプロダクトのGraphQL APIエンドポイントとフロントエンドが通信する場合 - ちょっとずつ形の異なる GraphQL スキーマがプロダクトの数だけ存在することによる、認知負荷の増大リスク - フロントが複数のプロダクトのエンドポイントを叩いてるケースも

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

20 © 2024 LayerX Inc. API Gateway Patternを採用 GraphQLでGatewayを実装 - フロントエンド（Webapp, Mobile）が参照するエントリーポイント　を統合し、すべてのリソースにアクセスするアーキテクチャに - GraphQLを採用 - リソース解決が非常に容易である - 多様なフロントエンド（Webapp, Mobile）から、様々なコンテキストでアクセスが来る - リソースのオーナを各microserviceにできる

Slide 21

Slide 21 text

21 © 2024 LayerX Inc. まとめ - GraphQLを導入することで ○ アンダーフェッチ, オーバーフェッチ問題が解消 ○ リレーションされたレスポンスを返すためのコードがシンプルに - コンパウンドスタートアップなので、連携そのものがプロダクトであり、プロダクトをまたいであらゆるリソースにアクセスしやすくするために - リリース3年の中で日々アーキテクチャが進化している - その時々に応じて変化できているのは、羅針盤に示されていることが浸透しているからだなと感じた（Bet Tecnhologyや型に投資する、No じゃなきゃ Go といった部分）

Slide 22

Slide 22 text