Open5
BFF調査
フロントエンドえんじにゃーやりたいこと整理
- BFFの解像度を上げる
- BFFを実装する為に何が必要なのかをあつめる
- Next.js / Nest.js / gRPC + Goなどひとつひとつの技術に関しての解像度をあげる
- Next.js - GraphQL間のBFF実装
- Go + gRPCのバックエンド実装
- インフラ側の構成がピンと来ていないので、たぶんAWS？既存のインフラサービスでgRPC + Go周りの最適解を探っていく
フロントエンドえんじにゃーBFFの解像度を上げる
↓元々の認識
フロントエンドの為に、バックエンドの技術スタックでよしなにAPIを作るくらい
↓これがしっくり来た
「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」
マイクロサービス化における課題を解決する為に出来たアーキテクチャ
以下に対応
- APIサーバへのリクエスト負荷
- レスポンスパターン増加による処理の複雑化
BFFサーバが配置されることで、フロントエンド、バックエンドともに連携負荷が分散され、アクセスフローがシンプルになる。
BFFで重要なキーワード
- Nest.js
- GraphQL
- Go + gRPC
よくある構成
フロントエンド → Next.js
BFF → Nest.js
バックエンド → Go + gRPC
なぜgRPC
結論：BFFとバックエンド間の通信速度が遅くならない様にする為
- フロントとBFFの通信はGraphQL
- BFFとバックエンド(マイクロサービスで作られた)間はgRPC
なぜGo
gRPCでstream処理を行う時に、goroutineで簡単に並列処理を実装できる
という理由らしい
- ここは実際にgRPC + Goを触ってみる
- あえてgRPC + 別言語をやった場合の比較もやる
なぜNest.js
バックエンドはAPIの為のマイクロサービス群となり、BFFとマイクロサービス群間をgRPCでつなぐ構成が主流
BFFでは、GraphQLとgRPCを両方を取り扱える必要があり、それを満たす為、フレームワークとしてNest.jsが採用されることが多い。
ちらっと見た記事だと、Next.jsをBFFサーバとして利用することもできるっぽい。
記事
フロントエンドえんじにゃーNest.jsの深掘り
- そもそもの書き方
- 既存のgRPCを使ったサーバとの接続
- GraphQLとの接続
以下のスクラップで深ぼっていく
フロントエンドえんじにゃーNext.jsをBFFとして扱う
- 実際の書き方を知る
フロントエンドえんじにゃーgRPC + Goの深掘り
知りたい
- Nest.js と gRPC間の接続
- gRPCをGo言語で扱うには
- gRPCを他言語で扱った場合