Rust製の業務WebアプリケーションをRustでリプレイス_220428

Transcript

1. A B O U T Rust製の業務Webアプリケーションを Rustでリプレイス
2. A B O U T Rust製の業務Webアプリケーションを Rustでリプレイス のドサクサでBFF/FEを大整理した話
3. Ken Ogura 3 • フロントエンドエンジニア @CADDi • 受発注管理アプリケーションのBFF/FE開発 • 競技プログラミングが得意 • YouTuber
4. あらすじ • 受発注プロダクトBFF/FEの開発体験が下がり始めていた • BEを刷新することになったしBFF/FEも整理しよう！
5. 技術スタック 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. 技術スタック 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 ここの話をします
7. 大整理その１ 7 GraphQLを コードファーストに 統一
8. GraphQLをコードファーストに統一 8 • APIといえばこんな格好をしている
9. GraphQLをコードファーストに統一 9 • APIといえばこんな格好をしている • Schemaによってお互いのReq/Resの仕様の約束ができる
10. GraphQLをコードファーストに統一 10 • FE/BFF間は具体的にはこうなっている
11. GraphQLをコードファーストに統一 11 • オリジナルProductの最初期の依存関係はこう ◦ ServerをSchemaFirstで開発 ①スキーマを定義 ②スキーマに則って 　サーバを実装 凡例
12. GraphQLをコードファーストに統一 12 • 諸事情でこうなっていく ◦ 一部CodeFirstも生じる ②実装をもとに 　スキーマを自動生成 ①サーバを実装 凡例
13. GraphQLをコードファーストに統一 13 • 混在はまずいのでコードファーストに統一 ◦ ポリシーが統一されて開発体験向上🚀🚀 凡例
14. GraphQLをコードファーストに統一 14 • なぜコードファーストに統一したのか？ ◦ 謎を解明するためにドメインの奥地に、、、
15. GraphQLをコードファーストに統一 15 • かつての依存関係はこうなっていた 凡例
16. GraphQLをコードファーストに統一 16 • BFFのGraphQLサーバー部分をコードファーストにすると、、、 凡例
17. GraphQLをコードファーストに統一 17 • BFFのGraphQLサーバー部分をコードファーストにすると、、、 ◦ 依存の方向が統一されてCleanな感じに！ 凡例
18. GraphQLをコードファーストに統一　まとめ 18 • 実装方法のポリシーが統一された • クリーンな構造になったために責務の 切り分けを意識しやすくなった • 開発体験向上🚀🚀🚀
19. 大整理その２ 19 gRPCスキーマと BFFを 同じリポジトリで管理 ※実際のところ BEもFEも全部まとめてモノレポ化して います
20. モノレポ化 20 • かつては、gRPCスキーマ(ProtoBuf)を別リポジトリに管理 • 更新が大変 ◦ サブモジュールを更新し忘れて動かない ◦ PRがたくさんできる ◦ CIが複雑
21. モノレポ化 21 • リプレイス後はモノリポジトリに！ • 開発時に行ったり来たりしなくても良い ◦ サービスのデプロイはCIで出し分ければ アーキテクチャの疎結合性は 保たれる。
22. その他整理 22 - GraphQLスキーマの設計、コンベンションに従う - Backにあるマイクロサービス群を オブジェクトのつながりという形でまとめあげる - BFFの責務が明確になる - GraphQLでフィールドレベルのリゾルバを使う - N+1問題の解決をBE層まで引きずっていた過去との決別 - ほかにも細々と
23. まとめ 23 - ドメインを型で守るときは型定義の一貫性を保つために 依存性を意識すると開発体験向上🚀🚀🚀🚀 - リポジトリが同じか分かれているかはサービスの結合度 とは独立した概念！ モノレポにするかどうかは開発体験のウェイトを大きくして検討して 良い