Add specific classes for Relationships when resolving nested objects

[jimwood]

For example, can person.postions result in a collection of Position objects rather than Relationship objects? Relationship contains all fields that could appear on any of the relationships represented in Vivo. Ideally, the schema for items in person.postions would only contain the id, label and the related organization. It would not have empty, unrelated fields such as thumbnailmage.

[ghost]

https://github.com/vivo-community/scholars-discovery/blob/master/src/main/resources/graphql/composites.yml

A persons position is defined as a reference of a composite. The position can be removed and it will generate the partial for persons position.

[ghost]

I have put much thought into not only the GraphQL class/schema generation, but also the nesting strategy for the REST responses. It is not as configurable as it needs to be. I would like to propose introducing a JsonSchema strategy for mapping the flat Solr documents to compound objects for the REST and subsequently a similar strategy for generating the GraphQL class/schema.

The idea is to represent a given model in JsonSchema and add additional properties on where the properties come from in the SoldDocuments. These JsonSchema would be consumed by a service and used to generate classes and also used during serialization and de-referencing. I will have to elaborate on the idea, but will provide implementors ability to define their response models for both REST and GraphQL. Of course it will be constrained by what properties are in the Solr document and have to implement affordance for stitching cross Solr document types together.

I prefer a solution in which we keep the most generic types as SolrDocuments mapped from the VIVO ontology and provide ability to define specific models that are desired in a more configurable approach. JsonSchema is simple and descriptive enough to accomplish the desired representation for this.

There will also have to be a configuration in which describes how resolvers are generated. Most likely an extension of a generic class with utility to perform the necessary lookups and stitching. I would most likely propose yaml and a custom model to configure the resolver generation.

[jimwood]

This should be approached in multiple steps. Code generation is the long term, maintainable options. Need it investigate first by creating static models and resolvers. Suggest new package under graphql called 'static' containing 'model' and 'service'. Resolvers will need to retrieve the Solr documents as Individual and map to the specific model (ie. Position).

Use IndividualRepo to retrieve the flattened documents.

For example create:

• graphql.static.model.Position (pojo, annotated for graphql type)
• graphql.static.service.PositionResolver (annotate with @service and @GraphQLAPI, autowire IndividualRepo, annotate methods for graphql query, annotate arguments)