Graphback: parse metadata and store them in `ModelDefinition` as much as possible

[machi1990]

The idea has been raised a couple of times:

• In https://github.com/aerogear/graphback/pull/1614#discussion_r448159331
• And https://github.com/aerogear/graphback/pull/1647#discussion_r449454898

Opening it here to keep track and to drive potential discussion.

[machi1990]

/cc @ssd71 @craicoverflow @wtrocki

[craicoverflow]

This will work really well in the service and provider creator abstractions. But it would make it extremely difficult for a user to make a one-off service that extends CRUDService outside of the service creator.

So the trade-off will be that there will be only one way to create services and providers, which I am fine with.

[machi1990]

Additionally, we should parse model's field names and store them in an array [fields]. One particular usecase I am thinking of is described here https://github.com/aerogear/graphback/pull/1729#discussion_r455017887

[craicoverflow]

Some thoughts from a discussion between myself and @machi1990

in best practices the data providers should not have any reference to a GraphQLObjectTypes at all. By abstracting ModelDefinition completely away from GraphQLObjectType the providers could be used outside of a GraphQL application - which would be awesome.

However, the ModelDefinition does still need a reference to the GraphQLObjectType for use elsewhere, such as in GraphbackCoreMetadata when building a plugin.

Perhaps these interfaces should be separate, where the Data Provider accepts a different interface from ModelDefinition containing only data valuable to the dataprovider.

I am a little bit against having an abstraction of GraphQLObjectType that can be used in both places (meaning it would no longer have any reference to GraphQLObjectType) because in older versions of Graphback we had this, called InputModelTypeContext and it was difficult to work with. See https://github.com/aerogear/graphback/blob/0.10.1/packages/graphback-core/src/api/ContextTypes.ts#L79-L86

[wtrocki]

Amazing writeoff. Please no InputModelTypeWhateverContext anymore :D

[wtrocki]

Challenge is that we do not know what metadata people might add. And most of the people still will be using directives (sadly) so we can collect as much metadata as much we have inside core. (Stuff from datasync cannot be there as will polute core with concepts that are separate).

[craicoverflow]

Challenge is that we do not know what metadata people might add.

Graphback could parse all metadata and add it the the model definition. It would not be typed but the user could then work with it in their providers.

export type ModelDefinition = {
  primaryKey: string
  annotations: any
}

[craicoverflow]

@machi1990 is this closed by https://github.com/aerogear/graphback/pull/1730?

[machi1990]

Partly, but there are things like indexes that are not parsed yet. This will be needed for https://github.com/aerogear/graphback/blob/ecf2e2ae1bbf28a681ff94964a8f967a7deaf4bb/packages/graphback-runtime-mongodb/src/utils/createIndexes.ts

[machi1990]

Partly, but there are things like indexes that are not parsed yet. This will be needed for https://github.com/aerogear/graphback/blob/ecf2e2ae1bbf28a681ff94964a8f967a7deaf4bb/packages/graphback-runtime-mongodb/src/utils/createIndexes.ts

Was revisiting this issue again and evaluating the need to do this for @index, and came to the conclusion that createIndexes.ts is too specific for mongodb and there won't be much benefits in exposing the indexes on a ModelDefinition. Going to close this issue and we can re-open more specific ones if needed.