I like the idea of grpc because I wanted the contract but I tried it on a small service and I think I would avoid it in the future. Too many rough edges and features I didnt really need. I was using it in Rust and python mainly (maybe it is better in Go?) but it had a whole bunch of google stuff in there I didnt need.
- Configuring the python client with a json string that did not seem to have a documented schema
- Error types that were overly general in some ways and overly specific in other ways
- HAProxy couldn't easily health check the service
There were a few others that I cant remember because it was ~5 years ago. I liked the idea of the contract and protobuf seemed easy to write but had no need for client side dns load balancing and the like and was not working in GoLang.
> - Configuring the python client with a json string that did not seem to have a documented schema
I'm far from an expert, yet I came to believe that what you've described is basically "code smell". And the smell probably comes from seemingly innocuous things like enum's.
And you wondered if the solution was using Go, but no, it isn't. I was actually Go at the time myself (this was a few years ago, and I used Twirp instead of Protobuf) - but I realised that RDBMS > "Server(Go)" layer had quirks, and then the "Server(Go)" > "API(JS)" had other quirks -- and so I realised that you may as well "splat" out every attribute/relationship. Because ultimately, that's the problem...
Eg: is it a null field, or undefined, or empty, or false, or [], or {}? ...
For those situations where you need just a little bit of protobuf in your project, and don't want to bother with the whole proto ecosystem of codegen and deps:
https://github.com/allanrbo/pb.py
gRPC/protobuf is largely a Google cult. I've seen too projects with complex business logic simply give up and embed JSON strings inside pb. Like WTF...?
Everything was good in the begining, as long as everyone submits their .proto to a centralized repo. Once the one team starts to host their own, things get broken quickly.
As it occured to me, gRPC could optionally just serve those .proto files in the initial h2 handshake on the wire. It add just few kilobytes but solves a big problem.
Protobuf is good, but it's not perfect. The handling of "oneof" fields is weird and the Python bindings were written by drunk squirrels, enums are strange, etc.
gRPC is terrible, but ConnectRPC allows sane integration of PB with regular browser clients. Buf.build also has a lot of helpful tools, like backwards compatibility checking.
But it's not worse than other alternatives like Thrift. And waaaaaaaaaayyyyyy better than OpenAPI monstrosities.
My gripe with grpc is that it doesn’t play super well with kubernetes services… you have to take a little bit of care, you need to understand how k8s services work and you have to understand how load balancing in grpc works. Ideally I would want to use protobuf as an interchange format, and a “dumb” http server that understands that.
That being said… once you do configure it properly it can be a powerful tool. The complexity though is usually not worth it unless you’re at a certain scale.
I’m old enough to remember the days of CORBA (Orbix, Iona, BEA, anyone ??) and its IDL, the IDL compiler, stubs and other props and doodads. Ah yes, and the registry as well, where the services registered themselves, and the discovery mechanisms.
gRPC (a very Googly thing) took it all, hook line and sinker and made it URLesque
Can’t recall how the ORB overhead has been resolved in gRPCs
7 comments
[ 3.3 ms ] story [ 30.0 ms ] thread- Configuring the python client with a json string that did not seem to have a documented schema
- Error types that were overly general in some ways and overly specific in other ways
- HAProxy couldn't easily health check the service
There were a few others that I cant remember because it was ~5 years ago. I liked the idea of the contract and protobuf seemed easy to write but had no need for client side dns load balancing and the like and was not working in GoLang.
I'm far from an expert, yet I came to believe that what you've described is basically "code smell". And the smell probably comes from seemingly innocuous things like enum's.
And you wondered if the solution was using Go, but no, it isn't. I was actually Go at the time myself (this was a few years ago, and I used Twirp instead of Protobuf) - but I realised that RDBMS > "Server(Go)" layer had quirks, and then the "Server(Go)" > "API(JS)" had other quirks -- and so I realised that you may as well "splat" out every attribute/relationship. Because ultimately, that's the problem...
Eg: is it a null field, or undefined, or empty, or false, or [], or {}? ...
[] == my valentines day inbox. :P
gRPC/protobuf is largely a Google cult. I've seen too projects with complex business logic simply give up and embed JSON strings inside pb. Like WTF...?
Everything was good in the begining, as long as everyone submits their .proto to a centralized repo. Once the one team starts to host their own, things get broken quickly.
As it occured to me, gRPC could optionally just serve those .proto files in the initial h2 handshake on the wire. It add just few kilobytes but solves a big problem.
gRPC is terrible, but ConnectRPC allows sane integration of PB with regular browser clients. Buf.build also has a lot of helpful tools, like backwards compatibility checking.
But it's not worse than other alternatives like Thrift. And waaaaaaaaaayyyyyy better than OpenAPI monstrosities.
That being said… once you do configure it properly it can be a powerful tool. The complexity though is usually not worth it unless you’re at a certain scale.
gRPC (a very Googly thing) took it all, hook line and sinker and made it URLesque
Can’t recall how the ORB overhead has been resolved in gRPCs