Open-EO / openeo-js-client

JavaScript and TypeScript client for the openEO API.
https://open-eo.github.io/openeo-js-client/latest/
Apache License 2.0
15 stars 6 forks source link

Check validity of process arguments based on JSON Schema #48

Open jonathom opened 3 years ago

jonathom commented 3 years ago

I submitted a filter_bands process as so: var red = builder.filter_bands(cubes, "B04"), which is accepted and passed to backend (VITO). The process graph then contains

"filter1": {
      "arguments": {
        "bands": "B04",

Which causes a problem in the execution: Invalid band name/index 'B'. Valid names: ['VV', 'B02', 'B04', 'B08'] When I submit the process like this, as intended by specification: var red = builder.filter_bands(cubes, ["B04"]) everything works fine.

Should that throw and error upon submission? In a quick search I also couldn't find documentation for filter_bands, doesn't look like it's in this repository.. why's that?

m-mohr commented 3 years ago

The processes are built automatically from the process description the back-end returns, which is more flexible then the hardcoded variants e.g. in Python. On the other hand, it's less easy to "customize" and improve the experience. That's why you find them in the Python code, but not in JS or R.

What I'd need to do here is to check the values against the JSON Schema for the parameters. I did not do that because it adds another dependency (ajv) to the JS client. But it's actually a good idea to have that in the repo and as a potential improvement for the future.

m-mohr commented 3 years ago

This is actually not as easy as it sounds like on first sight.

I tried client validation using openeo/js-processgraphs, but for that I'd need to request all the user processes, which can result in a lot of HTTP requests.

If I do it "on demand" (per parameter), I'd need to first check the back-end processes and if not available, I'd need to load the user-defined process. This makes the process builder methods async, which is undesirable.

For now, I've decided against the validation and moved it to milestone 3.0.0 for now.