The Truth About Protocol Buffers: Complete Guide to Binary Encoding and RPC Technologies

Introduction

“What is Protocol Buffer? Is it encryption?” “What’s the difference between gRPC and tRPC?”

Have you ever had such questions? This article provides a detailed explanation from Protocol Buffer binary encoding principles to modern RPC technology comparison with practical examples.

🔧 Protocol Buffer Detailed Technical Analysis

What is Protocol Buffer?

Protocol Buffer is an efficient binary serialization technology for structured data developed by Google. The important thing to understand is that “it’s not encryption.” It’s an encoding technology aimed at efficiency and compression.

The Core of Binary Encoding Principles

The biggest feature of Protocol Buffer is the field number system.

1
2
3
4
5

message User {
  int64 id = 1;      // Field number 1
  string name = 2;   // Field number 2  
  int32 age = 3;     // Field number 3
}

The meaning of this syntax:

• Data type: string
• Field name: name (not actually transmitted!)
• Field number: 2 (this is what’s actually transmitted)

Concrete Binary Analysis Example

Let’s see how it’s actually encoded.

Original data:

1

{"name": "Alice", "age": 26}

Protocol Buffer binary:

1

0A 05 41 6C 69 63 65 10 1A

Detailed analysis:

• 0A 05: Field 2 (name) start, length 5 bytes
• 41 6C 69 63 65: “Alice” string
  • 41 = ASCII 65 = ‘A’
  • 6C = ASCII 108 = ’l'
  • 69 = ASCII 105 = ‘i’
  • 63 = ASCII 99 = ‘c’
  • 65 = ASCII 101 = ’e'
• 10 1A: Field 3 (age) = 26

Efficiency proof:

• JSON: {"name":"Alice","age":26} = 26 bytes
• Protocol Buffer: 0A 05 41 6C 69 63 65 10 1A = 9 bytes
• About 3x more efficient!

Clear Distinction from Encryption

This is a point where many people are confused:

deprecated/reserved Standard Flow

The true value of Protocol Buffer lies in gradual schema evolution.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

message User {
  int64 id = 1;
  string name = 2;
  
  // Stage 1: Deprecation warning
  string email = 3 [deprecated = true];
  
  // Stage 2: Complete deletion, permanent number reservation
  reserved 4;        // Field number permanently reserved
  reserved "phone";  // Field name permanently reserved
}

This mechanism enables:

• Backward compatibility: Works with old clients
• Forward compatibility: Safely add new fields
• Reuse prevention: reserved setting prevents misuse of same names/numbers

🌐 RPC Technology Architecture Comparison Analysis

Broad Definition of RPC

RPC (Remote Procedure Call) refers to “all function calls over the network”.

These that we use regularly are actually all RPCs:

1
2
3
4
5
6
7
8

// This is also RPC
fetch('/api/users/123')

// This is also RPC
const user = await trpc.getUser.query({id: 123})

// This is also RPC
const response = await client.GetUser(request)

Comparison by Implementation Method

4-Axis Decision Framework for Technology Selection

1. Language Environment

   • Single language → tRPC
   • Multi-language mixed → gRPC, REST

2. Communication Frequency

   • High frequency, large volume → gRPC
   • Low frequency, small volume → REST

3. Data Volume

   • Large capacity → Protocol Buffer
   • Small capacity → JSON

4. Development Efficiency

   • Type safety emphasis → tRPC, gRPC
   • Versatility emphasis → REST

Actual Usage Strategy

In actual product development, the following usage differentiation is effective:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

🏢 Inter-microservice communication
→ gRPC (Multi-language environment like Go, Java, Python)

🖥️ Frontend communication  
→ Consider tRPC (TypeScript unified environment)
→ REST (Existing systems, versatility emphasis)

🔌 External API provision
→ REST (Compatibility, ease of understanding)

⚙️ Admin panels, internal tools
→ Regular HTTP API (Simplicity emphasis)

Actual Performance Comparison

When sending the same data using different methods:

Practical Selection Guidelines

When to Choose gRPC

1
2
3
4

✅ High-frequency communication between microservices
✅ Multi-language environment (Go, Java, Python, C++, etc.)
✅ Performance top priority
✅ Strict type safety required

When to Choose tRPC

1
2
3
4

✅ Both frontend and backend use TypeScript
✅ Development efficiency and developer experience priority
✅ High TypeScript proficiency across the team
✅ Communication volume not extremely high

When to Choose REST

1
2
3
4

✅ Providing external APIs
✅ Minimizing team learning costs
✅ Compatibility with existing systems priority  
✅ Debugging and troubleshooting emphasis

Summary

Core of Protocol Buffer

• Binary encoding: Efficiency technology, not encryption
• Field number system: Identification by numbers, not names
• Gradual schema evolution: deprecated→reserved flow
• Outstanding communication efficiency: About 1/3 the size of JSON

Key Points of RPC Technology Selection

• RPC = Broad concept: REST API and gRPC are all RPC
• Diverse implementations: Differentiated by protocol, data format, target languages
• 4-axis decision: Language environment, communication frequency, data volume, development efficiency
• Appropriate use: Using different technologies rather than a single solution

Essence of Technology Selection

What’s important is “appropriate technology selection according to purpose”. Protocol Buffer and gRPC are not silver bullets. The key to success is comprehensively judging project requirements, team situation, and operational constraints to select the optimal combination.

Next time, we plan to explain Protocol Buffer schema design and practical gRPC service implementation patterns in detail. Stay tuned!

Related Articles

• Protocol Buffer Schema Design Best Practices
• Practical gRPC Service Implementation Patterns
• Technology Selection Framework for Inter-Microservice Communication

Written on: 2025-08-25 Category: Technical Articles・Architecture・Protocol Buffer・RPC・gRPC・tRPC Target Audience: Software Engineers・System Architects・Microservice Developers