5 ms·

You'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

You'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 ago
I 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 ago
Did 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 ago
  That was already acknowledged earlier in the thread.
kajecounterhack 9y ago
When 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.

chrissnell 9y ago

I 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 ago

Did 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 ago
That was already acknowledged earlier in the thread.

kajecounterhack 9y ago

When 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.