grpc-patterns

Generate gRPC service patterns with protobuf contracts and status code handling.

6|1|Updated Mar 30, 2026
One-click install
npx skills add https://github.com/wesleyosantos91/multi-agents --skill grpc-patterns-wesleyosantos91
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grpc-patterns
Source: https://github.com/wesleyosantos91/multi-agents/tree/main/devin/.devin/skills/grpc-patterns
Command: npx skills add https://github.com/wesleyosantos91/multi-agents --skill grpc-patterns-wesleyosantos91

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

gRPC API design often fails in production due to weak schema discipline, missing backward-compatibility rules, inconsistent error handling, and absent operational concerns like deadlines and observability.

Core Features & Use Cases

  • Protobuf schema-first guidance: Define services, messages, streaming RPCs, and strong contracts using Protobuf (including examples of request/response modeling).
  • Backward compatibility rules: Prevent breaking changes by avoiding renumbering/removing fields without reserved, and enforcing enum safety with UNSPECIFIED = 0.
  • Operational production patterns: Apply interceptors (middleware), deadlines/timeouts, consistent Status codes, and integration testing practices across common stacks (Java, Go, Python).
  • When to choose gRPC vs REST: Use decision criteria for internal service-to-service, public APIs, streaming needs, and performance characteristics.

Quick Start

Use the grpc-patterns skill to review or generate a gRPC service contract and implementation details for a production system, including Protobuf compatibility and correct error/status handling.

Frequently Asked Questions about grpc-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a gRPC API that maintains backward compatibility?

To maintain gRPC API backward compatibility, avoid renumbering or removing fields without using the reserved keyword, and enforce enum safety by setting UNSPECIFIED = 0. These protobuf schema rules prevent breaking changes in production.

What's the best way to handle gRPC errors and status codes?

The best way to handle gRPC errors is by implementing robust error handling with consistent gRPC Status codes. This ensures runtime correctness and clear communication of failure states across internal service-to-service APIs.

When do I need to use gRPC streaming RPCs instead of unary calls?

You need gRPC streaming RPCs instead of unary calls when building endpoints requiring continuous data flow or real-time updates. Protobuf schema-first guidance helps define both streaming and unary RPCs with strong contracts.

How do I enforce deadlines and timeouts in a gRPC service?

To enforce deadlines and timeouts in a gRPC service, apply operational production patterns like interceptors or middleware. This ensures runtime correctness by preventing indefinitely hanging requests across Java, Go, and Python stacks.

Does gRPC work better than REST for internal service-to-service APIs?

gRPC works better than REST for internal service-to-service APIs due to its performance characteristics and protobuf contracts. Decision criteria favor gRPC for internal needs, streaming requirements, and schema-first API evolution over public REST endpoints.

Why does removing a protobuf field break my gRPC implementation?

Removing a protobuf field breaks your gRPC implementation because it violates backward compatibility rules. You must use the reserved keyword for field numbers and names to prevent runtime errors when older clients communicate with newer services.