5 ms·
1. Are they easier to use than JSON? 2. Is it just putting strings into a big array? 3. Do you have an examples of them being used?
by wzvici 4y ago
1. Are they easier to use than JSON?
2. Is it just putting strings into a big array?
3. Do you have an examples of them being used?
- politician 4y ago1. It's not easier to use them than JSON when just getting started. However, the pay off is the strong typing and zero-copy access that they offer to folks that need to support clients on multiple architectures. 2. No, writers can directly embed structs and primitive data types into binary buffers at runtime through an API generated from an IDL file. Readers use direct memory access to pull values out of the buffers. If you set it up right, this can result in a massive perf boost by eliminating the encoding and decoding steps. 3. Facebook uses them in their mobile app. Another commenter mentioned use of the in the Arrow format. The flatbuffers website isn't the best, but clearly documents the flatbuffers IDL.
- wzvici 4y agoIs there any good writeup about using them that is easy to follow? With drawbacks on using them in prod?
- politician 4y agoThe google documentation has a minimal tutorial. There are implementations for all of the major languages. The level of documentation in the ecosystem, though, is poor. My best recommendation for you is to jump in and get the tutorial/hello world example working in a language you're comfortable with. They aren't hard to use, but they aren't the easiest thing either. Once you get the gist of the API through the tutorial, the other important topics that come up immediately are version control; git repo design; headers and framing. In production, they've been bulletproof. As long as you account for the compile time issues (schema versioning, repo, headers and framing, etc.).
- ardit33 4y agoWe were using protobufs at Spotify and ditched them for simple JSON calls on the client side. No one complained, and never going back to having anything like that on the client side if I can. Just too many drawbacks. For server to server, they might be fine, but to client just stick with JSON. (which when compressed is pretty efficient).
- wzvici 4y agoWhy is it bad in server to client?
- pphysch 4y agoSetting up TLS in gRPC is annoying if the alternative is using an already-existing HTTPS endpoint.
- anuragsoni 4y agoThat sounds like a problem with GRPC not protobufs.
- boardwaalk 4y agoHow is it annoying? To be fair, we’re fronting our gRPC service with a AWS LB that terminates TLS (so our gRPC is plaintext), so we don’t deal with certs as direct dependencies of our server.
- cmrdporcupine 4y agoBeing able to debug through a simple curl or browser devtools is golden. Also browser has JSON parsing built in. Less dependencies. Easier tooling overall. In my experience people overuse protobuf. But I also worked at Google, where it's the hammer in constant search of any nail it can find. At the very least, endpoints should provide the option to provide a JSON form through content representation negotiation.
- franciscop 4y ago