0Pricing
Node.js Backend Development Bootcamp · 강의

Protobuf IDL로 서비스 및 메시지 정의하기

.proto 계약을 작성하고 이를 바탕으로 타입 안전한 클라이언트 및 서버 스텁을 생성합니다.

Protobuf IDL로 서비스 및 메시지 정의하기은(는) CoddyKit의 무료 Node.js Backend Development Bootcamp 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Node.js Backend Development Bootcamp 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Node.js Backend Development Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why an IDL?

In a gRPC microservice, the contract comes before the code. You describe your data and your RPC methods in a language-neutral Interface Definition Language (IDL) called .proto, then generate type-safe stubs for Node.js, Go, Java, and more from that single file.

  • One .proto file is the single source of truth shared by client and server.
  • Protocol Buffers (protobuf) is both the IDL and the binary wire format.
  • You never hand-write the serialization code — the compiler does it.

This lesson shows how to write .proto contracts and turn them into JavaScript client and server stubs.

Anatomy of a .proto file

Every modern .proto file starts by declaring the syntax version and a package. The package namespaces your symbols so two services can both define a User without colliding.

  • syntax = "proto3"; — always use proto3 for new services.
  • package — logical namespace, maps to a JS object path after generation.
  • The file groups message (data shapes) and service (RPC methods).
// user.proto
syntax = "proto3";

package users.v1;

// A data shape sent over the wire
message User {
  string id = 1;
  string email = 2;
  bool active = 3;
}

Messages and field numbers

A message is a record of typed fields. The number after the = is the field tag, not a default value. Tags are how protobuf identifies each field on the binary wire — they must be unique within a message and must never change once deployed.

  • Field names can be renamed freely; tags must stay stable for backward compatibility.
  • Tags 1-15 use a single byte, so reserve them for your most frequent fields.
  • Scalar types: string, bool, int32, int64, double, bytes.
message Product {
  string id = 1;          // tag 1 (1 byte on the wire)
  string name = 2;
  int32 stock = 3;
  double price = 4;
  bool discontinued = 5;
}

proto3 to JavaScript type mapping

When you load a .proto with @grpc/proto-loader, each protobuf type maps to a JavaScript value. Knowing the mapping avoids surprises at runtime.

  • string, bool, int32, float, double map to JS string, boolean, number.
  • int64 / uint64 map to a string by default in JS (numbers can exceed Number.MAX_SAFE_INTEGER).
  • bytes becomes a Buffer.
  • Unset proto3 scalars come back as their zero value ("", 0, false) — they are never undefined on the wire.
// What a decoded User object looks like in Node.js
const user = {
  id: 'u_123',      // string -> string
  email: '',         // unset string -> '' (zero value)
  active: false,     // unset bool -> false
  loginCount: '0'    // int64 -> string, not number!
};

console.log(typeof user.loginCount); // 'string'

Defining a service

A service block lists the RPC methods clients can call. Each rpc takes exactly one request message and returns exactly one response message. Wrapping request/response in dedicated messages (rather than passing bare scalars) lets you add fields later without breaking the contract.

  • Method names are PascalCase by convention.
  • Always define a request and a response message per method, even if one is empty.
message GetUserRequest { string id = 1; }
message GetUserResponse { User user = 1; }

service UserService {
  // unary: one request -> one response
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
  rpc CreateUser(CreateUserRequest) returns (User);
}

The four RPC kinds

The stream keyword on either side of an rpc declaration controls the streaming model. The same IDL keyword decides whether your generated handler receives a single value or a stream.

  • Unary: rpc Get(Req) returns (Res) — one in, one out.
  • Server streaming: returns (stream Res) — server pushes many.
  • Client streaming: (stream Req) — client uploads many.
  • Bidirectional: (stream Req) returns (stream Res).
service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc ListOrders(ListOrdersRequest) returns (stream Order);
  rpc ImportOrders(stream Order) returns (ImportSummary);
  rpc LiveOrders(stream OrderEvent) returns (stream OrderEvent);
}

Enums, repeated, and nested messages

Beyond scalars, protobuf gives you composite shapes for real-world data.

  • enum — a closed set of values; the first member must be 0 and is the default.
  • repeated — an ordered list; decodes to a JS Array.
  • Nested messages model structured sub-records.

Prefix enum members to avoid name clashes, since enum values share the enclosing scope.

enum OrderStatus {
  ORDER_STATUS_UNSPECIFIED = 0; // required zero default
  ORDER_STATUS_PENDING = 1;
  ORDER_STATUS_SHIPPED = 2;
}

message Order {
  string id = 1;
  OrderStatus status = 2;
  repeated LineItem items = 3; // -> JS Array
}

