cloudevents
Suggestion for extension attribute: strict (or validateStrict or similar)
Hi all, in my JavaScript/Node.js library for manage CloudEvents here, inside extensions I'm using an attribute 'strict' that when set to true (default is false) some additional validations will be done on the new created CloudEvent instance (but it's possible to validate an instance even later, without or with that 'strict' mode); this is useful for example during development, to better identify bad/wrong CloudEvent instances. Note that when set (for example in some "important" CloudEvent instances) I keep that flag into the extensions attribute of the instance, so it will be possible to reuse later.
Do you think it could be a good addition to extensions ?
Tell me if you need more info or context/examples.
Regards, Sandro
What do you do when "strict" is false and what do you do when it is true? I would think of this is a configuration setting inside the producer or consumer, but not as a setting that goes across the wire. Would an event be able to instruct the consumer to turn a blind eye on potential spec violations?
Hi, by default "strict" is false, but when enabled I force a check on some mandatory arguments at the end of the constructor; and when manually invoking a validation if "strict" is true I perform some more checks on attributes. That setting is saved under extensions (only when true) because when I serialize CloudEvents instances I could read it later and check/reprocess, but maybe this is too much.
In a similar way, in serialization/deserialization functions I added an optional argument to serialize/deserialize only if validation is successful on that CloudEvent instance; in some cases even this has been useful.
I'm finding this behavior good in my tests (both when creating CloudEvents instances, and even when receiving from other sources), for example setting it to true in DEV environment, and in some cases specifying it true only in some important events are raised/processed... but I understand that couls be good only for my usage.
Hope you like the idea; of course be free to close the issue if you don't think it would be useful in general.
Thanks, Sandro
Can you elaborate on the validation you're talking about? Is it validation against the CloudEvents spec, or validation against some business logic? If against the CE spec then I would think that should be done all the time and a flag wouldn't be needed. If you mean validation against some business logic, is this something that you want a on per-Event basis? I would think that this would be more like an environmental configuration option because otherwise you're requiring the code that produces the event to turn it on - but I would think that you'd want it on (or off) for all the time, not just for certain events. But perhaps I'm not understanding your scenario.
Also, this just validates outgoing events, not incoming one, right?
Hi, the validation is done against my implementation, and when the 'strict' option is raised more validation are done (for example even in the constructor in this case, so not valid CloudEvent instances won't be created). But I'd prefer to keep this flag by default disabled for more speed (less overhead) when creating and use instance, because many times once things has been tested deeply, all should be fine (generally speaking). So I added the ability to specify that flag only when needed (for example only for certain kind of "important) instances. But I agree my that probably use case could be simplified. Another use case that I tried to cover was a CloudEvents Gateway, so some events are generated internally by my code (so lett strict requirements after code stabilization) and others from outside systems.
Note that once this flag is raised I could use it in other places; for example I can perform automatic validation checks even when serializing/deserializing Cloudevents instances.
Just for info, my library has many unit tests (using Tap), but for a webapp example there is a sample example script in fastify-cloudevents (in the 'example' folder); I have other usages too if needed.
If you need more info I'd be happy to provide ... thanks for the feedback for now.