Show HN: Unify-jdocs – read / write any JSON path with a single line of code
2 comments
> the benefits we get from using dynamic typing outweigh the benefits of static typing
The trend seems to be in the opposite direction. People became frustrated with the lack of types in Python and JavaScript, hence we get Python with typing and TypeScript.
Strong, development time, typing catches many bugs much earlier with less effort.
> Reason for posting again....
Most people use the link version of a post and then make a comment with some text, if it sufficiently adds context or value, i.e. don't just copy the same landing text
I think you will find less traction with this method of posting to HN. People want a clickable link to look at the project
The trend seems to be in the opposite direction. People became frustrated with the lack of types in Python and JavaScript, hence we get Python with typing and TypeScript.
Strong, development time, typing catches many bugs much earlier with less effort.
> Reason for posting again....
Most people use the link version of a post and then make a comment with some text, if it sufficiently adds context or value, i.e. don't just copy the same landing text
I think you will find less traction with this method of posting to HN. People want a clickable link to look at the project
Auther here - thanks for responding! I really do appreciate it.
> The trend seems to be in the opposite direction. People became frustrated with the lack of types in Python and JavaScript, hence we get Python with typing and TypeScript.
Regarding typing, what I have tried to achieve is the best of both worlds. In unify-jdocs, we have the concept of typed document. This is a document that defines the structure of the JSON document. It defines what the "type" of a leaf node is i.e. integer, string etc. The validation / determination against this type is however done at runtime. This, I feel is acceptable because whenever we add a JSON path to a document, the first thing we would do is to test the read / write of that path. And any type mismatch would get caught there immediately. And so, from the point of view of being able to read / write / validate in a single line of code (even though dynamically) provides much simplicity and ease of use as compared to using POJOs. Plus we always know the exact JSON path we are dealing with.
Usually, I would prefer static typing but, in a scenario, where we can have hundreds of JSON document types (we deal with more than 500 in the same application), complex JSON document (ours go down more than ten levels deep with hundreds of JSON paths) and where the document structures may undergo change over project lifetime, the use of read / writing using a single line of code has many benefits. I shudder to think of hundreds (if not thousands) of POJO classes, the writing of accessor methods (null / empty handling, namespace etc.) and what it would take to refactor in the face of change. Just my opinion based on my experience in the past.
> I think you will find less traction with this method of posting to HN. People want a clickable link to look at the project
The clickable link to the repo / documentation is actually in the text (https://github.com/americanexpress/unify-jdocs). In the case of this post, I felt it more important for people to read the text rather than be directly pointed to the contents of the link and hence this approach.
> The trend seems to be in the opposite direction. People became frustrated with the lack of types in Python and JavaScript, hence we get Python with typing and TypeScript.
Regarding typing, what I have tried to achieve is the best of both worlds. In unify-jdocs, we have the concept of typed document. This is a document that defines the structure of the JSON document. It defines what the "type" of a leaf node is i.e. integer, string etc. The validation / determination against this type is however done at runtime. This, I feel is acceptable because whenever we add a JSON path to a document, the first thing we would do is to test the read / write of that path. And any type mismatch would get caught there immediately. And so, from the point of view of being able to read / write / validate in a single line of code (even though dynamically) provides much simplicity and ease of use as compared to using POJOs. Plus we always know the exact JSON path we are dealing with.
Usually, I would prefer static typing but, in a scenario, where we can have hundreds of JSON document types (we deal with more than 500 in the same application), complex JSON document (ours go down more than ten levels deep with hundreds of JSON paths) and where the document structures may undergo change over project lifetime, the use of read / writing using a single line of code has many benefits. I shudder to think of hundreds (if not thousands) of POJO classes, the writing of accessor methods (null / empty handling, namespace etc.) and what it would take to refactor in the face of change. Just my opinion based on my experience in the past.
> I think you will find less traction with this method of posting to HN. People want a clickable link to look at the project
The clickable link to the repo / documentation is actually in the text (https://github.com/americanexpress/unify-jdocs). In the case of this post, I felt it more important for people to read the text rather than be directly pointed to the contents of the link and hence this approach.
We announced the first release of unify-jdocs in August 2020. Since then, it has undergone multiple feature enhancements and has been used extensively within American Express as part of the project it was developed for. We have had tremendous success with it and have been able to reduce the size of our codebase substantially, make it much easier for developers and improve maintainability and agility significantly. Unify-jdocs has been invoked billons of times in production and has demonstrated great reliability. The original post can be found here: https://news.ycombinator.com/item?id=24332382.
Reason for posting again – last time while submitting on Show HN, I listed the URL in the URL field and so this text of mine was not visible! And so, I try to continue to promote unify-jdocs.
This is a one-of-a-kind library in my opinion. Two features stand out – read / write any JSON path in a single line of code – and define a document structure and validate a JSON document against it – along with a host of other features. It makes life so much simpler for any Java project that deals with JSON documents.
For projects that deal with more than a few simple JSON documents, need to do transformations and change structure during project lifetime, unify-jdocs absolutely shines. It provides a much simpler way of validating documents as compared to JSON schema.
One counter argument which I have heard come up again and again against using unify-jdocs is around static / dynamic type safety. When we use POJOs, the read / write operations on the document are statically compiled into the app JAR file whereas in the case of unify-jdocs, these operations take place dynamically at run time. In my opinion, the benefits we get from using dynamic typing outweigh the benefits of static typing using POJO / model classes. Looking forward to discussing more. Thanks.