Protocol Buffersを理解する

到達していたい状態

• Protocol Buffersとは何かを人に説明できる
• Protocol Buffersを使用して開発に取り組めるようになる

やること

• Protocol Buffersについて調べる
• Protocol Buffersのドキュメントを読む

Protocol Buffersとは？

概要

Googleが作成したスキーマ言語で、データ構造やインターフェース（APIなど）を定義できます。
略して「protobuf」などとも言う。

Protocol buffers are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.

サポート言語

言語自体も割とサポートされている

Protocol buffers support generated code in C++, C#, Dart, Go, Java, Kotlin, Objective-C, Python, and Ruby. With proto3, you can also work with PHP.

上記にサポートがなくても、プラグインやライブラリを使えばコンパイルは可能そう。

どうやって使うの？

1. Protocol Buffersの形式に沿って**.protoファイルにデータ構造を記述する
2. **.protoからデータ構造を対象の言語に自動生成する
3. プログラムから自動生成したデータ構造をimportしたりして使う

参考

Protocol Buffersはなぜ必要なのか？

1. スキーマファーストで開発できる

protobufを開発のフローに入れると、まずは.protoにスキーマを定義する必要があるので、スキーマファーストの開発が強制される。（そもそも.protoにスキーマを定義して、実際のプログラムを生成しないと実装を始めることができない）

スキーマファーストで開発をすることによって以下のメリットがある。

• サーバーサイドとクライアントサイドが同時に開発できる
  • 事前にスキーマが決まっているのでそれを元に作成が可能
• データに関する暗黙の知識を言語化し、共有できる
  • そもそも何を作っているのか、どのようなデータを扱うのかのドメイン理解がわかりやすい
  • データのフィールドの型もprotobufで記述できるので、想定がしやすい

2. コミュニケーションコスト、コミュニケーションリスクが減る

今までのAPI開発ではバックエンドエンジニアが「リクエストはこの想定で、レスポンスこんな感じできます」みたいなJSONをフロントエンドに連絡する、みたいなコミュニケーションをしていたが、これだと以下の問題点がある。

• 手戻りが発生した時の確認コストがかかる
• 細かい部分の認識合わせのコストがかかる
  • データはnullかどうかなど、少し混み合った話だと特に
• しれっとAPIの実装を変更できてしまう

protobufを使用すればスキーマ定義をする段階や、修正の段階でレビューや合意が明示的に必要になるので、これらのコストやリスクかなり押さえられる。

実装フェーズに入った時もスムーズにモックが作れる