Arguments against JSON-driven development • Hacker News Board

Re: Arguments against JSON-driven development

#71

Post by parenthephobia » Thu, Aug 25, 2016, 2:46 PM UTC

qwertyuiop924 wrote: post #45

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…

Part of the problem is that JSON and Sexprs aren't that they AREN'T serialization formats. They've been pressed into service as such, but they are actually notation for datastructures: In python, it may not be idiomatic to crawl dicts like this, but in JS, those aren't dicts, they're objects. If they've been de-serialized to some degree, they may even have their own methods. By the same token, in Lisp, Sexprs aren't…

What are serialization formats, then? What makes them different from notations for data structures?

Re: Arguments against JSON-driven development

#72

Post by joelcorrea » Thu, Aug 25, 2016, 2:48 PM UTC

Pretty much statically typed vs dinamically-typed discussion. It depends on your particular case, if there is a sufficiently defined schema or not

Re: Arguments against JSON-driven development

#73

Post by catnaroek » Thu, Aug 25, 2016, 2:48 PM UTC

qwertyuiop924 wrote: post #66

catnaroek wrote: post #61

Earlier quoted context omitted.

It's relevant. If it weren't, there wouldn't be a debate regarding the usefulness of behaviorless objects.

Well than FFS express yourself clearly.

Nobody other than an object-oriented programmer would think a value is something that evolves over time.

Re: Arguments against JSON-driven development

#74

Post by emodendroket » Thu, Aug 25, 2016, 2:49 PM UTC

There's no particular reason objects can't be serialized as JSON and deserialized back into strongly typed objects.

Re: Arguments against JSON-driven development

#75

Post by sidlls » Thu, Aug 25, 2016, 2:52 PM UTC

clifanatic wrote: post #48

Cthulhu_ wrote: post #8

I disagree with the anemic object argument. If an object is just there to store data and no behaviour, then that's fine - don't add behaviour if it doesn't need it. A large portion of back-end services are CRUD and data wrangling operations anyway - as in, convert data format A to data format B (which I guess could be a constructor or factory method if you're comfortable with having the conversion logic in a data cla…

> If an object is just there to store data and no behavior Then why do you have it at all?

Sometimes many different values are related to each other and it is useful to keep them close together for explicitness (and other reasons).

Re: Arguments against JSON-driven development

#76

Post by mythz » Thu, Aug 25, 2016, 2:55 PM UTC

adrianratnapala wrote: post #31

Cthulhu_ wrote: post #7

Earlier quoted context omitted.

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 don…

That's because you should be serializing purpose-specific DTOs or clean POCOs not Business Objects with behavior.

Re: Arguments against JSON-driven development

#77

Post by mack73 » Thu, Aug 25, 2016, 2:55 PM UTC

PaulHoule wrote: post #44

adrianratnapala wrote: post #31

Earlier quoted context omitted.

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 don…

Automated serialization has gotten much better than it was in the bad old days of RPC and COM!

I have nothing good to say about COM, but I'm seriously thinking about gRPC [0] to get away from the sloppy json endpoints we code around today, at work. Before I dive in I would love to hear, what it is that makes that architecture a bad one.

[0] http://www.grpc.io/

Re: Arguments against JSON-driven development

#78

Post by StavrosK » Thu, Aug 25, 2016, 3:01 PM UTC

aeruder wrote: post #22

lmm wrote: post #11

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class". I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata…

An article about the "attrs" library was posted here a couple weeks ago. Really highlighted the tedium of Python objects while offering a neat solution. https://glyph.twistedmatrix.com/2016/08/attrs.html Regarding protobuf, I'm a bit disappointed with the direction of version 3. Fields can no longer be marked as required - everything is optional; i.e. almost every protobuf needs to be wrapped with some sort of valida…

That's a really interesting article, thank you!

EDIT: I liked it so much that I posted it here:

https://news.ycombinator.com/item?id=12359522

Re: Arguments against JSON-driven development

#79

Post by cjslep » Thu, Aug 25, 2016, 3:02 PM UTC

catnaroek wrote: post #73

qwertyuiop924 wrote: post #66

Earlier quoted context omitted.

Well than FFS express yourself clearly.

Nobody other than an object-oriented programmer would think a value is something that evolves over time.

>Nobody other than an object-oriented programmer would think a value is something that evolves over time.

I don't think you fully read qwertyuiop924's post to get to the Randall Munroe quote, which makes this comment priceless.

Re: Arguments against JSON-driven development

#80

Post by emodendroket » Thu, Aug 25, 2016, 3:02 PM UTC

catnaroek wrote: post #73

qwertyuiop924 wrote: post #66

Earlier quoted context omitted.

Well than FFS express yourself clearly.

Nobody other than an object-oriented programmer would think a value is something that evolves over time.

Given that "object-oriented programmer" probably constitutes most of the people here you ought to know your audience and explain what you mean to say.