Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arguments against JSON-driven development

okigiveup.net

Post reply on HN
Print view View original

31–40 of 306 posts

Re: Arguments against JSON-driven development

#31

Post by adrianratnapala »

Cthulhu_ wrote: post #7
wtbob wrote: post #5

> The fundamental advice on Unicode is decode and encode on system boundaries. That is, you should never be working on non-unicode strings within your business logic. The same should apply to JSON. Decode it into business logic objects on entry into system, rejecting invalid data. Instead of relying on key errors and membership lookups, leave the orthogonal business of type validity to object instantiation. This righ…

When using parsers like e.g. Jackson or Gson for Java, this process is completely transparent and does not require any active thought from the developer - well, maybe if there's very specific formats that don't map 1:1 with the class that should be instantiated or generated from the json object. It's a bit more tricky in JS, both client-side and node. You can't work with the json string there, but after that you work…

I've never had good experiences with automated serialisation -- even though it sounds like other people do it with success. What's the secret?

To give you a flavour of the kind of poblem: In C# (or rather .net) json.net reads JSON and calls setters from the target class.

That means the setters have to be public, and you don't know what order they will be called in, and you have no real signal about when it is all done. The constructor is no longer enough to guarantee the object's invariants are met.

Most awkward.

Re: Arguments against JSON-driven development

#32

Post by smizell »

Coupling your code to the JSON you receive over the web can lead to some interesting problems. If the system on the other end decides to make some change you are not expecting, it can lead to errors.

In JavaScript, a simple thing that helps is to use lodash.get and provide a path to the property you are wanting.

  lodash.get(someObject, 'path.to.a.property')
If the path isn't there, the lodash.get returns undefined. This is much nicer than getting the error "Cannot read property 'to' of undefined" when "path" isn't there.

Re: Arguments against JSON-driven development

#33

Post by mcms »

Anemic objects and whether they are harmful or harmless has been debated in software engineering for long.

I find over-relying on encapsulation more harmful than useful nowadays specially if you are going to write scalable software that are inherently distributed. For example, hiding accessing a database behind a simple getter function makes another programmer ignore performance implication and other issues that may arise.

Re: Arguments against JSON-driven development

#35

Post by qwertyuiop924 »

For crying out loud, you don't have to build an object hierarchy around the thing (although it would make sense to in this case), but at least have the common sense, or the sense of shame, to abstract away data lookups into separate functions. That's data structure abstraction 101.

Re: Arguments against JSON-driven development

#37

Post by in_the_sticks »

catnaroek wrote: post #29
sevensor wrote: post #27

Earlier quoted context omitted.

As tantalor reminds us in a sibling comment, the named tuple works nicely in this role.

All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values.

That's a useless distinction. Everything is an object in Python. Does that mean Python doesn't have values?

Re: Arguments against JSON-driven development

#38

Post by VikingCoder »

wtbob wrote: post #5

> The fundamental advice on Unicode is decode and encode on system boundaries. That is, you should never be working on non-unicode strings within your business logic. The same should apply to JSON. Decode it into business logic objects on entry into system, rejecting invalid data. Instead of relying on key errors and membership lookups, leave the orthogonal business of type validity to object instantiation. This righ…

...unless your application is doing an in-place edit.

For instance, if your image compression application throws out my EXIF data that it doesn't understand, I'm going to be pissed. (Unless you give me an option to preserve it.)

Re: Arguments against JSON-driven development

#39

Post by catnaroek »

in_the_sticks wrote: post #37
catnaroek wrote: post #29

Earlier quoted context omitted.

All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values.

That's a useless distinction. Everything is an object in Python. Does that mean Python doesn't have values?

It has primitive values:

(0) small enough numbers

(1) True, False, None, etc.

(2) object references

But it doesn't have compound values.

And the distinction isn't useless. Values have a richer equational theory than objects, enabling lots of automatic optimizations.

Re: Arguments against JSON-driven development

#40

Post by weatherlight »

Use GraphQL or Really stick with RESTful routes. The more predictable the schema of these Dictionaries/hashes/JSON are the less likely you are to see that mess above. This is true whether you are using a FP approach or an OO approach. Using an Imperative coding style when doing ETL will always be hairy.

That function also violates the Single responsibility principle. I wouldn't even know where to begin to write a unit test for that other than breaking it down into smaller parts. There are design patterns that could be followed in dynamically typed languages that would avoid that mess altogether other than just OO.

Post reply on HN