grpc

Name: grpc
Author: managedcode

461stars35forks

How to install grpc?

managedcode/dotnet-skills/grpc

$npx -y skills add managedcode/dotnet-skills --skill grpc

Installs into the current project.

Summary

Build or review gRPC services and clients in .NET. USE FOR: ASP.NET Core gRPC, protobuf contracts, unary or streaming RPC, gRPC client factory, interceptors, deadlines, cancellation, channel reuse, backend service integration. DO NOT USE FOR: broad browser-facing APIs without gRP

Files · 1

View on GitHub

SKILL.md

1	# gRPC for .NET
2
3	## Trigger On
4
5	- building backend-to-backend RPC services or clients
6	- adding protobuf contracts, streaming calls, or interceptors
7	- deciding between gRPC, HTTP APIs, and SignalR
8	- optimizing gRPC performance, deadlines, cancellation, or connection reuse
9	- integrating service-to-service communication in microservices
10
11	## Do Not Use For
12
13	- public browser-first APIs unless gRPC-Web limitations are explicitly acceptable
14	- SignalR hub design, realtime UI fan-out, or websocket-style client collaboration
15	- generic ASP.NET Core minimal APIs or REST controllers with no protobuf/RPC requirement
16	- non-.NET gRPC work unless the user asks for cross-stack contract guidance
17
18	## Load References
19
20	- [references/patterns.md](references/patterns.md) for proto design, streaming implementations, interceptors, health checks, load balancing, and client factory setup.
21	- [references/anti-patterns.md](references/anti-patterns.md) for common channel, deadline, streaming, message-size, and exception-handling mistakes.
22
23	## Workflow
24
25	1. Validate the architecture fit before touching code.
26	- prefer gRPC for backend RPC, strong contracts, low-latency calls, or streaming
27	- prefer REST or minimal APIs for broad browser compatibility and loosely coupled public APIs
28	- prefer SignalR for browser/client realtime fan-out and UI collaboration
29	2. Treat `.proto` files as the source of truth.
30	- keep package names, `csharp_namespace`, service names, and versioning deliberate
31	- reserve removed field numbers and avoid reusing tags
32	- use wrapper types or explicit messages when optionality matters
33	3. Choose the RPC shape from the interaction model.
34	- unary for request/response
35	- server streaming for large or progressive result sets
36	- client streaming for uploads or batches
37	- bidirectional streaming for coordinated two-way flows
38	4. Wire server and client behavior together.
39	- register services with `AddGrpc`
40	- use `AddGrpcClient` or long-lived `GrpcChannel` reuse
41	- set deadlines and propagate cancellation
42	- convert domain failures to appropriate `RpcException` status codes
43	5. Add observability and resilience where the boundary justifies it.
44	- logging or exception interceptors
45	- OpenTelemetry traces and status-code metrics
46	- retry policy only for safe idempotent calls
47	6. Validate with the repo's normal build and tests, plus a focused smoke call when runnable.
48
49	## Current Upstream Notes
50
51	- `dotnet/aspnetcore` `v10.0.10` is servicing and does not change the gRPC programming model. Keep guidance focused on proto compatibility, streaming shape, deadlines, cancellation, channel reuse, and smoke calls.
52	- The July 2026 ASP.NET Core overview still treats gRPC as a contract-first RPC option. After package servicing updates, regenerate protobuf outputs only when inputs or generator packages actually changed; do not churn generated files as a proxy for validation.
53
54	```mermaid
55	flowchart LR
56	A["RPC requirement"] --> B["proto contract"]
57	B --> C["server implementation"]
58	B --> D["client factory or channel"]
59	C --> E["deadlines / cancellation / status codes"]
60	D --> E
61	E --> F["build, tests, smoke call"]
62	```
63
64	## Examples
65
66	Use client factory for normal app integration:
67
68	```csharp
69	builder.Services.AddGrpcClient<Greeter.GreeterClient>(options =>
70	{
71	options.Address = new Uri("https://localhost:5001");
72	});
73	```
74
75	Always set a deadline and pass cancellation:
76
77	```csharp
78	var response = await client.SayHelloAsync(
79	new HelloRequest { Name = name },
80	deadline: DateTime.UtcNow.AddSeconds(5),
81	cancellationToken: cancellationToken);
82	```
83
84	For streaming, check cancellation inside the read/write loop and keep message sizes bounded. Load [references/patterns.md](references/patterns.md) before writing detailed streaming code.
85
86	## Anti-Patterns
87
88	- creating a new `GrpcChannel` per call
89	- omitting deadlines and relying only on client-side cancellation
90	- ignoring `ServerCallContext.CancellationToken` in streaming handlers
91	- sending large single messages instead of chunking or streaming
92	- using gRPC as the default public browser API
93	- swallowing exceptions inside interceptors
94	- retrying non-idempotent calls without explicit policy
95
96	## Deliver
97
98	- stable protobuf contracts and generated-code ownership
99	- service and client code that match the RPC shape
100	- explicit deadline, cancellation, retry, and status-code behavior
101	- tests or smoke checks for serialization and call behavior
102	- documentati

