gRPCのベストプラクティス
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEji0lBfkpff_HooaGceEKGqts0U70VR-Xp88TC5BLHfWrmKmQSnDwuw5WhFnwUvMKpcplesAtBTPLagZUqKckHP_fH1dPiKccq9hTsoCyWeiEguQfKuMJbWRPWLrFeT2Vl2D666KDmuW_XKGDjnBztSlX6VcUIQCF-i6AQPoAsl1m9wrSVv5Rx1Klz6Uw/s400/eto_usagi_head.png
いろいろ模索しながら良さそうなもの、良かったものをまとめています
Protocol Buffers のスタイルガイドを見る
まず参照してほしいのが Protocol Buffers 自体のスタイルガイド
1行の長さと言った細かいところから パッケージの設計、メッセージ名など基礎的な部分を含む
ほとんどが後述する Buf でフォーマットやLintの対象となるのでチラ見程度で良い。 Google Cloud API 設計ガイドを参考にする
Google Cloud のドキュメントに gRPC を使った APIの設計ガイドが存在する。
ほとんどの命名や構造に関する悩みはこれで解決される
Cloud API やその他の Google API を設計するときに Google が従うガイドとして運用されている
より一般的なネットワークAPIの設計の基準として使用できる
gRPC のメソッド やリソース、サービスの単位など設計に関係する指標が具体的に言及されている
Buf を使って Lint と Format とコンパイルをする
Buf という gRPC を使った開発を支援するツールが存在する ほとんどのディレクトリ構造やビルドツールの悩みはこれで解決される
Linter、Formatter、コンパイラとして機能するため、多くのプラクティスをこのツールから享受できる
Protocol Buffers のスタイルガイドで言及されている殆どの項目はフォーマット対象になる
Linter で指摘される項目は「なぜだめでどうするべきか」まで言及されており非常に参考になる
複雑になりがちなビルドコマンドを予め設定ファイルとして再現性のある状態で管理できることもメリット
gRPC-WEB と TypeScript の組み合わせでは connect-web を使う
ESM を意識した実装となっており、これから先の時代に対応するにちょうどよくサイズも小さい