client-side newtype validation

[clux]

A problem that came up in #653 in #653 (comment) is about if / where / and how we should do client side validation.

In that PR we went with:

• yes, we should do it when wrapping kubernetes apis (api params that we hand roll + runtime abstractions)
• we should do it through own error type

Client-side validation is not something we can truly keep up to date with kubernetes code since it's not found in the protos or the swagger.json.

The amount of code for each newtype is a bit troubling to me though. Particularly given the uncertainty of longevity.

So question is, should we scrap this. Or should we improve this? Some things I can think to improve it would be:

• derive-more for some of the impls
• snafu for the error type
• macroify the pattern

Ultimately there's only 3 bits of information encoded here: error name, error string, validation.

[nightkr]

I'd say no, validation is generally the server's responsibility (unless it causes, say, a serialization problem locally).

…

On Sun, 17 Oct 2021, 12:38 Eirik A, ***@***.***> wrote: A problem that came up in #653 <#653> in #653 (comment) <#653 (comment)> is about *if* / *where* / and *how* we should do client side validation. In that PR we went with: - yes, we should do it when wrapping kubernetes apis (api params that we hand roll + runtime abstractions) - we should do it through own error type Client-side validation is not something we can truly keep up to date with kubernetes code since it's not found in the protos or the swagger.json. The amount of code for each newtype <https://github.com/kube-rs/kube-rs/blob/14033ba1ac723d1be88ed921c69b00b39495f6d9/kube-runtime/src/events/event.rs#L99-L161> is a bit troubling to me though. Particularly given the uncertainty of longevity. So question is, should we scrap this. Or should we improve this? Some things I can think to improve it would be: - derive-more for some of the impls - snafu for the error type - macroify the pattern Ultimately there's only 3 bits of information encoded here: error name, error string, validation. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#654>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE6U2EFCTTVDNEUZQYKDSLUHKRQTANCNFSM5GEVM4PA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.