golang-grpc

por samber

Proporciona pautas de uso de gRPC, organización de protobuf y patrones listos para producción para microservicios en Golang. Úsalo al implementar, revisar o depurar servidores/clientes gRPC, escribir archivos proto, configurar interceptores, manejar errores gRPC con códigos de estado, configurar TLS/mTLS, probar con bufconn o trabajar con RPC de transmisión.

npx skills add https://github.com/samber/cc-skills-golang --skill golang-grpc

Persona: You are a Go distributed systems engineer. You design gRPC services for correctness and operability — proper status codes, deadlines, interceptors, and graceful shutdown matter as much as the happy path.

Modes:

  • Build mode — implementing a new gRPC server or client from scratch.
  • Review mode — auditing existing gRPC code for correctness, security, and operability issues.

Dependencies:

  • protoc: brew install protobuf
  • protoc-gen-go: go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
  • protoc-gen-go-grpc: go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

Go gRPC Best Practices

Treat gRPC as a pure transport layer — keep it separate from business logic. The official Go implementation is google.golang.org/grpc.

This skill is not exhaustive. Please refer to library documentation and code examples for more information. For Go package docs, symbols, versions, importers, and known vulnerabilities, → See samber/cc-skills-golang@golang-pkg-go-dev skill (godig) — prefer it over Context7 for Go package facts. To navigate this library's usage in your own code (definitions, call sites, diagnostics), → See samber/cc-skills-golang@golang-gopls skill (gopls). Context7 remains a fallback for docs not indexed on pkg.go.dev.

Quick Reference

ConcernPackage / Tool
Service definitionprotoc or buf with .proto files
Code generationprotoc-gen-go, protoc-gen-go-grpc
Error handlinggoogle.golang.org/grpc/status with codes
Rich error detailsgoogle.golang.org/genproto/googleapis/rpc/errdetails
Interceptorsgrpc.ChainUnaryInterceptor, grpc.ChainStreamInterceptor
Middleware ecosystemgithub.com/grpc-ecosystem/go-grpc-middleware
Testinggoogle.golang.org/grpc/test/bufconn
TLS / mTLSgoogle.golang.org/grpc/credentials
Health checksgoogle.golang.org/grpc/health

Proto File Organization

Organize by domain with versioned directories (proto/user/v1/). Always use Request/Response wrapper messages — bare types like string cannot have fields added later. Generate with buf generate or protoc.

Proto & code generation reference

Server Implementation

  • Implement health check service (grpc_health_v1) — Kubernetes probes need it to determine readiness
  • Use interceptors for cross-cutting concerns (logging, auth, recovery) — keeps business logic clean
  • Use GracefulStop() with a timeout fallback to Stop() — drains in-flight RPCs while preventing hangs
  • Disable reflection in production — it exposes your full API surface
srv := grpc.NewServer(
    grpc.ChainUnaryInterceptor(loggingInterceptor, recoveryInterceptor),
)
pb.RegisterUserServiceServer(srv, svc)
healthpb.RegisterHealthServer(srv, health.NewServer())

go srv.Serve(lis)

// On shutdown signal:
stopped := make(chan struct{})
go func() { srv.GracefulStop(); close(stopped) }()
select {
case <-stopped:
case <-time.After(15 * time.Second):
    srv.Stop()
}

Interceptor Pattern

func loggingInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
    start := time.Now()
    resp, err := handler(ctx, req)
    log.Printf("method=%s duration=%s code=%s", info.FullMethod, time.Since(start), status.Code(err))
    return resp, err
}

Client Implementation

  • Reuse connections — gRPC multiplexes RPCs on a single HTTP/2 connection; one-per-request wastes TCP/TLS handshakes
  • Set deadlines on every call (context.WithTimeout) — without one, a slow upstream hangs goroutines indefinitely
  • Use round_robin with headless Kubernetes services via dns:/// scheme
  • Pass metadata (auth tokens, trace IDs) via metadata.NewOutgoingContext
conn, err := grpc.NewClient("dns:///user-service:50051",
    grpc.WithTransportCredentials(creds),
    grpc.WithDefaultServiceConfig(`{
        "loadBalancingPolicy": "round_robin",
        "methodConfig": [{
            "name": [{"service": ""}],
            "timeout": "5s",
            "retryPolicy": {
                "maxAttempts": 3,
                "initialBackoff": "0.1s",
                "maxBackoff": "1s",
                "backoffMultiplier": 2,
                "retryableStatusCodes": ["UNAVAILABLE"]
            }
        }]
    }`),
)
client := pb.NewUserServiceClient(conn)

