Comments (4)
cc @itowlson @lann @tschneidereit
from spin.
(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.
from spin.
My preference here would be to allow selective imports
Could you clarify what you mean by this? Feature flags?
from spin.
Yes, features.
from spin.
Related Issues (20)
- OTel features overwhelmed during high load HOT 5
- Build failed (aedc2b8ccc65f41615fa7beb3e427843dd782114) HOT 3
- Spin 2.6 release HOT 11
- Spin apps are no longer allowed to set host headers with Wasmtime 21.0.1 HOT 6
- Enable mustache-inspired string templates for `key_value_stores` and others HOT 6
- Add version control support to `spin new` or spin CLI HOT 12
- Rust and Python traces with KV store are not showing all KV spans in the same trace
- Remove HTTP trigger `base` option
- Consider deprioritizing the environment variable provider HOT 6
- Add `spin up --trigger-type` flag
- Enable pushing components with `spin registry push` HOT 3
- `spin login` keeps asking for one-time code after authorizaton HOT 6
- `spin --tree` or `spin --list` providing a tree structure of available subcommands and flags in spin cli HOT 3
- hello-python not working HOT 12
- Added flexibility to Spin allowed outbound hosts
- inconsistencies when making outbound http requests HOT 1
- Custom trigger with other WASI worlds requires trait implementation for `spin_core::Data<T>` HOT 2
- Add an S3 key/value storage provider interface HOT 3
- SQLITE error after update from 2.5.1 to 2.6.0 HOT 3
- spin can not login docker private registry while docker login success HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spin.