4 ms·
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
by kajecounterhack 9y ago
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.
- weberc2 9y agoI fully agree, but want to point out that JSON can be compressed.
- virmundi 9y agoYou're absolutely right. Auth0 shows that when compressed, protobufs don't provide a great benefit vs JSON. Something I've read from others is that gRPC is not the easiest thing to use directly in SPA. If you have services exposed to a web front end and mobile, double exposing a REST-ish API + gRPC might not be worth it. This is a problem with which I'm currently struggling. https://auth0.com/blog/beating-json-performance-with-protobuf/ https://auth0.com/blog/beating-json-performance-with-protobu...
- chrissnell 9y agoI spoke to some of the gRPC folks at KubeCon/CNCon and the word is that browser support is in the works. There are some existing, slightly hackish ways to do it already but I'm confident that they will get it done properly. It will be huge when that's a reality and we start building all of our APIs around protobuf.
- chickenbane 9y agoDid you not finish the rest of the post? Yes, it's true that compressed json is not materially different in size vs protobufs. But when it comes to the speed of serializing and deserializing protobufs there is a huge gain across languages. So if you're using gRPC in backend environments you'll gain huge speed benefits.
- weberc2 9y agoThat was already acknowledged earlier in the thread.
- kajecounterhack 9y agoWhen compressed sizes can still matter as the payload size increases. REST is the language the rest of the web speaks so if providing a consumer service that isn't latency sensitive you should feel at liberty to give a RESTful API. If you're building internal services, consumed internally, gRPC is a decent way to go. If say you're providing a logging service to a number of large customers you might want to provide a gRPC service for the performance characteristics. gRPC also provides you the option to write all your services internally using gRPC and then you can expose a JSON service without having to write it yourself.
- deleted 9y ago[deleted]
- mpweiher 9y ago> performance difference [..] (read: the gap is large) Hmm...can you quantify that? I found that while these performance difference you mention exist, they are not actually that large and completely dwarfed by actions later in the chain, particularly if you have generic intermediate representations.