> > >... First question being, which JSON library do we support? As we settled on > > johnzon, I assume thats the one... > > It looks like the Johnzon Mapper module [2] should support what I need > but I haven't found real documentation about it so far. I'll have a > look a might switch the graphql-core to it if I like what I see.
though Johnzon Mapper can handle generic data types like deeply nested maps, such as what is returned by graphql-java, but the controls here are rather limited. Most of the functionality is tuned to well-defined POJOs and not something generic such as a sling Resource or JCR Node. I've been using Mapper by itself and combined with graphql-java for 3+ years, filing bugs and PRs on Mapper along the way. For graphql-java + any JSON serializer, it simplifies down to null, Map, and GraphQLScalarType serializations. If one would want to use Mapper within Sling generically, this would likely entail having a org.apache.johnzon.mapper.ObjectConverter.Writer implementation to handle serializing Resources as JSON properly. This Writer implementation would then handle the control as to *what to write* on a Resource, such as which properties and which resource/node children, leaving the *how to write* to the Mapper configuration. >From a rather quick attempt at seeing if such a Writer exists, I did not find anything but instead found many direct uses of JSON-P instead. Whether this is a benefit or nuisance lies in how much of the JSON-P logic is shared or duplicated. I've not gone deep enough to have any foundation for evaluating sling here. Utilizing Mapper would allow simplify configuring how to serialize property values types (e.g. java.time types as ISO 8601) by registering Adapters or Writers to serialize those types. The configuration could then be shared by all components within the system needing to serialize (deserialize) and then possibly allow for one-time overrides by accepting an optional Mapper instance when serializing.
