3 ms·

It’s also conflating the serialization format with contracts

by klysm 11mo ago

shortrounddev2 10mo ago
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
- Seattle3503 10mo ago
  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.
  - masklinn 10mo ago
    > My experience with protobufs is that it was created to solve problems in large systems with many teams and APIs Also significant distribution such that it’s impossible to ensure every system is updated in lockstep (at least not without significant downtime), and high tail latencies e.g. a message could be stashed into a queue or database and processed hours or days later.
ablob 10mo ago
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.
- peterkelly 10mo ago
  Unless a violation of that contract can lead to a crash or security vulnerability...
  - ablob 10mo ago
    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.
  - happymellon 10mo ago
    Then reject the request if it is incomplete?

It’s also conflating the serialization format with contracts

by klysm 11mo ago

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

Seattle3503 10mo ago
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.
- masklinn 10mo ago
  > My experience with protobufs is that it was created to solve problems in large systems with many teams and APIs Also significant distribution such that it’s impossible to ensure every system is updated in lockstep (at least not without significant downtime), and high tail latencies e.g. a message could be stashed into a queue or database and processed hours or days later.

ablob 10mo ago

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.

peterkelly 10mo ago
Unless a violation of that contract can lead to a crash or security vulnerability...
- ablob 10mo ago
  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.
- happymellon 10mo ago
  Then reject the request if it is incomplete?