SKILL·174A7D

go-grpc

eduardo-sl
Updated Yesterday
63
9
63
View on GitHub
Designaiapidesign

About

This Claude Skill provides advanced guidance for implementing production-ready gRPC services in Go. It covers proto design, error handling, interceptors, streaming, deadlines, health checks, and graceful shutdown. Use it specifically for gRPC service implementation, not for REST APIs, general architecture, or security hardening.

Quick Install

Claude Code

Recommended
Primary
npx skills add eduardo-sl/go-agent-skills -a claude-code
Plugin CommandAlternative
/plugin add https://github.com/eduardo-sl/go-agent-skills
Git CloneAlternative
git clone https://github.com/eduardo-sl/go-agent-skills.git ~/.claude/skills/go-grpc

Copy and paste this command in Claude Code to install this skill

Documentation

Go gRPC Services

gRPC's contract-first model only pays off if the contract is treated as an API: versioned packages, deliberate error codes, deadlines everywhere, and interceptors for everything cross-cutting.

1. Proto Design Rules

syntax = "proto3";

package payment.v1;                            // version IN the package
option go_package = "github.com/acme/payment-service/gen/payment/v1;paymentv1";

service PaymentService {
  rpc CreatePayment(CreatePaymentRequest) returns (CreatePaymentResponse);
}

message CreatePaymentRequest {                 // one request/response pair
  string order_id = 1;                         // per RPC, always — even if
  int64 amount_cents = 2;                      // empty today
}

message CreatePaymentResponse {
  Payment payment = 1;
}
  • Version in the package (payment.v1); breaking change = payment.v2.
  • Never reuse or renumber field tags; reserved 3, 7; deleted ones.
  • Dedicated Request/Response messages per RPC — adding a field later is free; changing a shared message breaks every RPC using it.
  • Generate with buf or a pinned protoc in make generate; commit generated code so builds don't depend on toolchain drift.

2. Errors: Status Codes, Not Strings

Return status.Error, mapping domain errors in ONE place:

func (s *Server) CreatePayment(ctx context.Context, req *pb.CreatePaymentRequest) (*pb.CreatePaymentResponse, error) {
    p, err := s.svc.Create(ctx, toDomain(req))
    if err != nil {
        return nil, toStatus(err)
    }
    return &pb.CreatePaymentResponse{Payment: fromDomain(p)}, nil
}

func toStatus(err error) error {
    switch {
    case errors.Is(err, domain.ErrNotFound):
        return status.Error(codes.NotFound, "payment not found")
    case errors.Is(err, domain.ErrDuplicate):
        return status.Error(codes.AlreadyExists, "payment already exists")
    case errors.Is(err, context.DeadlineExceeded):
        return status.Error(codes.DeadlineExceeded, "timed out")
    default:
        return status.Error(codes.Internal, "internal error") // no details leak
    }
}

Code semantics that matter: InvalidArgument (bad request regardless of state), FailedPrecondition (bad state), NotFound, AlreadyExists, Unauthenticated vs PermissionDenied, Unavailable (retryable), Internal (bug). Clients read codes with status.FromError(err) — never parse messages.

3. Deadlines Are Mandatory

// Client — every call gets a deadline
ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
defer cancel()
resp, err := client.CreatePayment(ctx, req)

// Server — check before expensive work
if err := ctx.Err(); err != nil {
    return nil, status.FromContextError(err).Err()
}

The server inherits the client's deadline through the context. Pass ctx into every downstream call (DB, other RPCs) so cancellation propagates end to end.

4. Interceptors for Cross-Cutting Concerns

Handlers stay business-only; recovery, auth, logging, metrics live in interceptors:

srv := grpc.NewServer(
    grpc.ChainUnaryInterceptor(
        recoveryInterceptor,   // outermost: panic → codes.Internal
        loggingInterceptor,
        authInterceptor,
    ),
)

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

Order matters: recovery first (outermost), then observability, then auth. Streaming RPCs need the parallel StreamInterceptor versions.

