ozzo-validation VS protoc-gen-validate

go-ozzo/ozzo-validation

https://github.com/go-ozzo/ozzo-validation Seems to do what I need but likely will need some convoluted reflection to build out the rules. Also likely some custom rules to be written which is okay since it's a one time cost and reuse in the expressions.

Personally I use ozzo validation: https://github.com/go-ozzo/ozzo-validation

This looks useful, but what differentiates it from something like https://github.com/go-ozzo/ozzo-validation ? Why would I use Valgo over something battle tested that follows a very similar pattern?

This is where it gets spicy: I just don't get at all who ever though this struct-tag based validation library was a good idea https://github.com/go-playground/validator - and yet it's the most mainstream one. Try to implement your own type, you're up to register some global validation tag and repeat it every time you're using that type. I'm grateful https://github.com/go-ozzo/ozzo-validation exists, that's what I use. But it's still way behind the other things I mention, where in general, it's simply not possible to pass around an invalid struct - because it can't be built if it's invalid in the first place.

Gin comes with built-in "validation", while Echo recommends the same validator. I am also not a fan of magic struct tags, so I would probably prefer either writing my own or using something like ozzo.

Other packages of note: https://github.com/uber-go/zap https://github.com/go-ozzo/ozzo-validation

Does https://github.com/go-ozzo/ozzo-validation meet your requirements?

https://github.com/go-ozzo/ozzo-validation/blob/v3.6.0/struct.go#L61

My understanding is that the powers that be within Google have decided that validating messages is outside the scope of schemas and serialization. protoc-gen-validate provides a portable way to perform validation: https://github.com/bufbuild/protoc-gen-validate

The problem with required fields is it kicks the can down the road when you want to deprecate a field. Keeping everything optional is much, much better for everyone in the long run.

I built a (go) very rough draft to support 3.1 + a json pointer pkg to support a refactor that was in progress before I bailed on the idea. The amount of effort to get a conventional API was dwarfing that of grpc, especially with protoc-gen-validate.

Yes, I am currently using this. I prefer something like this https://github.com/envoyproxy/protoc-gen-validate

We've been using Rust with protobuf, but had to write lots of conversions from protobuf struct to actual DTO, since prost generates Options for nested types, and does not really support custom types. So I extended prost with the options that we needed. I might aim to also support protoc-gen-validate.