Yes! its amazing, it really should be the default people reach for. Vast majority of people dont need or want the complexity of grpc, they just want protos.
The one really annoying decision in GRPC's design is tying it to HTTP/2 without an official choice. It optimizes for complicated high-throughput and bidirectional cases, while making it slightly harder to use for simple one-at-a-time "client server unary" RPC calls.
Please don't add to the confusion around the term REST. These days most people just mean they use the GET/POST/PUT/DELETE verbs specifically, which is just using the HTTP protocol itself, no REST about it.
I have experience doing so with .NET simply because writing RPC / Contract definition in a .proto file once and then having gRPC tooling generate all boilerplate associated with it is much better than dealing with existing OpenAPI generators - this one slots right into .csproj where you just add a package reference and a reference to .proto file and you are ready to go.
yes! Twirp - last two companies ive worked at have used it to great success. Protos over plain ol http, without all the weird bespoke network stuff of gRPC. We just use regular dns, loadbalancers, etc etc. It should be way more popular IMHO.
I've done this in a lot of projects -- it works great. Protobuf is nice in a lot of ways and pretty simple, while gRPC is overkill (imo) for a simple web server that doesn't see tons of traffic.
We use it in a client-facing application to keep state of a complex configuration, primarily as a means of having a URL-safe way to encode that configuration. It works great, very happy with it.
Yeah protobuf is a good IDL and encoding. Unfortunately gRPC makes some choices that make sense for internal RPCs in a large engineering org, but it's not good for external clients IMO.
Comments
Yes, I wonder if anyone uses Protobuf encoded payloads over plain old HTTP REST calls.
I've used Twitch's Twirp before and it does that. It is a great middleground between gRPC and plain-HTTP services. :)
https://github.com/twitchtv/twirp
Yes! its amazing, it really should be the default people reach for. Vast majority of people dont need or want the complexity of grpc, they just want protos.
We do flatbuffers (super similar) over websockets/http rest. Works beautifully. gRPC is the culprit here.
Yeah we stream a bunch of telemetry and GPS/attitude data in protobufs over a websocket and it works beautifully.
The Connect RPC protocol is pretty much that: https://connectrpc.com/docs/protocol
The one really annoying decision in GRPC's design is tying it to HTTP/2 without an official choice. It optimizes for complicated high-throughput and bidirectional cases, while making it slightly harder to use for simple one-at-a-time "client server unary" RPC calls.
Please don't add to the confusion around the term REST. These days most people just mean they use the GET/POST/PUT/DELETE verbs specifically, which is just using the HTTP protocol itself, no REST about it.
https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
I have experience doing so with .NET simply because writing RPC / Contract definition in a .proto file once and then having gRPC tooling generate all boilerplate associated with it is much better than dealing with existing OpenAPI generators - this one slots right into .csproj where you just add a package reference and a reference to .proto file and you are ready to go.
Technically Kubernetes does: https://kubernetes.io/docs/reference/using-api/api-concepts/...
yes! Twirp - last two companies ive worked at have used it to great success. Protos over plain ol http, without all the weird bespoke network stuff of gRPC. We just use regular dns, loadbalancers, etc etc. It should be way more popular IMHO.
I've done this in a lot of projects -- it works great. Protobuf is nice in a lot of ways and pretty simple, while gRPC is overkill (imo) for a simple web server that doesn't see tons of traffic.
We use it in a client-facing application to keep state of a complex configuration, primarily as a means of having a URL-safe way to encode that configuration. It works great, very happy with it.
Google’s AdX was entirely protobuf, but now they offer json too.
Performance and the promise of seamless type safety?
Yeah protobuf is a good IDL and encoding. Unfortunately gRPC makes some choices that make sense for internal RPCs in a large engineering org, but it's not good for external clients IMO.