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

71–80 of 245 posts

Re: Why I stopped using JSON for my APIs

#71

Post by koakuma-chan »

dhussoe wrote: post #67
koakuma-chan wrote: post #62

Earlier quoted context omitted.

> strictly parsing (parse, don't validate) That's called validating? Zod is a validation library. But yeah, people really need to start strictly parsing/validating their data. One time I had an interview and I was told yOu DoN'T tRuSt YoUr BaCkeNd?!?!?!?

"parse don't validate" is from: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... looking at zod (assuming https://zod.dev ) it is a parsing library by that definition — which isn't, like, an official definition or anything, one person on the internet came up with it, but I think it is good at getting the principle across under these definitions a "parser" takes some input and returns either some valid…

I like your message and I think that you are right on everything.

Re: Why I stopped using JSON for my APIs

#72

Post by jonny_eh »

JoshMock wrote: post #64

Protobuf is a great format with a lot of benefits, but it's missing one that I wish it could support: zero-copy. The ability to transport data between processes, services and languages with effectively zero time spent on serialization and deserialization. It appears possible in some cases but it's not universally the case. Which means that similar binary transport formats that do support zero-copy, like Cap'n Proto,…

Is that a format/serialization issue, or library/implementation issue?

Re: Why I stopped using JSON for my APIs

#73

Post by dhussoe »

koakuma-chan wrote: post #71
dhussoe wrote: post #67

Earlier quoted context omitted.

"parse don't validate" is from: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... looking at zod (assuming https://zod.dev ) it is a parsing library by that definition — which isn't, like, an official definition or anything, one person on the internet came up with it, but I think it is good at getting the principle across under these definitions a "parser" takes some input and returns either some valid…

I like your message and I think that you are right on everything.

yeah I have repeatedly had things like "yOu DoN'T tRuSt YoUr BaCkeNd?!?!?!?" come up and am extremely tired of it when it's 2025 and we have libraries that solve this problem automatically and in a way that is usually more ergonomic anyways... I don't do JS/TS so I guess just casting the result of JSON.parse is sort of more convenient there, but come on...

Re: Why I stopped using JSON for my APIs

#74

Post by koakuma-chan »

dhussoe wrote: post #73
koakuma-chan wrote: post #71

Earlier quoted context omitted.

I like your message and I think that you are right on everything.

yeah I have repeatedly had things like "yOu DoN'T tRuSt YoUr BaCkeNd?!?!?!?" come up and am extremely tired of it when it's 2025 and we have libraries that solve this problem automatically and in a way that is usually more ergonomic anyways ... I don't do JS/TS so I guess just casting the result of JSON.parse is sort of more convenient there, but come on...

Yes, I know right? You are so lucky to not do JS/TS—those people are incredible. Finally, someone who understands me.

Re: Why I stopped using JSON for my APIs

#75

Post by Joel_Mckay »

teleforce wrote: post #61

Kudos to the poster and the author of this article. I think this is by far the most insightful technical post I've read this year on HN. >If you develop or use an API, there’s a 99% chance it exchanges data encoded in JSON. Just wondering if the inherent defiencies of JSON can somewhat be improved by CUE lang since the former is very much pervasive and the latter understand JSON [1],[2]. [1] Configure Unify Execute (…

BSON dealt with a lot of the JSON limitations, and ambiguous type issues.

Batching with message pooling to a transaction payload size limit actually made it performant. =3

Re: Why I stopped using JSON for my APIs

#78

Post by zzo38computer »

morshu9001 wrote: post #65
zzo38computer wrote: post #58

Earlier quoted context omitted.

Numbers bigger than 64-bits, character sets other than Unicode (and ASCII), OIDs, etc.

These are only scalars that you'd encode into bytes. I guess it's slightly annoying that both ends have to agree on how to serialize rather than protobuf itself doing it, but it's not a big enough problem. Also I don't see special ASN1 support for non-Unicode string encodings, only subsets of Unicode like ascii or printable ascii. It's a big can of worms once you bring in things like Latin-1.

ASN.1 has support for ISO 2022 as well as ASCII and Unicode (ASCII is a subset of Unicode as well as a subset of ISO 2022). (My own nonstandard extensions add a few more (such as TRON character code and packed BCD), and the standard unrestricted character string type can be used if you really need arbitrary character sets.) (Unicode is not a very good character set, anyways.)

Also, DER allows to indicate the type of data within the file (unless you are using implicit types). Protobuf has only a limited case of this (you cannot always identify the types), and it requires different framing for different types. However, DER uses the same framing for all types, and strings are not inherently limited to 2GB by the file format.

Furthermore, there are other non-scalar types as well.

In any of these cases, you do not have to use all of the types (nor do you need to implement all of the types); you only need to use the types that are applicable for your use.

I will continue to use ASN.1; Protobuf is not good enough in my opinion.

Re: Why I stopped using JSON for my APIs

#79

Post by deathanatos »

youngtaff wrote: post #16
codewritero wrote: post #3

I love to see people advocating for better protocols and standards but seeing the title I expected the author to present something which would be better in the sense of supporting the same or more use cases with better efficiency and/or ergonomics and I don't think that protobuf does that. Protobuf has advantages, but is missing support for a tons of use cases where JSON thrives due to the strict schema requirement.…

We need browsers to support CBOR APIs… and it shouldn’t be that hard as they all have internal implementations now

I suppose I should publish this, but a WASM module, in Rust, which just binds [ciborium] into JS only took me ~100 LoC. (And by this I mean that it effectively provides a "cbor_load" function to JS, which returns JS objects; I mention this just b/c I think some people have the impression that WASM can't interact with JS except by serializing stuff to/from bytestrings and/or JSON, which isn't really the whole story now with refs.)

But yes, a native implementation would save me the trouble!

[ciborium]: a Rust CBOR library; https://docs.rs/ciborium/latest/ciborium/

Post reply on HN