message LineItem {
  string sku = 1;
  int32 qty = 2;
}

Loading the contract in Node.js

In Node you generate stubs at runtime with @grpc/proto-loader plus @grpc/grpc-js. The loader parses the .proto and loadPackageDefinition turns it into a navigable JS object keyed by your package path.

  • keepCase: true preserves field names exactly as written in the proto.
  • longs: String keeps 64-bit ints safe as strings.
  • The package path users.v1 becomes proto.users.v1.
const protoLoader = require('@grpc/proto-loader');
const grpc = require('@grpc/grpc-js');

const pkgDef = protoLoader.loadSync('user.proto', {
  keepCase: true,
  longs: String,
  enums: String,
  defaults: true,
  oneofs: true,
});

const proto = grpc.loadPackageDefinition(pkgDef);
const UserService = proto.users.v1.UserService;

Implementing the server stub

The generated UserService gives you a service definition you register handlers against. Each unary handler receives (call, callback); call.request is your decoded request message, and you reply via the Node-style callback(err, response).

  • Return a gRPC status by passing an error with a code from grpc.status.
  • The response object must match the response message fields.
const server = new grpc.Server();

server.addService(UserService.service, {
  GetUser(call, callback) {
    const { id } = call.request;
    const user = db.find(id);
    if (!user) {
      return callback({
        code: grpc.status.NOT_FOUND,
        message: `User ${id} not found`,
      });
    }
    callback(null, { user });
  },
});

Calling from the client stub

The same generated UserService is also a client constructor. You instantiate it with a target address and credentials, then call methods directly. Each unary call takes the request object and a Node-style callback.

  • credentials.createInsecure() for local/dev; use TLS in production.
  • The request and response are plain JS objects matching the proto messages.
const client = new UserService(
  'localhost:50051',
  grpc.credentials.createInsecure()
);

client.GetUser({ id: 'u_123' }, (err, res) => {
  if (err) {
    console.error(err.code, err.message);
    return;
  }
  console.log(res.user.email);
});

Evolving the contract safely

A contract is only useful if it can change without breaking deployed clients. proto3 makes additive evolution safe when you follow a few rules.

  • Add new fields with new, never-before-used tag numbers — old clients ignore them.
  • Never reuse or renumber tags; mark removed tags with reserved.
  • Renaming a field is wire-compatible (tag is what matters), but breaks JSON/text usage.
  • Use reserved for both removed tag numbers and names to prevent accidental reuse.
message User {
  reserved 4, 5;              // retired tags, never reuse
  reserved "phone";          // retired field name
  string id = 1;
  string email = 2;
  bool active = 3;
  string display_name = 6;   // safe additive change
}

Quick Check

You need to remove the deprecated phone field (tag 4) from a deployed User message. What is the correct, backward-compatible way to do it?

Recap

You learned to design and consume gRPC contracts with Protobuf IDL:

  • A .proto file with syntax = "proto3" and a package is the single source of truth for client and server.
  • message defines typed records; the number after each field is its stable wire tag, not a default.
  • service + rpc declare methods; the stream keyword selects unary, server-, client-, or bidirectional streaming.
  • enum, repeated, and nested messages model richer data; int64 decodes to a JS string.
  • In Node, @grpc/proto-loader + grpc.loadPackageDefinition generate both the server service and the client constructor.
  • Evolve contracts additively and protect retired tags/names with reserved.

자주 묻는 질문

“Protobuf IDL로 서비스 및 메시지 정의하기” 강의는 무료인가요?

네 — “Protobuf IDL로 서비스 및 메시지 정의하기” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Node.js Backend Development Bootcamp 강의 전체를 잠금 해제할 수 있습니다. Node.js Backend Development Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

“Protobuf IDL로 서비스 및 메시지 정의하기”에서 뭘 배우나요?

.proto 계약을 작성하고 이를 바탕으로 타입 안전한 클라이언트 및 서버 스텁을 생성합니다. 브라우저에서 직접 실행하는 실습 코드로 Node.js Backend Development Bootcamp을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Node.js Backend Development Bootcamp을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Node.js Backend Development Bootcamp은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.

“Protobuf IDL로 서비스 및 메시지 정의하기” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Node.js Backend Development Bootcamp 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Node.js Backend Development Bootcamp 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. Protobuf IDL로 서비스 및 메시지 정의하기
  2. 단항, 서버, 클라이언트 및 양방향 스트리밍 RPC
  3. 인터셉터, 데드라인 및 메타데이터
  4. Proto 진화와 하위 호환성
← Node.js Backend Development Bootcamp(으)로 돌아가기