Consider using Buf to manage Protobuf and its artifact

[spencercjh]

I've been following the pingcap community on Twitter for a long time, but only briefly know some active developers. I am not familiar with developing databases but gRPC services and using Protobuf.

I find there is huge space for improvement in the way to manage Protobuf from TiSpark.

Use buf to manage protobuf codes instead of raw git clone operations and protoc code generation scripts.

With BSR, Go's Protobuf dependency reference becomes very simple with one line like this(it's an internal example in our team):

With another language like Java, working with Java BSR plugin, you can generate Java codes from Protobuf without protoc directly and publish the artifact to a repository like Maven Center or GitHub Package then depend on it with Maven or Gradle.

I am not a lobbyist for Buf. I'm writing this Issue due to my curiosity about the pingcap team and my enthusiasm for your community. And I am a newbee to open source, I want to participate in some very COOL open source communities.

Our team has been using gRPC for years, following the work of the community about gRPC and Protobuf like Envoy,AIP and Buf. Because of dependencies from other technical teams, we used to look at how we could better maintain and use Protobuf and its artifact using Bazel. Buf is a lighter-weight solution that fits the Go language perfectly compared to Bazel.

If you are interested in learning about it and find it meaningful and useful, I am willing to contribute.

[spencercjh]

Due to the community ecology and target orientation, Buf has the best support for Go languages and JS/TS, and other languages will be weaker.

[spencercjh]

I believe the more communities like pingcap use Buf, the better Buf will become, and the more people/organizations using gRPC and Protobuf in China will grow. We will be able to gain a better development experience.