gRPC-Go Engineering Practices
1–10 of 85 posts
Re: gRPC-Go Engineering Practices
#2Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already.
What is the advantage of gRPC - just more efficient?
Re: gRPC-Go Engineering Practices
#3Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?
Json is a serialization format. gRPC is both a serialization format and a DDL (data definition language).
That means that you are storing your schema, which also happens to contain interoperability features.
...and the serialization format is more efficient.
Re: gRPC-Go Engineering Practices
#4Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?
Versioning your API is one huge benefit and better done using proto/rpc. If you change your Json schema, have fun propagating that change to all clients without fear. Or hope you've built special infra to do that.
Also "just more efficient" is a funny way to characterize the performance difference between just data bytes vs data + structure bytes (read: the gap is large). You gain in transmission and you gain during deserialization / parsing.
Here is an example.
{"My key":"my value"} has n=21 characters. When you parse you must scan the whole 21 characters O(n), every time, just to read the thing.
If you instead store this in fixed size bytes, where you have some fixed # of bytes that tell you "my value starts at address 0x43", then you can skip to just the values you care about. You don't need brackets or quotes. And you can use other nifty tricks to compress the binary representation further for savings on the wire.
Re: gRPC-Go Engineering Practices
#5Great to hear, I'm pretty bullish on the framework and have been using it happily in Go for a while
Re: gRPC-Go Engineering Practices
#6Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?
Biggest benefits I've seen so far. Codegen, streaming connections, API versioning.
Re: gRPC-Go Engineering Practices
#7Does anyone have experience with both gRPC and Thrift? I'd be curious to know how they compare.
Re: gRPC-Go Engineering Practices
#8Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?
re: efficiency, I think this blog post does a decent job explaining: https://auth0.com/blog/beating-json-performance-with-protobu.... Basically, it doesn't make a huge difference if you're communicating with a Javascript endpoint, but Java to Java (or probably between other non-js backends) you can save a lot of time on serialization/deserialization. It's worth noting that the post uses fairly large blobs (50k people and addresses), and you probably won't see as big of a difference on smaller requests.
Re: gRPC-Go Engineering Practices
#9Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?
Afraid I'm going to be contrary and old-fashioned and say I prefer JSON.
Its never been problematic adding or extending JSON endpoints and its never been a problem using basic gzip compression on the fly either.
And JSON endpoints are a damn sight easier to debug and wireshark and all the rest.
I've spent a lot of time writing fast JSON serialization for various languages including Java etc; its staggering how inefficient most libraries are. But that's not really JSON's fault.
Re: gRPC-Go Engineering Practices
#10Is this gRPC the same thing as golang net/rpc referred to here: https://news.ycombinator.com/item?id=16170116? I don't think so but I've never used either one.
>seniorsassycat: I don't understand why AWS released Go support instead of binary support and I don't understand why they chose to rely on go's net/rpc [...] which encodes objects using Go's special [gobs] binary format