You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calling third party applications seems potentially error prone, since data
is not standardized in any way. The best case scenario, an app will have good
documentation, and a way to report back when called with missing values.
Proposal
To provide a clear API to consumers of an app, when triggering it from a remote
via .spawn. This can be done via runtime validation of the call options,
basically allowing the hub or io on the app side to verify the payload as soon
as the app calls .define.
From the spawned app point of view, it should be possible to define a validation
schema (in some form), for the options with types, default values and descriptions.
From the consumer point of view, the validation errors should be made available
as an easily understandable error object. This puts some requirements on the
validation library / functions being used.
Example:
io().spawn('Tradeshift.UserSelector',{internalOnly: 'true'}).then(([err,res])=>{// err: internalOnly should be boolean// err: companyId is required},err=>{// Should it be a "system" error, since it can be compared to a TypeError?});
Potential validation solutions:
Emphasis should be on the human readability of the errors, such that it's easy
to correct your mistakes, without needing to rely on (out of sync) documentation.
Problem
Calling third party applications seems potentially error prone, since
data
is not standardized in any way. The best case scenario, an app will have good
documentation, and a way to report back when called with missing values.
Proposal
To provide a clear API to consumers of an app, when triggering it from a remote
via
.spawn
. This can be done via runtime validation of the call options,basically allowing the hub or
io
on the app side to verify the payload as soonas the app calls
.define
.From the spawned app point of view, it should be possible to define a validation
schema (in some form), for the options with types, default values and descriptions.
From the consumer point of view, the validation errors should be made available
as an easily understandable error object. This puts some requirements on the
validation library / functions being used.
Example:
Potential validation solutions:
Emphasis should be on the human readability of the errors, such that it's easy
to correct your mistakes, without needing to rely on (out of sync) documentation.
Exploring the API, this could be something like
I like the plain object style, since it doesn't impose more libraries.
For
ajv
we have some formatters inv4
to make the errors more user friendly.The text was updated successfully, but these errors were encountered: