In the world of microservices, gRPC has become synonymous with efficient communication. Yet, despite its popularity, a myriad of complaints have surfaced from developers who find working with gRPC less than ideal. From Python and JSON configurations to convoluted source code, the concerns point to deeper issues. One comment noted the frustrating task of passing JSON strings to the Python library to configure services, a sentiment echoed by Java developers. This requirement for indirect and seemingly opaque configurations can disrupt the workflow, making developers question if gRPC is worth the trouble.
The criticism doesn’t end there. Reading the source code for gRPC Java has been described as a Herculean task due to the immense indirection. Developers expecting straightforward answers find themselves lost in a maze of undocumented territory. A notable observation pointed out how Google’s own Golang libraries stand as a testament to readable code, stirring disappointment that gRPC Java couldn’t follow suit. This is significant because well-documented, accessible source code can considerably ease the learning curve, especially for those looking to implement or debug services.
Auto-generated code is another contentious topic. Frequent complaints arise about the unreadable nature of gRPC-generated code, which some developers liken to a ‘quagmire of pain and confusion’. Unlike Sass or LESS, which produce relatively readable output, gRPC’s auto-generation can render even simple tasks convoluted. While Google isn’t the only player in this space, the expectation for high-quality auto-generated code remains unmet, frustrating developers who must wade through layers of abstraction to achieve their functional goals.
Compounding these issues, gRPC’s integration with C++ is no less problematic. Varied experiences with the complexities of Protobuf in Java, with its deep legacy support, intense benchmarking, and immutable message builders, yield mixed reactions. For some, the Java bindings are a blessing, offering thoughtful design and a smooth abstraction layer with service bindings. Yet, for others, the generated C++ interfaces are plagued with unnecessary complications, reflecting a culture criticized for its inability to simplify complex code.
Moreover, developers have pointed out that Google internally doesn’t rely heavily on gRPC. Many find this indicative of gRPC’s limitations, as Google uses internally developed alternatives that apparently offer better support. This revelation deters confidence in gRPC as a viable solution, prompting developers to explore alternatives like JSON with WebSockets or newer ecosystems like buf and ConnectRPC. If gRPC aims to regain its ground, addressing these substantial tooling and internal support deficiencies will be paramount.
Leave a Reply