Ability to validate Module args, result and other types defined in wrapper schema

[Niraj-Kamdar]

Is your feature request related to a problem? Please describe. It'd be nice to have the functionality of validating input args before passing them to the client for invocation. This can be a feature to pre-validate the args before the actual wasm call happens.

Describe the solution you'd like We can create a JSON schema from the defined GraphQL schema of a wrapper. We can use this schema to do input/output or type validation for any type/method from the GraphQL schema

Describe alternatives you've considered We may be able to leverage GraphQL schema itself for validation.

[dOrgJelli]

Hey @Niraj-Kamdar, myself and @namesty agree with you and have talked about this while working on WRAP ABI 0.2. We've documented our initial thoughts on this here: https://github.com/polywrap/wrap/tree/abi-0.2/abi#future-plans

[Niraj-Kamdar]

@dOrgJelli @namesty How would merkle root help here?

[dOrgJelli]

We were thinking it could be used to optimize the comparison of structured objects. Instead of iterating through each property of an object, and checking for type equivalency (recursively because prop might be struct), you could pre-compute a hash of the collection of properties.

Effectively this:

type Foo {
  prop1: String!
  prop2: Bar!
}

type Bar {
  prop1: String!
}

Could be computed as something like this:

hash(Foo) = multi(
  combine(hash("prop1"), hash(`String`), hash(`!`)),
  combine(hash("prop2"), multi(
    combine(hash("prop1"), hash(`String`), hash(`!`))
  )
)

The root hash(Foo) value that's computed could be used to compare two differnet ABIs that are being "linked" at runtime to see if they're equal. For example "Does the ABI the caller tells me exists in WrapperBar really exist within its ABI?"

Also could come in handy when doing version verification, seeing if a minor upgrade is actually a super-set of the previous version's ABI.

[Niraj-Kamdar]

I am not talking about comparing 2 different ABIs, I am talking about comparing whether the objects or arguments are of valid types. Ex:

type Foo {
  prop1: String!
  prop2: Bar!
}

type Bar {
  prop1: String!
}

would require the following object to be valid

{
  "prop1": "Hello",
  "prop2": {
     "prop1": "World"
  }
}

But this would be invalid

{
  "prop1": "Hey",
  "prop2": "Polywrap"
}