phero VS protoc-gen-validate

That's one of the reasons that drove me to create Phero: https://phero.dev

I’m one of the authors of Phero. It’s goal is similar to tRPC: fullstack typesafety between servers and clients.

One difference is syntax: Phero leverages the TS compiler api to generate parsers for your backend functions. It will parse input and output or your api, automatically, based on the types you define for your functions. It will generate a declaration file of your api and generate an RPC style client SDK for your frontend. Another difference is that it aims to be more batteries includes.

[1] https://github.com/phero-hq/phero

Comparison: https://phero.dev/docs/comparisons/tRPC

Shameless plug: you could also use https://phero.dev

Long story short: when fetching data, you should be validating the data, before casting it to a type you’re expecting it to be. There are a lot of different approaches for this, but being the go-author my favorite would be Phero (https://phero.dev). With this, you can build your API in typescript as well, automatically generate a client for your frontend to call the API. Phero will make sure all data is correct in runtime, automatically.

For those looking for an alternative: Definitely check out https://phero.dev. As the co-creator I’m totally biased of course, but thanks to its build-step IDE-performance is great 😊👍

What about Phero? https://phero.dev

Can we add Phero to the list? :) https://github.com/phero-hq/phero

You can use Phero. You can use it on your backend and frontend. It basically created a typed API from your backend afaik

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.