4 ms·

Mapping JSON to rigidly typed languages is also a bit of a problem. E.G. in golang you can use Interface, for some level of performance cost, to handle arbitra

Mapping JSON to rigidly typed languages is also a bit of a problem. E.G. in golang you can use Interface, for some level of performance cost, to handle arbitrary maps of (string) keys to (arbitrary, Interface?) values. Usually I've encountered JSON blobs that start with a map (dictionary / object / whatever) of keys to values, but they might also be lists, or maybe even just a string in the case of errors. The values can also be of any type. For rapid prototyping or cases where performance is trivial, I would really like a language to have some kind of object tree type which can represent any of JSON's data types. It would only need to be converted / cast at the leaf level, when transforming data to/from JSON. The same data structure would also be useful for manipulating any other 'trivial within memory' documents, like XML or anything else that easily fits within memory. Extra bonus points if the interface type is also an option for external databases to wired up and mapped as an ORM. Golang has some kind of comments based decorator that does this for XML and JSON mapping of native objects, but it tends to be clunky and I generally end up hating myself for using it on anything not trivial. Offhand I'm not sure if there's a more proper way of implementing it via configuration files / scripts or programatically (build or runtime?)... It'd be interesting to see if any languages have an effective and easy solution to this issue; any suggestions from others?

dnautics 6y ago
I've been pretty happy with Elixir's Ecto. I wouldn't call it easy, though. There is a LOT of ceremony, but it's designed to be declarative and it sure puts me at ease. For database ingress, I use schemas, and put in aggressive validations in the changesets. For jsonb values, I use embedded_schemas (https://thoughtbot.com/blog/embedding-elixir-structs-in-ecto-models https://thoughtbot.com/blog/embedding-elixir-structs-in-ecto...), and cast their creation as a normal part of filling in the database object. For egress to a third party that accepts JSON, I use naked embedded_schemas (even better if they can be shared with the database) and use a protocol to build an custom encoder that can for example send the 3rd party a deeply structured JSON from a flat struct. Due to the way protocols work in elixir, when I send it to Oauth, Oauth will (indirectly) call my protocol code.
- waynesonfire 6y ago
  This sounds pretty sweet, do you happen to have any resources handy that dive deeper into these concepts?
  - dnautics 6y ago
    unfortunately it's not super well documented. Some of the concepts are a bit new (~2 yrs or so), and I kind of stumbled into this as a best practice by accident literally in the last two months when I had to do this for work and was like, "oh, this is a thing". This video helped: https://www.youtube.com/watch?v=k_xDi7zAcNM https://www.youtube.com/watch?v=k_xDi7zAcNM
deepakarora3 6y ago
This article got my attention. Related to what you are saying, in Java, the problem that I was really fed up of was creating domain specific JSON object models to map the JSON documents into to use in code. In other words, mapping JSON to rigidly typed language structure. Its boiler plate, is tedious to do (as the author points out in the article), difficult to change and usually a pain. I solved this problem by creating unify-jdocs which completely eliminates the need to create object models or POJO classes to represent your JSON object. You can read more about it here -> https://github.com/americanexpress/unify-jdocs https://github.com/americanexpress/unify-jdocs I hope it helps you and others.

dnautics 6y ago

I've been pretty happy with Elixir's Ecto. I wouldn't call it easy, though. There is a LOT of ceremony, but it's designed to be declarative and it sure puts me at ease. For database ingress, I use schemas, and put in aggressive validations in the changesets. For jsonb values, I use embedded_schemas (https://thoughtbot.com/blog/embedding-elixir-structs-in-ecto-models https://thoughtbot.com/blog/embedding-elixir-structs-in-ecto...), and cast their creation as a normal part of filling in the database object. For egress to a third party that accepts JSON, I use naked embedded_schemas (even better if they can be shared with the database) and use a protocol to build an custom encoder that can for example send the 3rd party a deeply structured JSON from a flat struct. Due to the way protocols work in elixir, when I send it to Oauth, Oauth will (indirectly) call my protocol code.

waynesonfire 6y ago
This sounds pretty sweet, do you happen to have any resources handy that dive deeper into these concepts?
- dnautics 6y ago
  unfortunately it's not super well documented. Some of the concepts are a bit new (~2 yrs or so), and I kind of stumbled into this as a best practice by accident literally in the last two months when I had to do this for work and was like, "oh, this is a thing". This video helped: https://www.youtube.com/watch?v=k_xDi7zAcNM https://www.youtube.com/watch?v=k_xDi7zAcNM

deepakarora3 6y ago

This article got my attention. Related to what you are saying, in Java, the problem that I was really fed up of was creating domain specific JSON object models to map the JSON documents into to use in code. In other words, mapping JSON to rigidly typed language structure. Its boiler plate, is tedious to do (as the author points out in the article), difficult to change and usually a pain. I solved this problem by creating unify-jdocs which completely eliminates the need to create object models or POJO classes to represent your JSON object. You can read more about it here -> https://github.com/americanexpress/unify-jdocs https://github.com/americanexpress/unify-jdocs I hope it helps you and others.