Lyft社は主にチームやシステム間で共有される定義のための共同プロトコル設計に焦点を当て、システム間統合のためにProtocol Buffersを使用した経験を発表した。同社は、単なる効率性の最適化というよりも、知識共有、一貫性、開発プロセスの質を向上させるアプローチを推進している。
Lyft社は長年Protocol Buffersを採用しており、同社は2020年にHTTP+JSONから移行する理由について、インターフェース定義言語（IDL）としてのProtoBufの記述性、ほとんどの言語用のオープンソースコードジェネレータの利用可能性、最適化されたバイナリフォーマット、JSON APIとの下位互換性を挙げて説明している。
Protocol Buffersを3つの言語スタック（Python、Swift、Kotlin）で長年使用してきたことで、エンジニアはプロトコル定義設計の経験を積んだ。特に、Protobufの使用に精通していない同僚とチームやシステムをまたいで作業する場合にその経験が役立った。LyftのソフトウェアエンジニアであるRoman Kotenko氏は、プロトコル設計の重要な原則を呼びかけた。
明快さ：よく設計されたプロトコルは、どのフィールドを設定しなければならないかを明示するだけでなく、メッセージを定義する必要がある。これによって、実装中にメッセージのどれかを設定ミスすることを防ぐことができる。言い換えれば、優れたプロトコルは実装者にあいまいさを残さない。
拡張性：プロトコルの構造は、将来のビジョンと潜在的なロードマップを念頭に置いて構築されることが極めて重要である。こうすることで、予見可能な追加や重大な変更を事前に考慮できる。
さらにKotenko氏は、Lyftが広範な分散システムのインターフェース定義言語（IDL）としてプロトコルバッファの採用を成功させるために重要であると考えたベストプラクティスをいくつか紹介している。
著者は、Protocol Buffersのメッセージ検証機能を使う利点を強調している。プロジェクトprotovalidateは、ユーザー定義の検証ルールに基づいて実行時にメッセージを検証するための推奨方法である。これはprotoc-gen-validateプラグイン（Lyftで作成され、今のところまだ使用されている）の後継であり、GoogleのCommon Expression Language（CEL）を利用している。このソリューションは、ユニオン（oneof）、enum、コレクション（repeated）、マップ、スカラー（ラッパー型を含む）など、さまざまな種類のメッセージやフィールドに適用できる多くの検証ルールをサポートしている。
Lyftチームは、多くのエンティティにまたがるプロトコル定義で使用される定数値を統一するためのアプローチを確立した。Kotenko氏は、カスタムオプションがその目的のためにどのように使用できるかを示しているが、プロトコル定義ユーザーを完全に制御するための要件（例えば、プロトコルが内部で使用される場合）を含む、このソリューションを採用する際の注意点について警告している。
/filters:no_upscale()/news/2024/09/lyft-protocol-buffers-design/en/resources/1lyft-protocol-buffers-1726056093509.jpeg)
Protocol Buffersメッセージ定義の例（出典：Lyft Engineering Blog）
その他のベストプラクティスは、未知のenum値を含む一般的なユースケースによく知られたデータ型を使用することや、Protobuf 3.15で導入された新しい「optional」ラベルを活用してオプションフィールドを明示的にマークすることなど、公式ドキュメントに含まれるものを反映している。
最後に著者は、言語によって動作が異なるため、必要なセットアップや、型マッピングや生成されるコード機能のような微妙な詳細について学ぶには、言語固有のチュートリアルを確認することが重要であると指摘している。