Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
220428event_ogura_part
CADDi
May 02, 2022
Technology
0
240
220428event_ogura_part
CADDi
May 02, 2022
Tweet
Share
More Decks by CADDi
See All by CADDi
CADDi AI Lab Description
caddi_eng
0
6.8k
20220526event
caddi_eng
0
200
Introduction of CADDi Vietnam
caddi_eng
0
870
20220512Event_Launch in Vietnam
caddi_eng
0
180
CADDi HCMC Technology Center
caddi_eng
0
280
220428event_overview
caddi_eng
2
280
220428event_matsuda_part
caddi_eng
0
300
220428event_karibe_part
caddi_eng
0
240
Atlassian登壇資料_220324
caddi_eng
0
710
Other Decks in Technology
See All in Technology
DeepL の用語集が(いつのまにか)日本語に対応してたので試してみた
irokawah0
0
170
紙にまつわる苦しみを機能化してきた カミナシの歴史
kaminashi
0
1.3k
QiitaConference2022
fuwasegu
0
190
現状のFedCMの動作解説と OIDCとの親和性について- OpenID TechNight vol.19
ritou
2
450
What's new in Vision
satotakeshi
0
220
音のような言葉 〜ちゃちゃっとチャットで楽しむちょっとしたコツ〜 / words like sounds
satoryu
1
1.4k
20220622_FinJAWS_あのときにAWSがあったらこうできた
taketakekaho
0
110
サイボウズの アジャイル・クオリティ / Agile Quality at Cybozu
cybozuinsideout
PRO
4
2.3k
スクラムのスケールとチームトポロジー / Scaled Scrum and Team Topologies
daiksy
1
450
ラブグラフ紹介資料 〜プロダクト解体新書〜 / Lovegraph Product Deck
lovegraph
0
270
DOM Invader - prototype pollution対応の衝撃 - / DOM Invader - prototype pollution
okuken
0
160
モブに早く慣れたい人のためのガイド / A Guide to Getting Started Quickly with Mob Programming
cybozuinsideout
PRO
2
1.8k
Featured
See All Featured
Writing Fast Ruby
sferik
612
57k
How to train your dragon (web standard)
notwaldorf
58
3.9k
Reflections from 52 weeks, 52 projects
jeffersonlam
337
17k
How To Stay Up To Date on Web Technology
chriscoyier
780
250k
Six Lessons from altMBA
skipperchong
14
1.4k
Testing 201, or: Great Expectations
jmmastey
21
5.4k
Designing with Data
zakiwarfel
91
3.9k
Bash Introduction
62gerente
597
210k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
224
49k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_i
23
15k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
10
3.4k
Docker and Python
trallard
27
1.6k
Transcript
A B O U T Rust製の業務Webアプリケーションを Rustでリプレイス
A B O U T Rust製の業務Webアプリケーションを Rustでリプレイス のドサクサでBFF/FEを大整理した話
Ken Ogura 3 • フロントエンドエンジニア @CADDi • 受発注管理アプリケーションのBFF/FE開発 • 競技プログラミングが得意
• YouTuber
あらすじ • 受発注プロダクトBFF/FEの開発体験が下がり始めていた • BEを刷新することになったしBFF/FEも整理しよう!
技術スタック 5 5 FRONTEND ・React ・TypeScript ・Styled-Components ・Next.js ・Storybook ・Jest
・Apollo Client BFF ・TypeScript ・Node.js ・NestJS (Express) ・Apollo Server BACKEND (microservices) ・Rust ・diesel ・tonic GraphQL gRPC Infrastructure GCP, Docker, Kubernetes, Cloudflare, Datadog Event Bus Cloud Pub/Sub DevOps GitHub, CircleCI, ArgoCD, Kustomize
技術スタック 6 FRONTEND ・React ・TypeScript ・Styled-Components ・Next.js ・Storybook ・Jest ・Apollo
Client BFF ・TypeScript ・Node.js ・NestJS (Express) ・Apollo Server BACKEND (microservices) ・Rust ・diesel ・tonic GraphQL gRPC Infrastructure GCP, Docker, Kubernetes, Cloudflare, Datadog Event Bus Cloud Pub/Sub DevOps GitHub, CircleCI, ArgoCD, Kustomize ここの話をします
大整理その1 7 GraphQLを コードファーストに 統一
GraphQLをコードファーストに統一 8 • APIといえばこんな格好をしている
GraphQLをコードファーストに統一 9 • APIといえばこんな格好をしている • Schemaによってお互いのReq/Resの仕様の約束ができる
GraphQLをコードファーストに統一 10 • FE/BFF間は具体的にはこうなっている
GraphQLをコードファーストに統一 11 • オリジナルProductの最初期の依存関係はこう ◦ ServerをSchemaFirstで開発 ①スキーマを定義 ②スキーマに則って サーバを実装 凡例
GraphQLをコードファーストに統一 12 • 諸事情でこうなっていく ◦ 一部CodeFirstも生じる ②実装をもとに スキーマを自動生成 ①サーバを実装 凡例
GraphQLをコードファーストに統一 13 • 混在はまずいのでコードファーストに統一 ◦ ポリシーが統一されて開発体験向上🚀🚀 凡例
GraphQLをコードファーストに統一 14 • なぜコードファーストに統一したのか? ◦ 謎を解明するためにドメインの奥地に、、、
GraphQLをコードファーストに統一 15 • かつての依存関係はこうなっていた 凡例
GraphQLをコードファーストに統一 16 • BFFのGraphQLサーバー部分をコードファーストにすると、、、 凡例
GraphQLをコードファーストに統一 17 • BFFのGraphQLサーバー部分をコードファーストにすると、、、 ◦ 依存の方向が統一されてCleanな感じに! 凡例
GraphQLをコードファーストに統一 まとめ 18 • 実装方法のポリシーが統一された • クリーンな構造になったために責務の 切り分けを意識しやすくなった • 開発体験向上🚀🚀🚀
大整理その2 19 gRPCスキーマと BFFを 同じリポジトリで管理 ※実際のところ BEもFEも全部まとめてモノレポ化して います
モノレポ化 20 • かつては、gRPCスキーマ(ProtoBuf)を別リポジトリに管理 • 更新が大変 ◦ サブモジュールを更新し忘れて動かない ◦ PRがたくさんできる
◦ CIが複雑
モノレポ化 21 • リプレイス後はモノリポジトリに! • 開発時に行ったり来たりしなくても良い ◦ サービスのデプロイはCIで出し分ければ アーキテクチャの疎結合性は 保たれる。
その他整理 22 - GraphQLスキーマの設計、コンベンションに従う - Backにあるマイクロサービス群を オブジェクトのつながりという形でまとめあげる - BFFの責務が明確になる -
GraphQLでフィールドレベルのリゾルバを使う - N+1問題の解決をBE層まで引きずっていた過去との決別 - ほかにも細々と
まとめ 23 - ドメインを型で守るときは型定義の一貫性を保つために 依存性を意識すると開発体験向上🚀🚀🚀🚀 - リポジトリが同じか分かれているかはサービスの結合度 とは独立した概念! モノレポにするかどうかは開発体験のウェイトを大きくして検討して 良い