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

91–100 of 245 posts

Re: Why I stopped using JSON for my APIs

#91

Post by ElectricalUnion »

jonny_eh wrote: post #72
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?

Serialization issue. From the Introduction to Cap’n Proto:

"Cap’n Proto is INFINITY TIMES faster than Protocol Buffers. (...) there is no encoding/decoding step. The Cap’n Proto encoding is appropriate both as a data interchange format and an in-memory representation, so once your structure is built, you can simply write the bytes straight out".

I take it as a rationalization of what OLE Compound File Binary - internal Microsoft Office memory structures serialized "raw" as file format - would look like if they paid more attention to being backward and forward compatible and extensible.

Re: Why I stopped using JSON for my APIs

#92

Post by almosthere »

morshu9001 wrote: post #44
pyrolistical wrote: post #24

Compressed JSON is good enough and requires less human communication initially. Sure it will blow up in your face when a field goes missing or value changes type. People who advocate paying the higher cost ahead of time to perfectly type the entire data structure AND propose a process to do perform version updates to sync client/server are going to lose most of the time. The zero cost of starting with JSON is too com…

I've gone the all-JSON route many times, and pretty soon it starts getting annoying enough that I lament not using protos. I'm actually against static types in languages, but the API is one place they really matter (the other is the DB). Google made some unforced mistakes on proto usability/popularity though.

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.

Re: Why I stopped using JSON for my APIs

#94

Post by beders »

Know the consumer of your API.

If that is just your team, use whatever tech gets you there quick.

However, if you need to provide some guarantees to a second or third party with your API, embrace standards like JSON, even better, use content negotiation.

Re: Why I stopped using JSON for my APIs

#96

Post by OccamsMirror »

jstanley wrote: post #40
DyslexicAtheist wrote: post #39

Earlier quoted context omitted.

> People who advocate paying the higher cost ahead of time to perfectly type the entire data structure AND propose a process to do perform version updates to sync client/server are going to lose most of the time. that's true. But people also rather argue about security vulnerabilities than getting it right from the get-go. Why spend an extra 15 mins effort during design when you can spend 3 months revisiting the ensu…

Alternatively: why spend an extra 15 mins on protobuf every other day, when you can put off the 3-month JSON-revisiting project forever?

I use ConnectRPC (proto). I definitely do not spend any extra time. In fact the generated types for my backend and frontend saves me time.

Re: Why I stopped using JSON for my APIs

#97

Post by socalgal2 »

dhussoe wrote: post #47
brabel wrote: post #17

Earlier quoted context omitted.

No type system survives going through a network.

yes, but any sane JSON parsing library (Rust Serde, kotlinx-serialization, Swift, etc.) will raise an error when you have the wrong type or are missing a required field. and any JSON parsing callsite is very likely also an IO callsite so you need to handle errors there anyways, all IO can fail. then you log it or recover or whatever you do when IO fails in some other way in that situation. this seems like a problem o…

It's common to validate in JS land as well

https://github.com/ajv-validator/ajv

Re: Why I stopped using JSON for my APIs

#99

Post by TillE »

ElectricalUnion wrote: post #91
jonny_eh wrote: post #72

Earlier quoted context omitted.

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

Serialization issue. From the Introduction to Cap’n Proto: "Cap’n Proto is INFINITY TIMES faster than Protocol Buffers. (...) there is no encoding/decoding step. The Cap’n Proto encoding is appropriate both as a data interchange format and an in-memory representation, so once your structure is built, you can simply write the bytes straight out". I take it as a rationalization of what OLE Compound File Binary - intern…

Google has a library/format for that too, with FlatBuffers. Different use cases and advantages really, not clearly better/worse.

Re: Why I stopped using JSON for my APIs

#100

Post by Seattle3503 »

shortrounddev2 wrote: post #83
klysm wrote: post #70

Earlier quoted context omitted.

It’s also conflating the serialization format with contracts

Most web frameworks do both at the same time to the point where having to write code which enforced a type contract after deserializing is a delabreaker for me. I eant to be able to define my DTOs in one place, once, and have it both deserialize and enforce types/format. Anything else is code smell

I'm in the same boat. I mostly write Rust and Python. Using serde_json and Pydantic, you get deserialization and validation at the same time. It allows you to de-serialize really "tight" types.

Most of my APIs are internal APIs that accept breaking changes easily. My experience with protobufs is that it was created to solve problems in large systems with many teams and APIs, where backwards compatibility is important. There are certainly systems where you can't "just" push through a breaking API change, and in those cases protobufs make sense.

Post reply on HN