Hello, I work on Protocol Buffers at Google.
As part of our overall efforts to reduce tech debt in our code, we would like to remove generic services from our code generator. These have been marked as deprecated since 2010, both in the docs and in several places in the code (descriptor.proto, service.h, service.py, etc.).
We noticed that bRPC is built on generic services. Because these APIs are exposed directly to your users, a sudden removal on our end would cause significant disruption to the bRPC ecosystem. We want to avoid that and work together to manage this transition as smoothly as possible.
To move forward, the sustainable path is for bRPC to transition to its own custom code generator (a protoc plugin) to generate these service APIs, rather than relying on the built-in generic services option in protoc. This is the standard approach modern RPC frameworks (like gRPC) use to generate their stubs.
We want to give your team ample runway to design, implement, and distribute this migration.
- Timeline: We are targeting Q1 2028 to disable the
xx_generic_services options (making them into no-ops). Prior to this, we will begin emitting warnings and possibly require that a special codegen flag be set to continue using generic services.
- Our Support: We are happy to provide guidance on how to structure a custom generator plugin, share references from how other frameworks achieved this, or review migration designs to make this process easier for you.
Please let us know your thoughts on this timeline and how we can best support the Apache bRPC community during this transition.
Hello, I work on Protocol Buffers at Google.
As part of our overall efforts to reduce tech debt in our code, we would like to remove generic services from our code generator. These have been marked as deprecated since 2010, both in the docs and in several places in the code (descriptor.proto, service.h, service.py, etc.).
We noticed that bRPC is built on generic services. Because these APIs are exposed directly to your users, a sudden removal on our end would cause significant disruption to the bRPC ecosystem. We want to avoid that and work together to manage this transition as smoothly as possible.
To move forward, the sustainable path is for bRPC to transition to its own custom code generator (a
protocplugin) to generate these service APIs, rather than relying on the built-in generic services option inprotoc. This is the standard approach modern RPC frameworks (like gRPC) use to generate their stubs.We want to give your team ample runway to design, implement, and distribute this migration.
xx_generic_servicesoptions (making them into no-ops). Prior to this, we will begin emitting warnings and possibly require that a special codegen flag be set to continue using generic services.Please let us know your thoughts on this timeline and how we can best support the Apache bRPC community during this transition.