protoc-gen-validate
protoc-gen-validate copied to clipboard
bufbuild
RFC: Your PGV Wishlist
The team at @bufbuild are excited to begin maintaining PGV.
This project fills a huge gap in the protobuf ecosystem and deserves careful stewardship. As a company, our incentives are well-aligned with the PGV community's. We want protobuf to be feature-complete and easy to use for personal projects, tiny startups, and giant megacorporations alike, because wider protobuf adoption increases the market for our paid schema registry product. We will take care not to break existing PGV users, and we can devote enough time to the project to clear out the issue backlog and possibly support additional languages. We will, of course, keep everything under an Apache 2 license.
We appreciate the PGV community's continued paitence whilst we iron out a detailed transition plan and thank the @envoyproxy team for all that hard work they've put in to date.
Right now, we want to hear from you - What do you want to see from PGV? What major bugs have you run into and would like to see fixed? Or better yet, what have you already fixed that you'd like merged?
Some more color on the Ruby ask by Sarah. We use protobuf schemas heavily at Chime in general, and have lots of Ruby on Rails services that we actively want to move to Protobuf + Twirp. Autogeneration of parameter validation code will really DRY-up our APIs and help with better documentation too by making the semantic rules explicit. We'd greatly appreciate you prioritizing building support for Ruby in this tool. Thank you for taking ownership of PGV and really excited about its evolution!
I would love to see issue https://github.com/envoyproxy/protoc-gen-validate/issues/74 resolved.
Not having all valid issues closed without any resolution, since those were wishes. 😝
Should or could we re-open specific issues that had good context and we're good wish list items, for example: https://github.com/bufbuild/protoc-gen-validate/issues/405
Hi everyone! This is my fault, after recently taking over maintenance of PGV with 100 issues and 30 open PRs, trying to get a grasp of the current state of the project has been tricky and after a month of fixing various bugs, some tickets I thought were stale or resolved may have been caught up in the mix.
I'll go back over the issues I closed and reopen any that stand out. If I miss any, please don't hesitate to reopen any of particular interest yourself.
But this is a good thing, whilst jagged, all of this helps me and the team develop a deeper understanding of where the project should go and where we should focus our attention immediately.
I would love to see official plugin for buf and more string rules such as alphanumeric etc. Thank you for your hard work! Love the project 💙
Better structure for validation errors. When validation fails on a deeply-nested message instead of a massive string it'd be great to see JSONSchema-style errors with structure that can be handled by client code.
Combined validations. E.g. if name = John, then age must > 50. Silly example, but it explains the idea.
message Person {
string name = 1;
int32 age = 2;
}
Real world example , we have an enum that determines whether this repeated should have size 1 or not.
- make it possible to have a validation rule on both map keys and values. currently, only one of them is honored.
- typescript support, ideally so it can be used in combination with connect-web and/or ts-proto.
I would like to be able to generate a JSON schema that includes validation rules specified using validate.rules.
Some options I can thing of:
- Generate some language neutral output that can be used from
protoc-gen-jsonschema - Change
protoc-gen-jsonschemato understand the rules specified withvalidate.rules. - Change protoc-gen-validate to generate JSON schema.
None of these options are great though. Would like to know what others think.
Closed issue relating to this request:
- https://github.com/bufbuild/protoc-gen-validate/issues/615
I would like to be able to validate a stream of protobuf messages using protoc-gen-validate annotations without writing some custom code.
Export of validation rules to JSON-schema is the most needed feature in my opinion. I would like to use this so that front-end developers get the validation rules from the proto, and not duplicate them themselves.
@elliotmjackson any timeline for the new release? The last release was on December 2022.
Hello everyone!
I am excited to announce the release of protoc-gen-validate (PGV) v1.0! After half a decade of being labeled “alpha,” we’ve decided it’s time to promote PGV to v1.0, ensuring stability for all current workflows. 🎉
But that’s not all! We’re also announcing the imminent release of the future of validation: v2.0 of PGV, soon to be known as protovalidate. This new version, with its first release candidate coming in early June, will be based on Common Expression Language (CEL) and provide a much better foundation for validation going forward. :rocket:
In our latest blog post, we reflect on PGV’s history, discuss its limitations, and give you a sneak peek into the exciting features we’re working on for protovalidate. Check it out here: Announcing protoc-gen-validate v1.0 and our plans for v2.0
As always, your feedback is invaluable to us. So please, take a moment to read the blog post and let us know your thoughts. Feel free to share your ideas or feature requests in this wishlist GitHub issue.
Thank you for your ongoing support, and we look forward to hearing from you as we continue to shape the future of Protobuf validation together!
In terms of feature requests/wishlist, have you given any thought to message-level rather than field-level validation? For example, google.type.Date says:
// This can represent one of the following:
//
// * A full date, with non-zero year, month, and day values
// * A month and day value, with a zero year, such as an anniversary
// * A year on its own, with zero month and day values
// * A year and month value, with a zero day, such as a credit card expiration
// date
It would be nice to be able to write a message option to express/enforce this, e.g. (year > 0 && month > 0 && day > 0) || (month > 0 && day > 0 && year == 0) || (year > 0 && month == 0 && day == 0) || (year > 0 && month > 0 && day ==0).
Validation rules on methods! Without this, it makes it really hard to define validation rules on messages that are intended to be shared between more than one endpoint, even if said messages only form part of a request.
Validation transferral
Really just throwing this idea out there. I would like the ability to say "Copy the validation rules from {name}", where name is the symbol of a proto message, eg: foo.bar.v1.Message.field.
A way to provide sample values would be great. These are useful for e.g. generating sample code snippets for APIs.
Arguably this is beyond the scope of validation, but on the other hand it does feel somewhat related, in the sense that the sample values should certainly pass the validation rules (and an API linter might want to validate such a thing).
Our team would love to have support for the C#/.Net ecosystem
gRPC and proto files are cross-platform and supported in many languages but, so far, PGV does not support C# despite being one of the most popular languages. Having PGV support C# would greatly help in making gRPC a modern alternative to SOAP when it comes to interoperability across technical stacks for services that needs to be defined with rich data validation rules like it is possible in XSD for SOAP.
This is great news! Some ideas I've been chewing on:
-
Some sort of ternary logic similar to SQL check constraints where evaluating a null (missing field) is ignored.
-
Define validation on methods, messages, and fields. Defining validation on methods and messages supports cross-field validation.
-
An optimizing expression compiler. A validation like
val > 10should compile into an if statement. Alternately, use reflection to keep generated code size down. -
Support custom CEL methods.
That looks promising !
I had a similar approach in my protoc-gen-cel-validate validation plugin built around CEL. Here are some features that I was able to implement and that might be useful here:
- Add the possibility to validate nested messages from CEL directly
- Support partial validation functions, with something like fieldmasks
- Support function overloads (registering functions in the CEL runtime from code)
- Having a way to reuse CEL constants / variables / functions to avoid duplication
