Application validation crate/API

[fibonacci1729]

Currently, the Spin CLI validates a Spin Application by applying various checks on a well-formed manifest, such as whether the correct key-value stores are enumerated, whether variables marked required are provided during deploy, and most recently, @itowlson put together #1623 to correct #1622.

It would be ideal if we could factor out a validation crate that could be shared by Spin, the cloud-plugin, and cloud. This issue is to start the conversation regarding the shape and contents of this shared code (i.e. what kind of checks make the most sense to be commonized).

[fibonacci1729]

cc @itowlson @lann @tschneidereit

[itowlson]

(I know we chatted about this elsewhere, but just to capture it.)

I'm sceptical of a specific, separate "validation" crate. I'd rather that validation rules lived with the stuff they're supposed to be validating, because "what is valid" is part of the nature of that stuff, not an external piece of knowledge that the stuff can consult. (For example, other parts of the stuff's code may rely on the concept of "what is valid", though if the external service did parsing rather than validating, that could mitigate that. But then the external service needs more knowledge of the type it needs to produce, and bang, circular dependency.) The problem then is how other code can consult the "what is valid" rules.

My preference here would be to allow selective imports, so a crate that needs to validate config keys can get hold of the Key type and use its validation rules, without having to pull in the whole config crate (and similarly for e.g. host names and the outbound-http crate). This keeps types cohesive while hopefully breaking dependencies.

As you note, care is also needed about what can be shared because the validations we perform in Spin and the cloud plugin are different. So we cannot clearly say "this is what it means for a manifest to be valid" - conceptually we have kind of a pipeline of:

Can we even read the damn thing
-> Is it syntactically valid (are key names or host names well formed, do component triggers match the app trigger)
-> Does it conform to the rules of this environment (e.g. cloud might disallow SMTP ports in host names, or non-default store names; local Spin doesn't need to check for incumbent variable definitions)

At the moment this pipeline is fuzzy (at best!) and not readily accessible - the cloud plugin (per the old deploy implementation) finds itself dealing with the raw on-disk manifest format all the way up the pipeline, I think because the full "validated load" does too much. It would be great to have the loader handle the first two stages of the pipeline, so that Spin, cloud, and other plugins could simply layer their environment-specific validations on top of that, and not be concerned about how the loader gets hold of the validation logic.

Thanks for raising this! I hope these rambling thoughts are useful.

[lann]

My preference here would be to allow selective imports

Could you clarify what you mean by this? Feature flags?

[itowlson]

Yes, features.