5. Streaming

  • Server streaming for large result sets: stream.Send in a loop, return non-nil error to abort with a status.
  • Client/bidi streaming only when the protocol truly needs it — each open stream holds a goroutine and flow-control state.
  • Always terminate on ctx.Done():
func (s *Server) WatchPayments(req *pb.WatchRequest, stream pb.PaymentService_WatchPaymentsServer) error {
    for {
        select {
        case <-stream.Context().Done():
            return status.FromContextError(stream.Context().Err()).Err()
        case ev := <-s.events:
            if err := stream.Send(toProto(ev)); err != nil {
                return err
            }
        }
    }
}

6. Production Server Setup

lis, err := net.Listen("tcp", cfg.Addr)
if err != nil {
    return fmt.Errorf("listen: %w", err)
}

srv := grpc.NewServer(grpc.ChainUnaryInterceptor(...))
pb.RegisterPaymentServiceServer(srv, server)

healthSrv := health.NewServer() // grpc.health.v1 — load balancers need it
healthpb.RegisterHealthServer(srv, healthSrv)
reflection.Register(srv)        // grpcurl/debugging; gate on non-prod if policy requires

go func() {
    <-ctx.Done()
    stopped := make(chan struct{})
    go func() { srv.GracefulStop(); close(stopped) }()
    select {
    case <-stopped:                 // in-flight RPCs finished
    case <-time.After(10 * time.Second):
        srv.Stop()                  // force after grace period
    }
}()

return srv.Serve(lis)

Verification Checklist

  1. Proto packages versioned (*.v1); no tag reuse; reserved for removals
  2. Dedicated Request/Response message per RPC
  3. Generated code produced by a pinned tool (buf/protoc) and committed
  4. All handler errors are status.Error with semantically correct codes
  5. codes.Internal responses never leak internal error text
  6. Every client call has a deadline; ctx propagated through all layers
  7. Recovery, logging, auth implemented as chained interceptors (unary + stream)
  8. Streams select on stream.Context().Done()
  9. Health service registered; graceful stop with forced fallback
  10. grpcurl smoke test (or generated client test) passes against the running server

GitHub Repository

eduardo-sl/go-agent-skills
Path: skills/(architecture)/go-grpc
0
FAQ

Frequently asked questions

What is the go-grpc skill?

go-grpc is a Claude Skill by eduardo-sl. Skills package instructions and resources that Claude loads on demand, so Claude can perform go-grpc-related tasks without extra prompting.

How do I install go-grpc?

Use the install commands on this page: add go-grpc to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.

What category does go-grpc belong to?

go-grpc is in the Design category, tagged ai, api, and design.

Is go-grpc free to use?

Yes. go-grpc is listed on AIMCP and free to install.

Related Skills

executing-plans
Design

Use the executing-plans skill when you have a complete implementation plan to execute in controlled batches with review checkpoints. It loads and critically reviews the plan, then executes tasks in small batches (default 3 tasks) while reporting progress between each batch for architect review. This ensures systematic implementation with built-in quality control checkpoints.

View skill
requesting-code-review
Design

This skill dispatches a code-reviewer subagent to analyze code changes against requirements before proceeding. It should be used after completing tasks, implementing major features, or before merging to main. The review helps catch issues early by comparing the current implementation with the original plan.

View skill
connect-mcp-server
Design

This skill provides a comprehensive guide for developers to connect MCP servers to Claude Code using HTTP, stdio, or SSE transports. It covers installation, configuration, authentication, and security for integrating external services like GitHub, Notion, and custom APIs. Use it when setting up MCP integrations, configuring external tools, or working with Claude's Model Context Protocol.

View skill
web-cli-teleport
Design

This skill helps developers choose between Claude Code Web and CLI interfaces based on task analysis, then enables seamless session teleportation between these environments. It optimizes workflow by managing session state and context when switching between web, CLI, or mobile. Use it for complex projects requiring different tools at various stages.

View skill