Reflecting on deserialization. Why you should explicitly decode your JSON
When working with JSON, 99% of the time developers write a custom type that closely matches the format of the JSON payload, and then use their favorite programming languages built in metaprogramming ability to automatically deserialization the payload into a typed object. I want to tell you why you shouldn't use reflection and instead take a page out of functional programming and explicitly decode the JSON payload.
Reflecting on deserialization. Why you should explicitly decode your JSON. JSON is everywhere . As developers, we will be required to work with it at some point or another. Maybe in the embedded space you could avoid it, but as a cloud and web developer, I have no choice but to be intricately familiar with all things JSON. As an enjoyer of statically typed programming languages, I need some way of deserializing the JSON payload into a custom defined type in my language of choice. The techniques talked about here are opinions I hold myself that I have developed over my career and work well for
saved by
related reading
- Patterns for Defensive Programming in Rust | corrode Rust Consultingcorrode.dev
- Building a BFT JSON CRDTjzhao.xyz
- Everything I know about good API designseangoedecke.com
- Choosing a faster JSON library for Pythonpythonspeed.com
- The Laws of Reflection - The Go Programming Languagego.dev
- Get better at programming by learning how things workjvns.ca
- Java Serialization: readObject() vs. readResolve() | Baeldungbaeldung.com
- Parse, don’t validatelexi-lambda.github.io
- Schema Registry in Kafka: Avro, JSON and Protobuf | by Ismael Sánchez Chaves | .Net Programming | Mediummedium.com
- Software development topics I've changed my mind on after 10 years in the industrychriskiehl.com
- No, dynamic type systems are not inherently more openlexi-lambda.github.io
- GPT-4o doesn't consistently respect JSON schema on tool usecommunity.openai.com