Error Handling

Always return gRPC errors using status.Error with a specific code — a raw error becomes codes.Unknown, telling the client nothing actionable. Clients use codes to decide retry vs fail-fast vs degrade.

CodeWhen to Use
InvalidArgumentMalformed input (missing field, bad format)
NotFoundEntity does not exist
AlreadyExistsCreate failed, entity exists
PermissionDeniedCaller lacks permission
UnauthenticatedMissing or invalid token
FailedPreconditionSystem not in required state
ResourceExhaustedRate limit or quota exceeded
UnavailableTransient issue, safe to retry
InternalUnexpected bug
DeadlineExceededTimeout
// ✗ Bad — caller gets codes.Unknown, can't decide whether to retry
return nil, fmt.Errorf("user not found")

// ✓ Good — specific code lets clients act appropriately
if errors.Is(err, ErrNotFound) {
    return nil, status.Errorf(codes.NotFound, "user %q not found", req.UserId)
}
return nil, status.Errorf(codes.Internal, "lookup failed: %v", err)

For field-level validation errors, attach errdetails.BadRequest via status.WithDetails.

Streaming

PatternUse Case
Server streamingServer sends a sequence (log tailing, result sets)
Client streamingClient sends a sequence, server responds once (file upload, batch)
BidirectionalBoth send independently (chat, real-time sync)

Prefer streaming over large single messages — avoids per-message size limits and lowers memory pressure.

func (s *server) ListUsers(req *pb.ListUsersRequest, stream pb.UserService_ListUsersServer) error {
    for _, u := range users {
        if err := stream.Send(u); err != nil {
            return err
        }
    }
    return nil
}

Testing

Use bufconn for in-memory connections that exercise the full gRPC stack (serialization, interceptors, metadata) without network overhead. Always test that error scenarios return the expected gRPC status codes.

Testing patterns and examples

Security

  • TLS MUST be enabled in production — credentials travel in metadata
  • For service-to-service auth, use mTLS or delegate to a service mesh (Istio, Linkerd)
  • For user auth, implement credentials.PerRPCCredentials and validate tokens in an auth interceptor
  • Reflection SHOULD be disabled in production to prevent API discovery

Performance

SettingPurposeTypical Value
keepalive.ServerParameters.TimePing interval for idle connections30s
keepalive.ServerParameters.TimeoutPing ack timeout10s
grpc.MaxRecvMsgSizeOverride 4 MB default for large payloads16 MB
Connection poolingMultiple conns for high-load streaming4 connections

Most services do not need connection pooling — profile before adding complexity.

Common Mistakes

MistakeFix
Returning raw errorBecomes codes.Unknown — client can't decide whether to retry. Use status.Errorf with a specific code
No deadline on client callsSlow upstream hangs indefinitely. Always context.WithTimeout
New connection per requestWastes TCP/TLS handshakes. Create once, reuse — HTTP/2 multiplexes RPCs
Reflection enabled in productionLets attackers enumerate every method. Enable only in dev/staging
codes.Internal for all errorsWrong codes break client retry logic. Unavailable triggers retry; InvalidArgument does not
Bare types as RPC argumentsCan't add fields to string. Wrapper messages allow backwards-compatible evolution
Missing health check serviceKubernetes can't determine readiness, kills pods during deployments
Ignoring context cancellationLong operations continue after caller gave up. Check ctx.Err()

Cross-References

  • → See samber/cc-skills-golang@golang-context skill for deadline and cancellation patterns
  • → See samber/cc-skills-golang@golang-error-handling skill for gRPC error to Go error mapping
  • → See samber/cc-skills-golang@golang-observability skill for gRPC interceptors (logging, tracing, metrics)
  • → See samber/cc-skills-golang@golang-testing skill for gRPC testing with bufconn

Más skills de samber

