Looking for a reverse protobuf compiler to generate .proto from go types

agolangf · · 560 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>We&#39;re working on a <a href="https://github.com/tendermint/tendermint/" rel="nofollow">fault tolerant distributed consensus engine</a> and are starting to adopt protobuf/grpc. But I don&#39;t want to replace all my types with protobuf generated types (they&#39;re ugly) and I don&#39;t want to manually maintain types in both go and protobuf (the pain!). An amazing solution could be to compile all go types from some package/s to a .proto file that can then be used for grpc or implementations of the software in other languages. Does this exist?!</p> <hr/>**评论:**<br/><br/>robpike: <pre><p>Protocol buffers work best when they rule your data structures. For some that is an acceptable approach; for others it is an annoyance. It&#39;s a matter of expectations: yours vs. protobufs&#39;.</p> <p>In other words, no. You must either pay the price of conversion or use the &#34;ugly&#34; and constraining data model they provide.</p></pre>sercand: <pre><p><a href="https://github.com/kubernetes/kubernetes/tree/master/cmd/libs/go2idl/go-to-protobuf" rel="nofollow">https://github.com/kubernetes/kubernetes/tree/master/cmd/libs/go2idl/go-to-protobuf</a> Kubernetes has this stuff in their repo, but I don&#39;t know how to use it</p></pre>icholy: <pre><p>I don&#39;t think this can work. Say you generate a .proto file from an existing struct. Then use protoc to generate the serialization/deserialization code. The generated code won&#39;t work with your original structs, but with the similar (probably not identical) structs the codegen gives you.</p></pre>work2heat: <pre><p>right. at least at first I just want it for use in RPC args/return values, ie. so I can use grpc, so I don&#39;t think that&#39;s an issue. But you&#39;re right that actually using it eg. for other implementations will not be straight forward</p></pre>icholy: <pre><p>If you want to keep using your original structs throughout your code, you&#39;ll need to write code that converts between your original struct and the protobuf struct every time it interacts with grpc. I&#39;d just use the protobuf struct everywhere.</p></pre>beertocode: <pre><p>Random thought. How about generating the .proto files on the fly, instead of trying to make a program understand static code.</p> <p>You could write an interceptor/ middleware one can put in between every RPC call, which logs the input and output. Program then can turn those logs into .proto definitions.</p></pre>chuhnk: <pre><p>No it doesn&#39;t exist. I was looking for this for my own project <a href="https://github.com/micro" rel="nofollow">https://github.com/micro</a> but there doesn&#39;t appear to be an easy way. </p></pre>timetravelhunter: <pre><p>You could create your own descriptors to put on your protobuf messages..</p> <p>something like:</p> <p>golang_package =&#34;stuff/mypackage&#34; message { required string name [(golangType=&#34;string&#34;)] required int age [(golangType=&#34;int&#34;)] }</p> <p>then write a simple struct to proto converter. You could have plenty of defaults so you don&#39;t need to add descriptors to every line.</p></pre>MistakenForYeti: <pre><p>I think Commander Pike is right here. You need to generate the specs/schemas first and let that flow down into your code. </p> <p>I&#39;ve also found that .proto files generally aren&#39;t quite enough when attempting to thoroughly document every single field and having a conversation with a team (i.e. client iOS users) about the schema.</p> <p>(pitch time!) I&#39;ve actually found Swagger and Open API to be much better suited for conversations around schemas, but we still wanted to utilize Protobufs and gRPC. This is why we created <a href="https://github.com/NYTimes/openapi2proto" rel="nofollow">openapi2proto</a>. It allows us to have our conversation about data in Swagger (with the Swagger editor even!) and then generate all the things we need from it. </p></pre>nosverratdu: <pre><p>For our <a href="https://github.com/dedis" rel="nofollow">projects</a> we wrote a <a href="/protobuf" rel="nofollow">library</a> based on reflection which (at least to some extend) does what you describe. I would say: our lib is great for rapid prototyping but it has quite some downsides and especially the feature you are describing (generating .proto files) <a href="https://github.com/dedis/protobuf#generating-proto-files" rel="nofollow">exists</a> but isn&#39;t really well tested (at least we don&#39;t really use it). </p> <p>But I also agree with Rob&#39;s <a href="https://www.reddit.com/r/golang/comments/4p9i51/looking_for_a_reverse_protobuf_compiler_to/d4jgkci" rel="nofollow">view</a> here.</p></pre>I_HATE_SPIES: <pre><p>Just add &#34;proto&#34; tags to your structs and use this: <a href="https://godoc.org/github.com/golang/protobuf/proto" rel="nofollow">https://godoc.org/github.com/golang/protobuf/proto</a></p> <p>(or am i missing something here?)</p></pre>icholy: <pre><p>I don&#39;t think it works like that.</p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

560 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传