People who liked this also viewed

6 picks

Type

grpc

461stars35forks

View on GitHub

How to install grpc?

managedcode/dotnet-skills/grpc

$npx -y skills add managedcode/dotnet-skills --skill grpc

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# gRPC for .NET
2
3	## Trigger On
4
5	- building backend-to-backend RPC services or clients
6	- adding protobuf contracts, streaming calls, or interceptors
7	- deciding between gRPC, HTTP APIs, and SignalR
8	- optimizing gRPC performance, deadlines, cancellation, or connection reuse
9	- integrating service-to-service communication in microservices
10
11	## Do Not Use For
12
13	- public browser-first APIs unless gRPC-Web limitations are explicitly acceptable
14	- SignalR hub design, realtime UI fan-out, or websocket-style client collaboration
15	- generic ASP.NET Core minimal APIs or REST controllers with no protobuf/RPC requirement
16	- non-.NET gRPC work unless the user asks for cross-stack contract guidance
17
18	## Load References
19
20	- [references/patterns.md](references/patterns.md) for proto design, streaming implementations, interceptors, health checks, load balancing, and client factory setup.
21	- [references/anti-patterns.md](references/anti-patterns.md) for common channel, deadline, streaming, message-size, and exception-handling mistakes.
22
23	## Workflow
24
25	1. Validate the architecture fit before touching code.
26	- prefer gRPC for backend RPC, strong contracts, low-latency calls, or streaming
27	- prefer REST or minimal APIs for broad browser compatibility and loosely coupled public APIs
28	- prefer SignalR for browser/client realtime fan-out and UI collaboration
29	2. Treat `.proto` files as the source of truth.
30	- keep package names, `csharp_namespace`, service names, and versioning deliberate
31	- reserve removed field numbers and avoid reusing tags
32	- use wrapper types or explicit messages when optionality matters
33	3. Choose the RPC shape from the interaction model.
34	- unary for request/response
35	- server streaming for large or progressive result sets
36	- client streaming for uploads or batches
37	- bidirectional streaming for coordinated two-way flows
38	4. Wire server and client behavior together.
39	- register services with `AddGrpc`
40	- use `AddGrpcClient` or long-lived `GrpcChannel` reuse
41	- set deadlines and propagate cancellation
42	- convert domain failures to appropriate `RpcException` status codes
43	5. Add observability and resilience where the boundary justifies it.
44	- logging or exception interceptors
45	- OpenTelemetry traces and status-code metrics
46	- retry policy only for safe idempotent calls
47	6. Validate with the repo's normal build and tests, plus a focused smoke call when runnable.
48
49	## Current Upstream Notes
50
51	- `dotnet/aspnetcore` `v10.0.10` is servicing and does not change the gRPC programming model. Keep guidance focused on proto compatibility, streaming shape, deadlines, cancellation, channel reuse, and smoke calls.
52	- The July 2026 ASP.NET Core overview still treats gRPC as a contract-first RPC option. After package servicing updates, regenerate protobuf outputs only when inputs or generator packages actually changed; do not churn generated files as a proxy for validation.
53
54	```mermaid
55	flowchart LR
56	A["RPC requirement"] --> B["proto contract"]
57	B --> C["server implementation"]
58	B --> D["client factory or channel"]
59	C --> E["deadlines / cancellation / status codes"]
60	D --> E
61	E --> F["build, tests, smoke call"]
62	```
63
64	## Examples
65
66	Use client factory for normal app integration:
67
68	```csharp
69	builder.Services.AddGrpcClient<Greeter.GreeterClient>(options =>
70	{
71	options.Address = new Uri("https://localhost:5001");
72	});
73	```
74
75	Always set a deadline and pass cancellation:
76
77	```csharp
78	var response = await client.SayHelloAsync(
79	new HelloRequest { Name = name },
80	deadline: DateTime.UtcNow.AddSeconds(5),
81	cancellationToken: cancellationToken);
82	```
83
84	For streaming, check cancellation inside the read/write loop and keep message sizes bounded. Load [references/patterns.md](references/patterns.md) before writing detailed streaming code.
85
86	## Anti-Patterns
87
88	- creating a new `GrpcChannel` per call
89	- omitting deadlines and relying only on client-side cancellation
90	- ignoring `ServerCallContext.CancellationToken` in streaming handlers
91	- sending large single messages instead of chunking or streaming
92	- using gRPC as the default public browser API
93	- swallowing exceptions inside interceptors
94	- retrying non-idempotent calls without explicit policy
95
96	## Deliver
97
98	- stable protobuf contracts and generated-code ownership
99	- service and client code that match the RPC shape
100	- explicit deadline, cancellation, retry, and status-code behavior
101	- tests or smoke checks for serialization and call behavior
102	- documentati

People who liked this also viewed

6 picks

Type