[Question] How can I avoid forcing protovalidate on to the consumers of my API?

[Diggs]

I'm looking at implementing a standard proto validation pattern for my gRPC API server, which I imagine is a fairly typical use case. protovalidate looks fantastic - CEL gives me a lot of flexibility and I like the idea of describing validation rules alongside the schema. The issue I have is that once I've adopted protovalidate in my .protos, consumers of my protos, or code generated from them, are now on the hook for taking a dependency on protovalidate in their project. Further, it seems if protovalidate doesn't support their language of choice, they can't consume my protos at all.

Is there a way to use protovalidate for server-side validation while allowing consumers of the proto definitions to opt out?

[rodaine]

Hey, @Diggs! Thanks for the thoughtful question. The protovalidate protos are just like any other protos and dependencies that you might have in a project. The options you add to a messages and fields to annotate protovalidate rules must come from somewhere.

We did not want to use comments or a secondary file as the former provides no structure and cannot be validate prior to compile time effectively (e.g., buf lint and our IDE plugins will detect errors in these options), and the latter decouples the semantics of your API from the type definitions. The protovalidate rules are just as much documentation for your API as they are used by protovalidate implementations.

All that said, because protovalidate does not use code generation to perform validation, any code that does not use or doesn't support protovalidate will not be affected by its presence; they will be treated as types and option extensions like any other protos you might use. It will require consumers to have the protovalidate protos available (ideally through the BSR, but could be manually included as a build step if necessary) in order to build however, which you'd already need for other dependencies as well.

I hope that answers your question! Let me know if there's anything I could clarify further.

[Diggs]

@rodaine thank you so much for the detailed response - I appreciate how much time it can take. That does answer my question very thoroughly, thanks.

My frame of reference is one where projects typically produce dependency-free protos (sans some occasional dependency on Google's well-known types), and so I haven't been exposed to supporting a proto dependency graph in any meaningful sense. I can see how the BSR coupled with protovalidate's approach to being "just another proto" makes my question moot.

[rodaine]

I definitely agree that ideally something like protovalidate would be built into the language so we wouldn't need to have the dependency.