Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I stopped using JSON for my APIs

aloisdeniel.com

Post reply on HN
Print view View original

121–130 of 245 posts

Re: Why I stopped using JSON for my APIs

#121

Post by mb7733 »

coffeeaddict1 wrote: post #59

> protobuf As an aside, like all things Google, their C++ library is massive (14mb dll) and painful to build (takes nearly 10 minutes on my laptop).

Yeah and (1) the codegen produces massive headers that slow compilation of anything that touches them (2) the generated classes are really awkward to use. Not a big fan of the experience of protobuffer generated code in a large C++ code base.

It's lead to a huge layer of adapters and native c++ classes equivalent to the protobuffers classes to try and mitigate these issues.

Re: Why I stopped using JSON for my APIs

#122

Post by themafia »

duped wrote: post #85
barremian wrote: post #56

Earlier quoted context omitted.

> When judging which alternative will succeed, lower perceived human cost beats lower machine cost every time. Yup this is it. No architect considers using protos unless there is an explicit need for it. And the explicit need is most times using gRPC. Unless the alternative allows for zero cost startup and debugging by just doing `console.log()`, they won't replace JSON any time soon. Edit: Just for context, I'm not…

Print debugging is fine and all but I find that it pays massive dividends to learn how to use a debugger and actually inspect the values in scope rather than guessing which are worth printing. It also is useless when you need to debug a currently running system and can't change the code. And since you need to translate it anyway, there's not much benefit in my mind to using something like msgpack which is more compac…

> rather than guessing

I'm not guessing. I'm using my knowledge of the program and the error together to decide what to print. I never find the process laborious and I almost always get the right set of variables in the first debug run.

The only time I use a debugger is when working on someone else's code.

Re: Why I stopped using JSON for my APIs

#123

Post by ablob »

peterkelly wrote: post #105
ablob wrote: post #102

Earlier quoted context omitted.

I feel like that's fine since both things go hand in hand anyway. And if choosing the JSON-format comes with a rather high amount of contract-breaches it might just be easier to switch that instead of fixing the contract.

Unless a violation of that contract can lead to a crash or security vulnerability...

The post is about changing the serialization-format so enforcing contracts becomes esier; and I am defending the post, so I don't understand what you're hinting at here.

Re: Why I stopped using JSON for my APIs

#124

Post by davedx »

"Ultra-efficient"

Searched the article, no mention of gzip, and how most of the time all that text data (html, js and css too!) you're sending over the wire will be automatically compressed to...... an efficient binary format!

So really, the author should compare protobufs to gzipped JSON

Re: Why I stopped using JSON for my APIs

#125

Post by themafia »

theamk wrote: post #81
brabel wrote: post #15

Mandatory comment about ASN.1, a protocol from 1984, already did what Protobuf does, with more flexibility. Yes, it's a bit ugly but if you stick to the DER encoding it's really not worse than Protbuf at all. Check out the Wikipedia example: https://en.wikipedia.org/wiki/ASN.1#Example_encoded_in_DER Protobuf is ok but if you actually look at how the serializers work, it's just too complex for what it achieves.

ASN.1 has too much stuff. The moment you write "I made ASN.1 decoder/encoder", someone will throw TeletexString or BMPString at it. Or inheritance, as morshu9001 sad. So at this point: - You can support all those features, and your ASM.1 library will be horribly bloated and over-engineered. - You can support your favorite subset, but then you cannot say it's ASN.1 anymore. It will be "ASN.brabel", which only has one…

> someone will throw TeletexString or BMPString

ASCII with escapes and UCS-2.

> horribly bloated and over-engineered.

It's no more or less complicated than XML, JSON or CSV. Which is why you can use ASN.1 to serialize to and from all these formats. ASN.1 provides you an additional level of schema above these. It simply allows you to describe your problem.

I find ASN.1 far more sane and useful than something like JSON Schema which is just as "bloated and over-engineered." It turns out describing data is not a simple problem.

Re: Why I stopped using JSON for my APIs

#126

Post by sergiotapia »

Personally, I looked into protobuf for our Elixir/React Native wombocombo but the second I realized we would have to deploy app updates when we added or removed a field from the response structure it became a non-starter.

I can't imagine using protobuf when you're in the first 5 years of a product.

Re: Why I stopped using JSON for my APIs

#127

Post by gethly »

Reading the first few paragraphs and immediately seeing PB made me instantly think of "Every master was once a beginner.".

When you'll go through your own journey, and inevitably end back with json, do write another blog post :) ... we've all been there.

Re: Why I stopped using JSON for my APIs

#128

Post by chillfox »

davedx wrote: post #124

"Ultra-efficient" Searched the article, no mention of gzip, and how most of the time all that text data (html, js and css too!) you're sending over the wire will be automatically compressed to...... an efficient binary format! So really, the author should compare protobufs to gzipped JSON

Last time I was evaluating different binary serialization formats for an API I was really hoping to get to use one of the cool ones, but gzipped JSON just beat everything and it wasn't even close.

Re: Why I stopped using JSON for my APIs

#130

Post by MangoToupe »

davedx wrote: post #124

"Ultra-efficient" Searched the article, no mention of gzip, and how most of the time all that text data (html, js and css too!) you're sending over the wire will be automatically compressed to...... an efficient binary format! So really, the author should compare protobufs to gzipped JSON

I would think that serialization/deserialization time would be the largest drawback of json (at least for serving APIs). Pretty much all the other pain points can slowly be ironed out over time, albeit with deeply ugly solutions.
Post reply on HN