Hi HN. I would like to show unify-jdocs – a new way of working with JSON documents without using model classes or JSON schemas. Unify-jdocs is a Java library which I have created as part of working on a new technology platform in American Express. You can work with JSON documents without using model classes. It also allows you to do away with JSON schema for validation and provides a much simpler way for structure adherence and content validations. You can read AND write any JSON path including elements of an array nested any levels deep in a single line of code. There are other features like being able to merge documents and reuse model documents.
The background behind writing this library is that we have a large number of JSON document types and many of them are quite complex in terms of structure (many paths and many nested levels). I did not want to create POJO / model classes and write read and write accessor methods for manipulating data in these documents as these can be quite challenging to maintain in the face of changing document structures. I also did not want to use JSON schema validations as they tend to get quite verbose, do not mirror the JSON data document structure and can be unwieldy to use. What I did want was 1) have the ability to read and write any JSON path in a document and know metadata information (like the number of elements in an array, index of a specific element etc.) using a single line of code, 2) the ability to do fast, accurate and exhaustive impact analysis on the usage of JSON paths over the whole code base and be able to refactor quickly in case positions of JSON paths changed in the document structure and 3) the ability to conform to predefined document structures and specify field validations which would automatically get done in the background. This library does all this and more.
Before starting work on this library, I did look around to see if something similar existed. I did find some which could be used to read and write simple JSON paths but could not handle the complex scenarios which we wanted to address. I am happy to report that the use of this library in our project has made working with JSON documents an order of magnitude easier, reduced boilerplate lines of code by nearly 90% (primarily due to no POJO / model classes, accessor methods and validations) and made it extremely easy to refactor code in case paths are updated in the document. For reference, we have over 250 JSON document types, more than 2000 JSON paths nested more than 10 levels deep in multiple documents which we have been successfully able to manage using this library.
I hope this work will help many who have experienced working with POJO / model classes and JSON schema validations to be far too tedious and challenging to maintain in the long run. This is my first creation on open source (better late than never) and I look forward to comments and feedback from the community. Thanks to my employer American Express for open sourcing this piece of work which i truly think has the potential to help a lot of people in the wider Java development community.
This looks very promising FW and looks like you have spent good time in determining the gaps in the ecosystem for similar FW. Good one to try and report back.
I am truly impressed by the value proposition this framework provides for a developer, data marshalling/unmarshalling without maintaining data models for sure will provide big relief to software engineering community, i am really excited to try this framework. Thank you for great idea and thought of making this available on public domain.
Thanks for your comment. Yes, we have a code base which is 350K LOC and growing and it takes us a few seconds in IntelliJ to look up all occurrences of a specific JSON path. The is of great help to us in refactoring in case something changes. It also helps know which path is being read and written from where due to which we are able to pin point its usage and know the exact impact
6 comments
[ 2.9 ms ] story [ 29.2 ms ] threadThe background behind writing this library is that we have a large number of JSON document types and many of them are quite complex in terms of structure (many paths and many nested levels). I did not want to create POJO / model classes and write read and write accessor methods for manipulating data in these documents as these can be quite challenging to maintain in the face of changing document structures. I also did not want to use JSON schema validations as they tend to get quite verbose, do not mirror the JSON data document structure and can be unwieldy to use. What I did want was 1) have the ability to read and write any JSON path in a document and know metadata information (like the number of elements in an array, index of a specific element etc.) using a single line of code, 2) the ability to do fast, accurate and exhaustive impact analysis on the usage of JSON paths over the whole code base and be able to refactor quickly in case positions of JSON paths changed in the document structure and 3) the ability to conform to predefined document structures and specify field validations which would automatically get done in the background. This library does all this and more.
Before starting work on this library, I did look around to see if something similar existed. I did find some which could be used to read and write simple JSON paths but could not handle the complex scenarios which we wanted to address. I am happy to report that the use of this library in our project has made working with JSON documents an order of magnitude easier, reduced boilerplate lines of code by nearly 90% (primarily due to no POJO / model classes, accessor methods and validations) and made it extremely easy to refactor code in case paths are updated in the document. For reference, we have over 250 JSON document types, more than 2000 JSON paths nested more than 10 levels deep in multiple documents which we have been successfully able to manage using this library.
I hope this work will help many who have experienced working with POJO / model classes and JSON schema validations to be far too tedious and challenging to maintain in the long run. This is my first creation on open source (better late than never) and I look forward to comments and feedback from the community. Thanks to my employer American Express for open sourcing this piece of work which i truly think has the potential to help a lot of people in the wider Java development community.
Disclaimer -> #ViewsMyOwn.