🐷
Souzoh Tech Talk #04:Backends For Frontends
概要
2021/09/08に開催された下記勉強会のメモです
パネルディスカッション
- 構成についてはこちら
- 「GraphQL サーバ周辺の構成」
技術選定
- NestJS + GraphQL
- なぜNestJSなのか
- メリット
- Apolloサーバ使える
- コードベースでスキーマ定義できる
- javascript以外触る人もいるので
- 学習コストも低い
- デメリット
- ユーザあまりいない
- コンポーネント思考の馴染みがない人も
- メリット
- なぜNestJSなのか
- なぜBFFが必要なのか
- アグリゲーションする層が必要
- Graphql
- おんなじ要素ちょっとずつ違うものいっぱい用意しないといけない
- 学習コストはある
- メリットが上回る
課題と取り組み
- スキーマ設計
- コードファーストで実装してる
- スキーマ駆動になってない
- 機能単位で開発している
- アプリケーション単位でのモデルの定義綺麗にするの難しい
- コードファーストで実装してる
- N＋1問題
- GraphQLではN＋1問題が起きやすい
- dataloaderを使う
- 最初に紹介したページの↓も参照
「DataLoader を使って Batch Request に対応する」
- 循環参照
- エンティティが相互に参照
- レイヤ構造を作ることによって解決しようとしている
- スキーマの破壊的変更
- 破壊的変更入れても気付きにくい
- GraphQLInspetor入れてる
- CLIやCIでのGitHub Actionで
- こちらも最初に紹介したページの↓も参照
「スキーマの Breaking Change （破壊的変更）を防ぐ」
Q&A
- GraphQLのスキーマ設計についてフロントとバックどっちに寄せる？
- みんなで認識揃える
- バックの人主体でフロントにきく
- サービス内のリソースとかモデルに寄せる
- GraphQLの設計に迷ったらGitHubのGraphQL APIのドキュメント読んで参考にする。
- キャッシュ戦略について
- 複雑なキャッシュの機構はない
- 短い時間のものはある
- DBの変更などにより破壊的変更が発生することはないのでしょうか？
- BFFからDBにアクセスするとかはやってない
- DBの変更はバックエンドでBFFではgRPCを管理
- protocol bufferに変更あるとBFFも変更必要
- その場合はAPIバージョンをあげる
- BFFでトランザクション的な処理はできるか？
- 仕組みとしてはない
- そういう機能作るときはエンジニア全体で考える
- マイクロサービス側で提供してもらう
- 各エンドポイントごとのアクセスログなどはどのように集計？
- GCPのCloud Trace
- NestJSのテストは？
- ユニットテストはあるがE2Eテストない
- 仕組みできてない
- Relay Server Specificationにどのくらい準拠？
- ページネーションできるくらい
- 完全ではない
- バックエンド〜スキーマまでそれなりに一括で生成できたらいいなと思っていますがうまくいきそうな方法ありますか？
- GraphQL Meshみたいなのはあるけど試していない
- monorepoでどうやって開発しているか？
- 大体の流れ
- こういう機能入れたいなどの概要はプロダクトマネージャが作る
- データの流れなど大体の作りはバックエンドの人が考えることが多い
- デザインドックを用意してレビューしてもらう
- protoファイルを必要なRPC分書いてもらってそれぞれ同時に開発が走る
- 大体の流れ
Discussion