5 ms·
Why should usual developers use protobuf instead of json? You are just making your life harder If using compression the size is in the same ballpark (protobuf
by arein3 4y ago
Why should usual developers use protobuf instead of json?
You are just making your life harder
If using compression the size is in the same ballpark (protobuf can be between 20% and 50% smaller). For 99% of users it should not make a difference.
https://nilsmagnus.github.io/post/proto-json-sizes/#gzipped-json-and-gzipped-protobuf https://nilsmagnus.github.io/post/proto-json-sizes/#gzipped-...
- dboreham 4y agoTo talk to a server that doesn't speak json.
- arein3 4y agoFor non-niche use cases that is a bad developer experience. If you are designing your own solution that uses protobuf instead of JSON say goodbye to a range of useful tools that the whole industry uses. From testing to automation it will be harder at every step, and you will have to find custom solutions instead of usual no-customization solution that works OOTB with JSON. It is a good way to frustrate your developers and generate sometimes brittle solutions related to testing/automation/infrastructure.
- osigurdson 4y agoIf PB becomes popular enough the tooling will materialize. The only difference is the schema needs to be discovered (somehow) with PB.
- arein3 4y agoI would advise to be pragmatic and not risk. You are using it now, and my experience was worse with protobuf than with JSON.
- osigurdson 4y agoI would advise you not to assume you know what pragmatism means for the problems of others.
- arein3 4y agoFor sure. There's a niche for protobuf. I was advising to be pragmatic regarding the tooling, since that was the context.
- lolinder 4y agoChoosing a technology because you're betting it will become popular and therefore better than it is now is a bad move (except for hobby projects). You should only choose to use a new tech if you will derive enough in its current form to justify the cost. Otherwise you may well end up stuck with technology that you were never happy with and that never hit the popularity thresholds you hoped for.
- endtime 4y agoThat's one of the core problems Buf solves.
- osigurdson 4y agoThe schema isn't part of the message. This is what people are complaining about when comparing it to json. Debugging is harder because it is impossible to know what is in the message without having the proto information available. My suggestion/strawman is to add request/response debug headers that include this in a standardized way. Then tooling can start to pick this up (eventually). The developer experience can then start to approach json.
- lolinder 4y agoThis only makes sense if you have a server that someone else put together that for some reason only speaks protobuf. I'm not aware of any language ecosystem that has protocol buffers but no json support, so if you're building a server from scratch this isn't a good reason to use protobufs. And if you are faced with a server that only speaks protobuf, the same question applies to the original devs: why did they make that decision?
- deleted 4y ago[deleted]
- onion2k 4y agoFor 99% of users it should not make a difference. The link you included shows that protobufs are at least 15% better for all users, and as much as 57% better for cases where the data is small. Doesn't that mean for 100% of users it will actually make a difference? Your users might not care about the difference but it will be there.
- arein3 4y agoUsually when visiting a website, saving a few kilobytes on the client side on requests to backend does not make any difference.
- billions 4y agoAgreed. ProtoBufs slows code iteration velocity tremendously. Saving 100 milliseconds on page load while reducing developer efficiency by 30% = a net worse product for end users.
- jameshart 4y agoA feature that never ships has value for 0% of users. Actually realizing that speed up for your users will take time away from delivering features. Engineering is a trade off, always will be.
- thdespou 4y agoHaha awesome response.
- jtolmar 4y agoYou'd also have to compare this against the download size of the protobuf library itself.
- marcosdumay 4y ago> 57% better for cases where the data is small You don't optimize things for the cases when they are fast. (Unless the gain is a couple of orders of magnitude; certainly not for a 50% speedup.) The 15% gain is the one that matters. On practice, it comes at the expense of a more complex (thus larger, negating some of it) and less reliable system. It is very rare that this trade-off is worth it.
- Thaxll 4y agoJSON/REST does not declare its schema, it's like talking about type vs dynamic typed language.
- arein3 4y agoA subjective opinion, but it's much easier to read some documentation and checking maybe an OpenAPI spec than having to deal with protobuf. You also have solutions like GraphQL that define a schema, or you can publish some kind of schema (a good thing to do) but use JSON instead of a binary format.
- zeroq 4y agoType checking and schema are two different things. Both your application and documentation will assume certain state to be true, but only with type checking you can actually verify if it's correct.
- sa46 4y agoI prefer reading proto files with services over OpenAPI yaml. Here's the pet store example to compare. - https://github.com/project-flogo/grpc/blob/master/proto/grpc2grpc/petstore.proto https://github.com/project-flogo/grpc/blob/master/proto/grpc... - https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/petstore.yaml https://github.com/OAI/OpenAPI-Specification/blob/main/examp...
- morelisp 4y agoProtobuf also does not declare its schema. Message parsers can be generated from a schema, but that's also true for REST over JSON. Even ad hoc REST APIs often have better self-declaration of resource types than protobuf. (I still like protobuf, but the schemas are a terrible reason to like it.)
- tekkk 4y agoI am using it for sending data between game server and client. Encoding the messages in JSON would be just silly, although I wonder what is the standard in the game industry.
- arein3 4y agoYour case is one of those 1% if you have a real time game where a fraction of a second is important.
- depr 4y agoProtocol buffers are used in Dark Souls 3, Pokemon GO, Hearthstone and I'm sure many other games.
- cdelsolar 4y agowe use it at https://woogles.io https://woogles.io for pretty much all communication (server-to-server and client-to-server). I do loathe dealing with the JS aspect of it and am very excited to move over to protocol-es after reading this article (and shaving off a ton of repeated code and generated code).
- ranguna 4y agoMoving to es? Isn't it slower than protobufjs?
- soylentgraham 4y agoLarge blocks of data. (Eg 10,000 floats) Otherwise personally json wins
- cdelsolar 4y agonothing to do with the size, but with having robust schemata.
- arriu 4y agoIt has everything to do with automatic validation on both sides and little to do with the transfer size.
- arein3 4y agoIntroducing a binary format for payload validation is like shooting yourself in the foot because you have an itch.
- arriu 4y agoI disagree, especially if your goal is to reduce the payload size. Another point to consider is that not all programming languages deal well with JSON, adding support for it can be just as painful.
- WorldMaker 4y agoAny programming language you can teach to process protobuf or other binary formats you can teach to process JSON. The hardest part of the JSON spec is UTF-8 support and if your programming language doesn't have strong UTF-8 support in 2022 you have other, presumably larger problems.
- MrJohz 4y agoBut you can do automatic validation fairly easily with JSON Schema. You don't need to choose a binary format to get validation. The principle benefit is that you can use the schema to define the data format, which means you can pack the data in more tightly (you don't need a byte to say "this is an object" if you know that the input data must be an object at this point). That's a big benefit in certain situations, but if you're using this sort of stuff just to get validation then you're probably better off using JSON Schema and having a wire transfer format that you can read easily without additional tools.
- endtime 4y agoprotobuf is much more concise and readable than OAS. You can define API contracts in protobuf and still serve JSON APIs via the standard-ish gRPC/JSON transcoding enabled by google.api annotations.