> Что такое protobuf и как он используется в gRPC (Go)

Короткий ответ

Protobuf (Protocol Buffers) - это бинарный формат сериализации данных от Google, основанный на описании структур в .proto файлах. В gRPC он используется как язык определения интерфейсов (IDL) и формат обмена сообщениями по умолчанию. Вы описываете сервис и сообщения в .proto, затем компилятор генерирует код на Go - структуры с методами сериализации и интерфейсы клиента/сервера. Это обеспечивает строгую типизацию, компактность и скорость по сравнению с JSON.

Подробное объяснение

Protobuf работает в два этапа: сначала вы описываете схему данных в текстовом файле .proto, затем запускаете компилятор protoc с плагином для Go (protoc-gen-go и protoc-gen-go-grpc). На выходе получаются обычные Go-структуры с методами Marshal/Unmarshal и интерфейсы для gRPC.

В gRPC protobuf выполняет две роли:

• IDL - определяет контракт сервиса: методы, их входные и выходные типы. Это позволяет генерировать клиентский и серверный код на разных языках из одного файла.
• Формат передачи - сообщения сериализуются в бинарный вид, который занимает меньше места и обрабатывается быстрее, чем JSON или XML.

Ключевые особенности protobuf:

• Нумерация полей - каждое поле имеет номер, который используется в бинарном представлении. Это позволяет добавлять новые поля без поломки совместимости.
• Совместимость версий - можно менять схему, сохраняя обратную совместимость за счёт правил (не удалять поля, не менять номера).
• Генерация кода - компилятор создаёт код, который не нужно писать вручную, что исключает ошибки в сериализации.

На практике

В Go-проекте с gRPC вы обычно:

1. Создаёте файл api/user.proto с описанием сервиса и сообщений.
2. Добавляете в go.mod зависимости google.golang.org/protobuf и google.golang.org/grpc.
3. Запускаете protoc с плагинами для генерации .pb.go и _grpc.pb.go файлов.
4. Импортируете сгенерированные пакеты в код сервера и клиента.

Сгенерированный код содержит:

• Структуры с getter'ами и методами Reset, String, ProtoReflect.
• Интерфейс сервера, который нужно реализовать.
• Клиентский интерфейс с готовыми методами для вызова RPC.

Важно: protobuf не поддерживает nil для скалярных полей - для опциональных значений используйте optional или указатели. Также не стоит хранить большие бинарные данные в одном сообщении - лучше использовать стриминг.

Пример кода

Файл api/user.proto:

syntax = "proto3";

package user;

option go_package = "example.com/project/gen/user";

message UserRequest {
  int32 id = 1;
}

message UserResponse {
  string name = 1;
  string email = 2;
}

service UserService {
  rpc GetUser(UserRequest) returns (UserResponse);
}

Генерация кода:

BASH
protoc --go_out=. --go_opt=paths=source_relative \
       --go-grpc_out=. --go-grpc_opt=paths=source_relative \
       api/user.proto

Реализация сервера:

GO
type userServer struct {
    user.UnimplementedUserServiceServer
}

func (s *userServer) GetUser(ctx context.Context, req *user.UserRequest) (*user.UserResponse, error) {
    return &user.UserResponse{
        Name:  "Alice",
        Email: "alice@example.com",
    }, nil
}

Как отвечать на собеседовании

Начните с простого определения: protobuf - бинарный формат сериализации и IDL для gRPC. Затем объясните, что .proto файл описывает и сообщения, и сервисы, а компилятор генерирует код. Упомяните преимущества: компактность, скорость, строгая типизация, кросс-языковая совместимость. Если спросят про нумерацию полей - объясните, что номера важны для бинарного формата и совместимости версий. Для junior достаточно показать понимание базового цикла: описал схему → сгенерировал код → используешь в сервисе.

Что проверяет интервьюер

Интервьюер хочет убедиться, что вы понимаете:

• Зачем нужен protobuf в gRPC, а не только как его использовать.
• Разницу между IDL и форматом передачи данных.
• Как работает генерация кода и почему это удобно.
• Базовые правила совместимости схем (не менять номера полей, не удалять поля).

Для junior достаточно, если вы можете описать процесс и привести простой пример. Не нужно углубляться в детали wire format или advanced features.

Типичные ошибки

• Путать protobuf с JSON или XML - это не текстовый формат, а бинарный.
• Не упоминать, что .proto описывает и сервисы, а не только данные.
• Говорить, что protobuf работает только с gRPC - он может использоваться и отдельно.
• Забывать про необходимость генерации кода - некоторые думают, что структуры нужно писать вручную.
• Не знать, что поля имеют номера, которые критичны для совместимости.
• Путать optional и required - в proto3 required нет, все поля опциональны по умолчанию.