SKILL·174A7D

go-grpc

eduardo-sl
Aktualisiert 27 days ago
5 Ansichten
70
9
70
Auf GitHub ansehen
Designaiapidesign

Über

Dieses Claude Skill bietet fortgeschrittene Anleitung zur Implementierung von produktionsreifen gRPC-Diensten in Go. Es behandelt Proto-Design, Fehlerbehandlung, Interceptoren, Streaming, Deadlines, Health Checks und Graceful Shutdown. Verwenden Sie es speziell für die Implementierung von gRPC-Diensten, nicht für REST-APIs, allgemeine Architektur oder Sicherheitshärtung.

Schnellinstallation

Claude Code

Empfohlen
Primär
npx skills add eduardo-sl/go-agent-skills -a claude-code
Plugin-BefehlAlternativ
/plugin add https://github.com/eduardo-sl/go-agent-skills
Git CloneAlternativ
git clone https://github.com/eduardo-sl/go-agent-skills.git ~/.claude/skills/go-grpc

Kopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um diese Fähigkeit zu installieren

Dokumentation

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
Pfad: skills/(architecture)/go-grpc
0
FAQ

Häufig gestellte Fragen

Was ist der Skill go-grpc?

go-grpc ist ein Claude Skill von eduardo-sl. Skills bündeln Anweisungen und Ressourcen, die Claude bei Bedarf lädt, um Aufgaben rund um go-grpc ohne zusätzliche Eingaben auszuführen.

Wie installiere ich go-grpc?

Verwende die Installationsbefehle auf dieser Seite: Füge go-grpc als Plugin zu Claude Code hinzu oder klone das Repository in dein Skills-Verzeichnis. Starte Claude danach neu, damit der Skill geladen wird.

Zu welcher Kategorie gehört go-grpc?

go-grpc gehört zur Kategorie Design.

Kann ich go-grpc kostenlos nutzen?

Ja. go-grpc ist auf AIMCP gelistet und kann kostenlos installiert werden.

Verwandte Skills

executing-plans
Design

Verwenden Sie die Fähigkeit "executing-plans", wenn Sie einen vollständigen Implementierungsplan zur Ausführung in kontrollierten Batches mit Überprüfungspunkten vorliegen haben. Sie lädt den Plan und überprüft ihn kritisch, führt dann Aufgaben in kleinen Batches (standardmäßig 3 Aufgaben) aus und meldet den Fortschritt zwischen jedem Batch zur Überprüfung durch den Architekten. Dies gewährleistet eine systematische Implementierung mit integrierten Qualitätskontrollpunkten.

Skill ansehen
requesting-code-review
Design

Diese Fähigkeit sendet einen Unteragenten für Code-Review, um Codeänderungen anhand der Anforderungen zu analysieren, bevor fortgefahren wird. Sie sollte nach dem Abschließen von Aufgaben, der Implementierung größerer Funktionen oder vor dem Zusammenführen in den Hauptzweig verwendet werden. Die Überprüfung hilft dabei, Probleme frühzeitig zu erkennen, indem die aktuelle Implementierung mit dem ursprünglichen Plan verglichen wird.

Skill ansehen
connect-mcp-server
Design

Diese Fähigkeit bietet Entwicklern eine umfassende Anleitung, um MCP-Server über HTTP-, stdio- oder SSE-Transports mit Claude Code zu verbinden. Sie behandelt Installation, Konfiguration, Authentifizierung und Sicherheit für die Integration externer Dienste wie GitHub, Notion und benutzerdefinierter APIs. Nutzen Sie sie beim Einrichten von MCP-Integrationen, bei der Konfiguration externer Tools oder bei der Arbeit mit Claude's Model Context Protocol.

Skill ansehen
web-cli-teleport
Design

Diese Fähigkeit unterstützt Entwickler bei der Wahl zwischen Claude Code Web- und CLI-Schnittstellen basierend auf Aufgabenanalysen und ermöglicht nahtloses Session-Teleporting zwischen diesen Umgebungen. Sie optimiert den Workflow, indem sie den Sitzungsstatus und Kontext beim Wechsel zwischen Web, CLI oder Mobilgeräten verwaltet. Nutzen Sie sie für komplexe Projekte, die in verschiedenen Phasen unterschiedliche Werkzeuge erfordern.

Skill ansehen