Assessed in the 2026-09-07 framework survey (which produced #178 for Taskiq). gRPC is shippable; it is a question of cost and coverage, not of feasibility. Filing so the assessment is not repeated from scratch.
Free-threading is not the obstacle
Recording this because it is the first objection raised and it does not hold. grpcio 1.83.1 publishes 50 wheels and zero free-threaded ones (grpc/grpc#38762 is open), but the free-threaded CI leg in .github/workflows/_checks.yml already installs an explicit extras allowlist and excludes orjson, otl and pyroscope. A grpc extra would be a fourth entry in that list, and free-threaded users would be without a gRPC bootstrapper — exactly the status the pyroscope instrument has today under #171.
ADR-0005 and ADR-0006 are about keeping ft-hostile packages off default paths. A framework extra is not a default path.
What it would actually cost
Tracing is free. opentelemetry-instrumentation-grpc is official contrib (0.65b0, versioned in lockstep with the rest of contrib) and provides both server and client interceptors.
Sentry is free. sentry_sdk.integrations.grpc is first-party.
Prometheus is not. The community options are stale — py-grpc-prometheus last released 2024-02-29, grpc-interceptor 2023-11-16 — so lite-bootstrap would own a hand-written interceptor and its metric names, which is a maintenance commitment no other framework in the matrix carries.
Coverage is 5 of 8. A gRPC server has no HTTP surface, so cors, swagger and health-checks have nothing to bind to. (gRPC's own health-checking protocol is a different thing from HealthChecksInstrument, and mapping one onto the other is its own design question.) Applicable: logging, sentry, opentelemetry, pyroscope, and prometheus subject to the above.
The attach model differs from all five current frameworks. Every supported framework is ASGI or broker-shaped. A grpc.Server is built by grpc.server(...) with its interceptors fixed at construction, so there is no post-construction hook of the kind add_middleware / add_middlewares / add_provider gives elsewhere. Either the bootstrapper takes the interceptor list before the server is built — which breaks the construct-and-hand-over contract — or it takes something other than a server object. That is the real design question and it should be settled before any code.
6 extras, each getting its own venv under install-isolation at a 100% coverage floor.
Note
modern-di-grpc exists in this org, so gRPC is in scope for modern-python generally. That is not by itself an argument for this library, whose matrix cost per framework is much higher.
Assessed in the 2026-09-07 framework survey (which produced #178 for Taskiq). gRPC is shippable; it is a question of cost and coverage, not of feasibility. Filing so the assessment is not repeated from scratch.
Free-threading is not the obstacle
Recording this because it is the first objection raised and it does not hold.
grpcio1.83.1 publishes 50 wheels and zero free-threaded ones (grpc/grpc#38762 is open), but the free-threaded CI leg in.github/workflows/_checks.ymlalready installs an explicit extras allowlist and excludesorjson,otlandpyroscope. Agrpcextra would be a fourth entry in that list, and free-threaded users would be without a gRPC bootstrapper — exactly the status the pyroscope instrument has today under #171.ADR-0005 and ADR-0006 are about keeping ft-hostile packages off default paths. A framework extra is not a default path.
What it would actually cost
Tracing is free.
opentelemetry-instrumentation-grpcis official contrib (0.65b0, versioned in lockstep with the rest of contrib) and provides both server and client interceptors.Sentry is free.
sentry_sdk.integrations.grpcis first-party.Prometheus is not. The community options are stale —
py-grpc-prometheuslast released 2024-02-29,grpc-interceptor2023-11-16 — so lite-bootstrap would own a hand-written interceptor and its metric names, which is a maintenance commitment no other framework in the matrix carries.Coverage is 5 of 8. A gRPC server has no HTTP surface, so cors, swagger and health-checks have nothing to bind to. (gRPC's own health-checking protocol is a different thing from
HealthChecksInstrument, and mapping one onto the other is its own design question.) Applicable: logging, sentry, opentelemetry, pyroscope, and prometheus subject to the above.The attach model differs from all five current frameworks. Every supported framework is ASGI or broker-shaped. A
grpc.Serveris built bygrpc.server(...)with its interceptors fixed at construction, so there is no post-construction hook of the kindadd_middleware/add_middlewares/add_providergives elsewhere. Either the bootstrapper takes the interceptor list before the server is built — which breaks the construct-and-hand-over contract — or it takes something other than a server object. That is the real design question and it should be settled before any code.6 extras, each getting its own venv under
install-isolationat a 100% coverage floor.Note
modern-di-grpcexists in this org, so gRPC is in scope for modern-python generally. That is not by itself an argument for this library, whose matrix cost per framework is much higher.