4 ms·
As a counterpoint to the horror stories, I've had a few relatively good experiences with protocol buffers (not gRPC). On one project, we had messages that neede
by thadt 2y ago
As a counterpoint to the horror stories, I've had a few relatively good experiences with protocol buffers (not gRPC). On one project, we had messages that needed to be used across multiple applications, on a microcontroller, on an SBC running Python, in an Android app, in a web service, and on web UI frontend. Being able to update a message definition in one place, and have it spit out updated code in half a dozen languages while allowing for incremental rollout to the various pieces was very handy.
Sure - it wasn't all guns and roses, but overall it rocked.
- ainar-g 2y agoTo be fair, if that's what you need ProtoBuf isn't the only option. Cap'n Proto[1], JSON Schema[2], or any other well supported message-definition language could probably achieve that as well, each with their own positives and negatives. [1]: https://capnproto.org/ https://capnproto.org/ [2]: https://json-schema.org/ https://json-schema.org/
- palata 2y agoBig fan of Cap'n Proto here, but to be fair it doesn't support as many languages as Protobuf/gRPC yet.
- jviotti 2y agoI'm currently building a Protocol Buffers alternative that uses JSON Schema instead: https://jsonbinpack.sourcemeta.com/ https://jsonbinpack.sourcemeta.com/. It was proven on research to be as or more space-efficient than any considered alternative (https://arxiv.org/abs/2211.12799 https://arxiv.org/abs/2211.12799). However, it is still heavily under development and not ready for production use. Definitely looking for GitHub Sponsors or other type of funding to support it :)
- fullstop 2y agoThis is what I used it for, and it was great. Especially if you were feeding data to a third party and had to agree on an exchange format anyway.