Graphback: Is it possible to have Metadata validation?

[machi1990]

I made a typo in the way I wrote my metadata but
@crud.sudCreate: false when running the generation nothing failed, when I checked the model.ts I had this entry for the model in question publishCreate: true.

Is it possible to fail early in this case by performing some kind of validation for the metadata?

Opening it as question.

[craicoverflow]

If you don't supply a CRUD configuration value for a model then the global config value is applied to that model.

We don't parse metadata into typed interfaces now, so it is not possible to validate the metadata.

This could be something we could add and I can see the benefit of doing so. We could have a CrudMetadata interface that we try to parse @crud name spaced annotations into and so on.

We chose graphql-metadata over directives due to their flexibility at the cost of not being typed or recognised by GraphQL parser, but parsing the core annotations is a fair compromise and a good idea.

[machi1990]

.. but parsing the core annotations is a fair compromise and a good idea.

+1. Yes, especially when we'll drop codegen for resolvers and everything will be runtime driven.

[wtrocki]

https://github.com/aerogear/graphql-metadata/blob/master/tests/specs/annotations.js

Annotations giving us objects that are losely defined.
Validation should be added here:

https://github.com/aerogear/graphback/blob/deprecate-db-and-resolvers/packages/graphback-core/src/plugin/GraphbackCoreMetadata.ts#L78

Global validation can be added here:
https://github.com/aerogear/graphback/blob/deprecate-db-and-resolvers/packages/graphback-core/src/plugin/GraphbackCoreMetadata.ts#L31:L31

[wtrocki]

EDIT: Haven't seen that @craicoverflow responded

[machi1990]

Once the dust on the refactor is settled, I could work on this.

[machi1990]

While we are on this topic: Is Subscription a valid model name? If so, how does it play out with generated crud subscription type?

[wtrocki]

That is graphql related question, but I will answer it here.
Subscription is not valid user type unless we map subscription to a different type:

root {
    ...
    subscription: IWantToBeDifferentSubscription
}

[machi1990]

https://github.com/aerogear/graphql-metadata/blob/master/tests/specs/annotations.js

Annotations giving us objects that are losely defined.
Validation should be added here:

https://github.com/aerogear/graphback/blob/deprecate-db-and-resolvers/packages/graphback-core/src/plugin/GraphbackCoreMetadata.ts#L78

Global validation can be added here:
https://github.com/aerogear/graphback/blob/deprecate-db-and-resolvers/packages/graphback-core/src/plugin/GraphbackCoreMetadata.ts#L31:L31

The link are actually not valid anymore but this is the same idea that I had. Once the annotations are parsed check if there is any metadata that's unknown, and spit an error. I was thinking of doing it for the @crud namespace. And the global configuration.

We don't parse metadata into typed interfaces now, so it is not possible to validate the metadata.

This could be something we could add and I can see the benefit of doing so. We could have a CrudMetadata interface that we try to parse @crud name spaced annotations into and so on.

But would love to know what @craicoverflow had in mind with this. Is it the same idea as the one above?

[craicoverflow]

I don't think we should spit an error for unknown metadata because people can bring custom plugins with their own annotations that Graphback is not aware of.

This could be something we could add and I can see the benefit of doing so. We could have a CrudMetadata interface that we try to parse @crud name spaced annotations into and so on.

This is pretty much how I pictured it too :smile:

[machi1990]

I don't think we should spit an error for unknown metadata because people can bring custom plugins with their own annotations that Graphback is not aware of.

This can very much happen for the @crud namespace? I thought it is reserved for graphback core plugins.

This could be something we could add and I can see the benefit of doing so. We could have a CrudMetadata interface that we try to parse @crud name spaced annotations into and so on.

This is pretty much how I pictured it too

Okay, what kind of validations do we see being done / performed?

[craicoverflow]

This can very much happen for the @crud namespace? I thought it is reserved for graphback core plugins.

Sorry, I thought you meant throw an error for _any_ unknown metadata namespace just for @crud.

So yeah, I do see it the same way - @crud.randomProp does not exist on our CrudMetadata interface so throw an error.

[machi1990]

This can very much happen for the @crud namespace? I thought it is reserved for graphback core plugins.

Sorry, I thought you meant throw an error for _any_ unknown metadata namespace just for @crud.

So yeah, I do see it the same way - @crud.randomProp does not exist on our CrudMetadata interface so throw an error.

Yes I was thinking of doing it for @crud namespace.

[wtrocki]

TL;DR - we have tried to implement this and it was hard due to how metadata works.

We can specify what annotation or marker we need instead of getting all annotations or markers. We are not ready for validation - first we need to standardize our annotations markers , then maybe we can add method to metadata to get all possible markers from doc and validate it with array of the annotations we have

[machi1990]

Closing this for now, users should be able to follow our guides and not make the typo mistake I did. We can revisit later the need of fine grained validations.