web-dev-qa-db-ja.com

プロトコルバッファーとJson-どちらを選択するか

マイクロサービスアーキテクチャで、JSONの代わりにプロトコルバッファーを使用する場合について説明できますか?およびその逆?同期通信と非同期通信の両方。

9
Kaidul

JSONを使用する場合

  • 人間が読めるデータが必要または必要
  • サービスからのデータはWebブラウザーによって直接消費されます
  • サーバー側アプリケーションはJavaScriptで記述されています
  • データモデルをスキーマに関連付ける準備ができていません
  • 武器に別のツールを追加するための帯域幅がありません
  • 別の種類のネットワークサービスを実行する運用上の負担が大きすぎる

ProtoBufの長所

  • 保証型安全性
  • スキーマ違反を防止
  • シンプルなアクセサーを提供します
  • 高速シリアライゼーション/デシリアライゼーション
  • 下位互換性

その間、 flatbuffers を見たことはありますか?

ここでは、いくつかの側面について説明します google protocol buffers vs json vs XML

参照:

https://codeclimate.com/blog/choose-protocol-buffers/

https://codeburst.io/json-vs-protocol-buffers-vs-flatbuffers-a4247f8bda6f

9
so-random-dude

コンシューマーがJSONの組み込みサポートが組み込まれた言語(JavaScriptがその例です)、Webブラウザー、または人間の可読性が求められる場合に、JSONを使用します。そういえば、少なくとも非同期呼び出しの場合、多くの開発者は、デバッグのために、そして通常の開発過程の間でも、キューの内容を直接調べるという便利さを楽しんでいます。使用する技術スタックに応じて、ネットワーク負荷を減らすためだけにprotobufを使用することは、トレードオフに値する場合とそうでない場合があります。これは、パフォーマンスが向上しても非同期の世界ではあまり効果がないためです。そして、ほとんどの言語でJSONマーシャリングおよびアンマーシャリングを使用していたように、ボイラープレートコードの束を記述する必要がなくなったわけではありません。

他のすべてにprotobufを使用します...上記の考慮事項を備えた他のユースケースが残っている場合。パフォーマンス、ネットワーク負荷、バージョン管理スキームによって提供される下位互換性、プロトファイルに魔法のように付属している素敵なドキュメント、検証など、目に見える利点があります。何らかの理由でRESTまたはマイクロサービス間の他の同期呼び出しがある場合、ヒープを提供しながら、Protobufは多くのトレードオフがあったとしても、JSONの代わりにネットワーク経由で送信できます。利点の。

1
Gerry Mantha