Why Protocol Buffers?

• 데이터 직렬화의 세계에는 선택할 수 있는 옵션이 많음.
  • XML, JSON, Protocol Buffers
  • Protocol Buffers → language-neutral, platform-neutral

Protocol Buffer Message 예시

syntax = "proto3";

import "google/protobuf/timestamp.proto";

message User {
	uint32 id = 1;
	string lname = 2;
	string fname = 3;
	google.protobuf.Timestamep bday = 4;
}

• 데이터 자체와 데이터 스키마를 분리함.

프로토콜 버퍼의 이점

1. 강력한 타입 지정

• 위 프로토콜 버퍼 메시지의 경우, uint32, string, timestamp를 가지고 있음.
• 이는 다른 직렬화 형식과 크게 개선된 것처럼 보이진 않음.
  • JSON 에서도 boolean, string, integer를 정의하기 때문.
  • 하지만 프로토콜 버퍼는 필드 유형을 강력하게 강조하기 때문에 문자열을 넣을 수 없음.
  • JSON 에서는 넣을 수 있음.

2. 코드 생성

• JavaScript, C++, Python 모두 코드를 생성할 수 있음.
• 개발자는 데이터 스키마에 집중하고, 데이터가 어떻게 직렬화되는지에 대해 걱정하지 않아도 됨.
• 반면 JSON 의 경우, 스키마 최적화를 위해 키와 값을 더 작게 만드는 방법을 고려해야 함.
• 프로토콜 버퍼에서는 주로 유형 최적화에 집중한다.
  • 직렬화 최적화 방법은 무료로 제공해준다!

3. 스키마 진화

• 진화하는 스키마를 고려하여 설계됨.
• 시간이 지남에 따라 변화에 빠르게 적응할 수 있음.

4. 주석 달기

• 주석을 통해 내용을 설명할 수 있음.
  • JSON에서는 사용할 수 없는 기능임.
  • JSON은 설명을 위해 외부 문서가 필요함.

5. 이진 직렬화

• XML, JSON과 달리 프로토콜 버퍼는 데이터를 이진 형식으로 직렬화 함.
  • 데이터가 훨씬 작고, 관리가 쉬우며, 네트워크를 통해 더 낮은 비용으로 전송할 수 있게 함.

프로토콜 버퍼의 단점

1. 이진 직렬화

• 장점이자 단점인 기능
• 데이터가 이진으로 직렬화되면, 수정하고 읽는 것이 어려워짐.

2. 지원의 한계

• 널리 받아들여진 데이터 스키마인 XML과 JSON에 비해 프로토콜 버퍼의 지원이 적음.
• JSON과 XML은 거의 모든 언어로 전송할 수 있지만, 프로토콜 버퍼는 아직 그렇지 않음.
  • 하지만, 많은 커뮤니티가 이 문제를 해결하려고 노력하고 있음.
  • ex) 구글, 넷플릭스, 스퀘어 등의 회사들이 이미 프로토콜 버퍼를 사용하고 있음.