Upgrade to Pro — share decks privately, control downloads, hide ads and more …

LayerX(バクラク)とGraphQL

Matsumoto Toshi
February 08, 2024
830

 LayerX(バクラク)とGraphQL

Matsumoto Toshi

February 08, 2024
Tweet

Transcript

  1. 2 © 2024 LayerX Inc. 今日話すこと LayerX(バクラク)とGraphQL バクラクはおかげさまで3周年を迎えました。 その過程でのシステム構成の変遷 や

    バクラクでなぜGraphQLを導入したのか 運用してみてのメリット/デメリットを発表します。
  2. 3 © 2024 LayerX Inc. 自己紹介 松本駿 2019年株式会社リクルート 新卒入社 不動産情報サイトSUUMOの新規機能開発やパフォーマンス改善、技術的負債の解消などを経験。

    9ヶ月の副業を経て、 2022年2月株式会社LayerX 中途入社 バクラクビジネスカードとバクラク電子帳簿保存の バックエンドとフロントエンドを担当。 趣味 車 Github: toshi1127 Twitter: toshi11274
  3. 8 © 2024 LayerX Inc. REST APIによるプロダクト開発で起きた問題 BE側の問題 - 1画面で必要な情報を1回で取得できないため、複数回の通信が必要

    ◦ アンダーフェッチ - バクラクではリレーションされたレスポンスを返すことでできるだけ解消 ◦ ユースケースによって使用しない不要なデータまで取得してしまう ▪ オーバーフェッチ ◦ REST APIの仕様, BEのロジックが、クライアントUIの都合に引きずられ見通しが悪い
  4. 10 © 2024 LayerX Inc. REST APIによるプロダクト開発で起きた問題 FE側の問題 - 仕訳に必要なマスタ情報をVuexで状態管理(都度取得しなくて良いようにキャッシュしていた)

    ◦ リソースごとにテンプレート的な実装を多くしていた ▪ Loading, Error Handling ◦ (Vuexならではだけど) Vue側で型が当たらない問題や文字列のタイポで動かなくなる問題も ◦ 更新, 作成した結果を状態管理漏れ
  5. 12 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて REST APIによるプロダクト開発で起きた問題は解消された - アンダーフェッチ,

    オーバーフェッチ問題→画面に必要なデータは過不足なく一度で取得可能 - リレーションされたレスポンスを返すためのコードがシンプルに - Model Resolverでリレーションされたデータの解決を容易にできる
  6. 14 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて 加えて採用してよかったこと(BEに関して) - 再利用性が高くて生産性が良い、同じModelへのリレーションを解決したくなった時の実装がほぼない -

    DocumentというModelの担当部署(Group)を取得する処理を追加したくなった場合の例 - 特定のFieldの解決にコストがかかる場合、FieldResolverとして処理を分けることで要求された時のみ処理される様にできる - Presigned URLを返す処理など
  7. 15 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて 加えて採用してよかったこと - スキーマ定義がシンプルで考えることが少ない -

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

    RESTの時のものを横展開はできず、別途自分たちで実装する必要がある - 同じエンドポイントにPOSTリクエストが来るので、単純にレスポンスタイムを集計できない - GraphQLのクエリ情報(クエリ名やパラメータなど)が取得できない
  9. 17 © 2024 LayerX Inc. プロダクトごとにGraphQLを使用してみて プロダクトごとにGraphQL APIを提供することで起きた問題 - 前提

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

    フロントエンド(Webapp, Mobile)が参照する エントリーポイント を統合し、すべてのリソースにアクセ スするアーキテクチャに - GraphQLを採用 - リソース解決が非常に容易である - 多様なフロントエンド(Webapp, Mobile)から、様々なコンテキストでアクセスが来る - リソースのオーナを各microserviceにできる
  11. 21 © 2024 LayerX Inc. まとめ - GraphQLを導入することで ◦ アンダーフェッチ,

    オーバーフェッチ問題が解消 ◦ リレーションされたレスポンスを返すためのコードがシンプルに - コンパウンドスタートアップなので、連携そのものがプロダクトであり、プロダクトをまたいであらゆるリ ソースにアクセスしやすくするために - リリース3年の中で日々アーキテクチャが進化している - その時々に応じて変化できているのは、羅針盤に示されていることが浸透しているからだなと感じた (Bet Tecnhologyや型に投資する、No じゃなきゃ Go といった部分)
  12. 22 © 2024 LayerX Inc. We're hiring 一緒に挑戦する仲間を募集中です! - 採用ページ

    - https://jobs.layerx.co.jp/ - カジュアル面談 - https://open.talentio.com/r/1/c/layerx/pages/68950