golang-code-style
samber
Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber/cc-skills-golang@golang-naming` skill), linter configuration (→ See `samber/cc-skills-golang@golang-lint` skill), or doc comments (→ See `samber/cc-skills-golang@golang-documentation` skill).
developmentcode-review
golang-testing
samber
We need to translate the given text from English to Spanish. The text is a description of a skill for Go testing. We must preserve the name "golang-testing" but it's not in the text, so we don't include it. Also preserve technical terms like "table-driven tests", "testify suites", "mocks", "parallel tests", "fuzzing", "fixtures", "goroutine leak detection", "goleak", "snapshot testing", "code coverage", "integration tests", "idiomatic test naming", "Go test CI", "flaky/slow tests", "testify-specific APIs", "samber/cc-skills-golang@golang-stretchr-testify", "measurement methodology". Also preserve URLs? There is no URL. Numbers? None. Technical terms should be kept as is or translated if common? Usually in technical translations, terms like "table-driven tests" might be translated as "pruebas basadas en tablas" but it's common to keep English terms. The instruction says "Preserve product names
developmenttestingcode-review
golang-design-patterns
samber
Patrones de diseño idiomáticos en Golang: opciones funcionales, constructores, flujo y cascada de errores, gestión y ciclo de vida de recursos, apagado elegante, resiliencia, arquitectura, inyección de dependencias, manejo de datos, streaming y más. Aplicar al elegir explícitamente entre patrones arquitectónicos, implementar opciones funcionales, diseñar APIs de constructores, configurar un apagado elegante, aplicar patrones de resiliencia o preguntar qué patrón idiomático de Go se ajusta a un problema específico.
developmentdesigncode-review
golang-error-handling
samber
We need to translate the given text from English to Spanish, preserving the name "golang-error-handling" as it appears in the source? The instruction says: "Do not include the name unless it appears in the source text." The name "golang-error-handling" is not in the <text> block. The text block contains the description. So we only translate the text inside <text>. Also preserve product names, protocol names, URLs, numbers, technical terms. So "Golang", "slog", "samber/oops", "samber/cc-skills-golang@golang-samber-oops" should remain as is. Also "errors.Is/As", "errors.Join", "panic/recover", "HTTP", "log aggregation", "3rd-party", "Go code". Translate the rest idiomatically. Translation: "Manejo idiomático de errores en Golang: creación, envoltura con %w, errors.Is/As, errors.Join, tipos de error personalizados, errores centinela, panic/recover, la
developmentcode-review
golang-performance
samber
Patrones y metodología de optimización de rendimiento en Golang: si hay un cuello de botella X, entonces aplica Y. Cubre reducción de asignaciones, eficiencia de CPU, diseño de memoria, ajuste de GC, pooling, caching y optimización de rutas críticas. Úsalo cuando el perfilado o los benchmarks hayan identificado un cuello de botella y necesites el patrón de optimización adecuado para solucionarlo. También úsalo al realizar una revisión de código de rendimiento para sugerir mejoras o benchmarks que ayuden a identificar ganancias rápidas de rendimiento. No es para metodología de medición (→...
developmentcode-review
golang-security
samber
Prácticas recomendadas de seguridad y prevención de vulnerabilidades para Golang. Abarca inyección (SQL, comandos, XSS), criptografía, seguridad del sistema de archivos, seguridad de red, cookies, gestión de secretos, seguridad de memoria y registro. Aplicar al escribir, revisar o auditar código Go por seguridad, o al trabajar en cualquier código riesgoso que involucre criptografía, E/S, gestión de secretos, manejo de entrada de usuario o autenticación. Incluye configuración de herramientas de seguridad.
securitycode-reviewdevelopment
golang-database
samber
Guía completa para el acceso a bases de datos en Go: consultas parametrizadas, escaneo de estructuras, columnas anulables, transacciones, niveles de aislamiento, SELECT FOR UPDATE, pool de conexiones, procesamiento por lotes, propagación de contexto y herramientas de migración. Úsela al escribir, revisar o depurar código Golang que interactúe con PostgreSQL, MariaDB, MySQL o SQLite; para pruebas de bases de datos; o para preguntas sobre database/sql, sqlx o pgx. NO genera esquemas de bases de datos ni SQL de migración.
developmentdatabase
golang-lint
samber
Mejores prácticas de linting y configuración de golangci-lint para proyectos Golang: ejecutar linters, configurar .golangci.yml, suprimir advertencias con directivas nolint, interpretar la salida de lint y seleccionar linters. Úselo al configurar golangci-lint, preguntar sobre advertencias de lint o supresiones nolint, configurar herramientas de calidad de código o elegir linters. También úselo cuando el usuario mencione golangci-lint, go vet, staticcheck o revive.
developmentcode-reviewtesting