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
BFFとmicroservicesアーキテクチャ
Search
hirac
May 19, 2022
Technology
1
720
BFFとmicroservicesアーキテクチャ
hirac
May 19, 2022
Tweet
Share
More Decks by hirac
See All by hirac
クラウドサービスベンダーのセキュリティチェックシート対応
hirac1220
0
280
スタートアップのエンジニア採用広報.pdf
hirac1220
1
320
CTOとしてプロダクト価値を上げるために実施したこと
hirac1220
1
250
フルリモート環境でのスクラム開発
hirac1220
1
510
開発リーダーとしてやったことリスト
hirac1220
0
1.6k
Other Decks in Technology
See All in Technology
Yamla: Rustでつくるリアルタイム性を追求した機械学習基盤 / Yamla: A Rust-Based Machine Learning Platform Pursuing Real-Time Capabilities
lycorptech_jp
PRO
4
180
Claude Code Actionを使ったコード品質改善の取り組み
potix2
PRO
6
2.6k
AIとともに進化するエンジニアリング / Engineering-Evolving-with-AI_final.pdf
lycorptech_jp
PRO
0
140
KubeCon + CloudNativeCon Japan 2025 に行ってきた! & containerd の新機能紹介
honahuku
0
120
CI/CD/IaC 久々に0から環境を作ったらこうなりました
kaz29
1
200
Connect 100+を支える技術
kanyamaguc
0
150
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
1.4k
製造業からパッケージ製品まで、あらゆる領域をカバー!生成AIを利用したテストシナリオ生成 / 20250627 Suguru Ishii
shift_evolve
PRO
1
160
KubeCon + CloudNativeCon Japan 2025 Recap
ren510dev
1
300
How Community Opened Global Doors
hiroramos4
PRO
1
130
GeminiとNotebookLMによる金融実務の業務革新
abenben
0
250
Github Copilot エージェントモードで試してみた
ochtum
0
140
Featured
See All Featured
Building Adaptive Systems
keathley
43
2.6k
Become a Pro
speakerdeck
PRO
28
5.4k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Building Applications with DynamoDB
mza
95
6.5k
Facilitating Awesome Meetings
lara
54
6.4k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Agile that works and the tools we love
rasmusluckow
329
21k
Docker and Python
trallard
44
3.5k
Scaling GitHub
holman
459
140k
Transcript
hirac CTO@sweeep sweeep Boxにおける BFFとmicroservicesアーキテクチャ
©hirac 1 BFFとmicroservicesアーキテクチャ採用の背景 GraphQL/BFF導入のメリットと課題 まとめと今後の課題 Point 2 Point 3 Point
©hirac 3 自己紹介 { "日立": "CTスキャナの制御ソフト開発リーダー ", "フィリップス": "医療IT製品のテクサポ・技術リーダー ",
"シーメンス": "医療IT製品のPM", "オリンパス": "クラウドサービスの開発 PM", "CAPS": "電カル・AI問診など開発エンジニア ", "フリーランス": "SREやテックリード", "sweeep": "CTO" , "twitter": "@kimi_hira" }
本当に紙をやめたい人のための請求書管理ツール
©hirac 5
©hirac 6 新サービス:sweeep Box
©hirac 1 BFFとmicroservicesアーキテクチャ採用の背景 GraphQL/BFF導入のメリットと課題 まとめと今後の課題 Point 2 Point 3 Point
©hirac 8 モノリスなアーキテクチャ Web mobile Backend DB Frontend Backend
©hirac 技術負債 ・モノリスなアーキテクチャを同時修正でコンフリ ・単一DBでデータの肥大化。マイグレーションなど大変 ・凝集度が低く修正箇所漏れ
©hirac Web mobile BFF ServiceX ServiceZ DB DB Frontend BFF
Backend DB BFF & microservicesアーキテクチャ ServiceY
©hirac microservicesで技術負債の解消 ・モノリスなアーキテクチャを同時修正でコンフリ → microservicesで少人数で各service修正 ・単一DBでデータの肥大化。マイグレーションなど大変 → microservices毎にDBをもつ ・凝集度が低く修正箇所漏れ → 適切なドメインで凝集度上げる
©hirac microservicesの課題 ・複数DBにおける情報の集約化 ex. :支払情報とユーザ情報など別DB ・複数リソースにおけるFEの工数増・肥大化 ex. :上記支払情報にあるuser_idとユーザ情報を紐付け → BFFで情報の集約と紐付けを実施し、GraphQLで
集約した情報を返す(複数同時更新のユースケースも)
©hirac 複数リソースにおける情報の集約化 type Payment { """ 支払情報 """ Id: Int!
# 支払管理ID userId: Int! # 担当者ID userName: String! # 担当者名 ... } GraphQL BFF ユーザ DB 支払 DB XXX DB
©hirac 1 BFFとmicroservicesアーキテクチャ採用の背景 GraphQL/BFF導入のメリットと課題 まとめと今後の課題 Point 2 Point 3 Point
©hirac GraphQLメリット ・スキーマ駆動 & mockで並行開発 ・クエリライクで複数リクエストなしに情報を取得できる
©hirac スキーマ駆動 & mockで並行開発 ・スキーマから生成したプログラムなので齟齬がない ・MockによりClient/Server並行開発
©hirac GraphQLスキーマからClient/Server生成 $npm run graphql-codegen --config ./path/to/config.yml Client (TS) →
client/model生成 config.yml /schema: http://localhost:3000/graphql documents: ./src/**/*.graphql generates: ./src/types.ts: plugins: - typescript - typescript-operations $go run github.com/99designs/gqlgen generate BFF (Go) → resolver/model生成 gqlgen.yml schema: "*.graphql" exec: filename: generated.go model: filename: models_gen.go resolver: type: Resolver layout: follow-schema dir: . models: ...
©hirac BFFメリット ・各microservicesリソースをFEの必要な情報に束ねて返す ex.:BFFでUser情報 + 支払い情報を束ねる → FEで情報の操作が必要ない ・EndpointがBFF一箇所で済む →
ない場合はBE (microservices)を意識する必要がある
©hirac → ユーザ情報と支払情報を束ねる BFF無とBFF有の比較 (情報の集約) BFFなし BFFあり
©hirac BFF無とBFF有の比較 (Endpointの集約化) ユーザ DB 支払 DB XXX DB BFF
ユーザ DB 支払 DB XXX DB
©hirac GraphQLの課題 ・GraphQL ↔ Protobufの値の詰め替えが発生 Request:model.xxxInput → pb.xxxRequest Response:model.xxx ←
pb.xxxResponse ex. : GraphQLではintしかサポートしていない Protobufだとint32/64 → Protobuf -> GraphQL生成なども将来検討
©hirac GraphQL ↔ Protobufの値の詰め替え # ユーザ情報Input type UserInput { Id:
Int # ユーザID ... } # ユーザ情報 type User { Id: Int! # ユーザID ... } GraphQL Protobuf // ユーザ情報Request message GetUserRequest { int32 id = 1; // ユーザID ... } // ユーザ情報Response message GetUserResponse { int32 id = 1; // ユーザID ... } toPb int → int32 toGraphQL int ← int32
©hirac BFF課題 ・BFF開発分の工数増・メンテ増 ・ただmicroservices → BFF → FEと透過的に情報を渡して いるだけで冗長に感じることがある ・反面、BFFでいろいろやらせる(=やらせたくなる)と
Fatになるので気をつける → GraphQL Gateway (Apollo Federation)なども将来検討
©hirac 1 BFFとmicroservicesアーキテクチャ採用の背景 GraphQL/BFF導入のメリットと課題 まとめと今後の課題 Point 2 Point 3 Point
©hirac まとめ:GraphQL & BFFメリット ・GraphQLはスキーマ駆動・情報の集約という点でメリット ・BFFはmicroservicesのEndpointの集約・仲介役でメリット → BFFを後から入れるのはインパクトが大きく (BFFの新規開発/Web &
Mobile側の工数/インフラ etc…) 最初に決断してよかった
©hirac 後からBFF新規/Endpoint入替/情報集約... ユーザ DB 支払 DB XXX DB BFF ユーザ
DB 支払 DB XXX DB
©hirac 今後の課題 ・BFF開発分の工数増で冗長に感じることも多いが、 無いとFEで頑張らないといけなかったりする 次のサービスではGraphQL Gatewayなど検討したい ・GraphQL & BFFは現在はWeb &
Mobile共通のため、同時 リリース。共通化やアジリティを下げない仕組みに課題 → アーキテクチャにも「銀の弾丸」はないので改善し続ける
©hirac 参考資料 ・sweeep Box - 書類保管AI ・sweeep Boxで使用している技術スタック ・スタートアップのCTOとして何を考え何を変えたか ・GraphQL
Code Generator ・gqlgen ・みんなで育てる GraphQL スキーマ, それを支える Protobuf / GraphQL and Protobuf
©hirac フロントエンドエンジニア募集してます! ・ご興味のある方は下記リンクよりご応募お待ちしております! sweeep株式会社の募集・採用・求人情報 - Wantedly
©hirac まずはカジュアルに話したい方 ・下記リンクよりお申し込みください! 請求書クラウドAIの開発について共有とCTOとゆるーく雑談 ・会社の雰囲気 sweeep株式会社の働き方とストーリー - Wantedly
©hirac Thank you!