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

181–190 of 245 posts

Re: Why I stopped using JSON for my APIs

#181

Post by smohare »

morshu9001 wrote: post #178
almosthere wrote: post #92

Earlier quoted context omitted.

why are you against static types in languages? I once converted a fairly large JS codebase to TS and I found about 200 mismatching names/properties all over the place. Tons of properties we had nulls suddenly started getting values.

It costs time, distracts some devs, and adds complexity for negligible safety improvement. Especially if/when the types end up being used everywhere because managers like that metric. I get using types if you have no tests, but you really need tests either way. I've done the opposite migration before, TS to JS. Oh I forgot to qualify that I'm only talking about high level code, not things that you'd use C or Rust for…

[dead]

Re: Why I stopped using JSON for my APIs

#182

Post by WorldMaker »

andersmurphy wrote: post #143
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

Or streaming brotli/zstd json/html where the compression window can be used for the duration of the connection.

Brotli also benefits out-of-the-box in fresh compression windows with some common JSON patterns always in the Brotli static dictionary.

Re: Why I stopped using JSON for my APIs

#183

Post by cosmotic »

chrismorgan wrote: post #166
HelloNurse wrote: post #145

Earlier quoted context omitted.

The blog seems to contain other similar misunderstandings: for example the parallel article against using SVG images doesn't consider scaling the images freely a benefit of vector formats.

https://aloisdeniel.com/blog/i-changed-my-mind-about-vector-... seems fairly clearly to be talking about icons of known sizes, in which case that advantage disappears. (I still feel the article is misguided and that the benefit of runtime-determined scaling should have been mentioned, and see no benchmarks supporting its performance theses, and I’d be surprised if the difference was anything but negligible; vector gr…

Icons are no longer fixed sizes. They're are numerous dpi/scaling settings even if the "size" doesn't change.

Re: Why I stopped using JSON for my APIs

#184

Post by myvoiceismypass »

dhussoe wrote: post #50

I like that JSON parsing libraries (Serde etc.) allow you to validate nullability constraints at parse-time. Protobuf's deliberate lack of support for required fields means that either you kick that down to every callsite, or you need to build another parsing layer on top of the generated protobuf code. Now, there is a serde_protobuf (I haven't used it) that I assume allows you to enforce nullability constraints but…

'Parse, don't validate' is such great reading: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Re: Why I stopped using JSON for my APIs

#185

Post by HelloNurse »

chrismorgan wrote: post #166
HelloNurse wrote: post #145

Earlier quoted context omitted.

The blog seems to contain other similar misunderstandings: for example the parallel article against using SVG images doesn't consider scaling the images freely a benefit of vector formats.

https://aloisdeniel.com/blog/i-changed-my-mind-about-vector-... seems fairly clearly to be talking about icons of known sizes, in which case that advantage disappears. (I still feel the article is misguided and that the benefit of runtime-determined scaling should have been mentioned, and see no benchmarks supporting its performance theses, and I’d be surprised if the difference was anything but negligible; vector gr…

> seems fairly clearly to be talking about icons of known sizes, in which case that advantage disappears.

That's the point: obliviousness to different concerns and their importance.

Among mature people, the main reason to use SVG is scaling vector graphics (in different contexts, including resolution-elastic final rendering, automatically exporting bitmap images from easy to maintain vector sources, altering the images programmatically like in many icon collections); worrying about file sizes and rendering speed is a luxury for situations that allow switching to bitmap images without serious cost or friction.

Re: Why I stopped using JSON for my APIs

#186

Post by kstrauser »

kragen wrote: post #159
bloppe wrote: post #18

Earlier quoted context omitted.

What makes it too complex in your opinion?

Experience with ASN.1.

Same. My take on ASN.1 is that no one would pay me what I would ask to work on ASN.1. I’d only touch it if I had to parse files from an outside source, and a package already exists in my language of choice that’s capable of parsing those files.

Re: Why I stopped using JSON for my APIs

#187

Post by madFlasher »

The author should check first the performance of protobuf serialization/deserialiazation in browsers

Due to very native nature of JSON in browsers and node backend it usually also the fastest data format

If for example you have C++ on backend and C++ on frontend - you'll definitely have some performance boost

But for browsers usage the goal is not so obvious

Re: Why I stopped using JSON for my APIs

#188

Post by WorldMaker »

paulddraper wrote: post #120
rock_artist wrote: post #119

I feel few points weren’t addressed in the article. 1. Size, biggest problem with JSON can happen when things gets too big. So here other formats might be better. Yet, as a reminder JSON has the binary version named BSON. 2. Zero batteries. JSON is readable by humans but also almost self explanatory format. Most languages has built in or quick drop in for json. Still, it’s easy to implement a limited JSON parser from…

BSON is not simply a binary encoding of JSON. It is a JSON superset with binary encoding, created by MongoDB. (And there is even a JSON encoding of BSON, called extended JSON.) AFAIK there is no widely adopted binary pure adaptation of JSON. (There are application-specific storage formats, like PostgreSQL JSONB, or SQLite JSONB.) ——- Moreover, JSON is relatively compact. BSON or other self descriptive binary formats…

CBOR [0] is probably the closest to a widely adopted "pure" adaptation of JSON. It is still technically a superset of JSON, but it tries to be closely matched and frequently cross-references the JSON specs directly, especially because it is also an IETF tracked standard like JSON, and in so far as widely adopted is concerned is included in web standards like WebAuthn today. (For instance, you can't handle Passkeys without some amount of CBOR. The presumed next steps to wider adoption now that all browsers have internal CBOR encoders/decoders would be to add a web platform JS API for it as well.)

However, yes, JSON compresses extremely well even in ancient gzip, but especially in Brotli, and desiring compaction of your API responses alone isn't necessarily the best reason to prefer a binary encoding of JSON to just using JSON and letting compression do its thing.

[0] https://www.rfc-editor.org/rfc/rfc8949.html

Re: Why I stopped using JSON for my APIs

#189

Post by chrismorgan »

cosmotic wrote: post #183
chrismorgan wrote: post #166

Earlier quoted context omitted.

https://aloisdeniel.com/blog/i-changed-my-mind-about-vector-... seems fairly clearly to be talking about icons of known sizes, in which case that advantage disappears. (I still feel the article is misguided and that the benefit of runtime-determined scaling should have been mentioned, and see no benchmarks supporting its performance theses, and I’d be surprised if the difference was anything but negligible; vector gr…

Icons are no longer fixed sizes. They're are numerous dpi/scaling settings even if the "size" doesn't change.

The article goes into that, it’s making a sprite map of at least the expected scaling factors.

Re: Why I stopped using JSON for my APIs

#190

Post by chrismorgan »

eviks wrote: post #168
chrismorgan wrote: post #166

Earlier quoted context omitted.

https://aloisdeniel.com/blog/i-changed-my-mind-about-vector-... seems fairly clearly to be talking about icons of known sizes, in which case that advantage disappears. (I still feel the article is misguided and that the benefit of runtime-determined scaling should have been mentioned, and see no benchmarks supporting its performance theses, and I’d be surprised if the difference was anything but negligible; vector gr…

Are there display pipelines that cache the generated-for-my-device-resolution svgs instead of doing all the slower parsing etc from scratch every time, achieving benefits of both worlds? And you can still have runtime-defined scaling by "just" rebuilding the cache?

Increasingly I think you’ll find that the efficient format for simple icons like this actually isn’t raster, due to (simplifying aggressively) hardware acceleration. We definitely haven’t reached that stage in wide deployment yet, but multiple C++ and Rust projects exist where I strongly suspect it’s already the case, at least on some hardware.
Post reply on HN