3 ms·
As a fan of static typing, the ideas in the blog post do resonate with me. However, one concern I have with this approach over simple JSON, is client size. A J
by losvedir 6y ago
As a fan of static typing, the ideas in the blog post do resonate with me.
However, one concern I have with this approach over simple JSON, is client size. A JSON API can be consumed by the web client natively, basically. Whereas using, e.g., protobuf will require some tooling to digest a .proto file to generate some client side code for you to use. In practice, if you're embedding that in your web app, how large will that be?
- rpdillon 6y agoI've hit this in scripting. I wanted to submit performance metrics from a build script to an analytics service another team was running, but the service only accepted gRPC. This meant the bash script had to somehow pull in the entire protobuf/gRPC stack so it could say "The build on this host for this branch took 12 minutes". I think accessibility from a broad range of environments is a disadvantage of the "protobufs everywhere" approach. I'm one of the few that still believes in dynamic typing though, so I'm probably biased.