This is not the exact answer to your question but we can do something like this to share common parameters. message Child1 { required int c1 = 2; required string c2 = 3; } message Child2 { required int c1 = 2; required string c2 = 3; } message Request { required string common1 = … Read more
The following applies for ‘proto2’ syntax, not ‘proto3’ : The notion of a field being set or not is a core feature of Protobuf. If you set a field to a value (any value), then the corresponding has_xxx method must return true, otherwise you have a bug in the API. If you do not set … Read more
In general, Bond has better type system and supports multiple protocols. In particular, pros are: Bond supports generics Bond has different types to represent collections: vector<T>, map<T>, list<T> Bond supports type-safe lazy deserialization (bonded<T>) Bond supports multiple formats (fast binary, compact binary, XML, JSON) + marshaling and transcoding Cons: Bond doesn’t support different types for … Read more
I would suggest storing the .proto files in a separate project. These are the contract between your two projects, and they are not necessarily “owned” by either one. Storing them in a separate project provides neutral ground for both project members to negotiate changes to the files – for example through a pull/merge request process … Read more
For large binary transfers, the standard approach is chunking. Chunking can serve two purposes: reduce the maximum amount of memory required to process each message provide a boundary for recovering partial uploads. For your use-case #2 probably isn’t very necessary. In gRPC, a client-streaming call allows for fairly natural chunking since it has flow control, … Read more
I very much doubt that it will ever have direct language support or even framework support – it’s the kind of thing which is handled perfectly well with 3rd party libraries. My own port of the Java code is explicit – you have to call methods to serialize/deserialize. (There are RPC stubs which will automatically … Read more
The impl.MessageState is embedded in concrete messages only, not in the generated structs that implement a proto message. It specifically embeds the three pragmas: NoUnkeyedLiterals, DoNotCompare, and DoNotCopy. The last one, DoNotCopy is a zero-sized array of sync.Mutex. The sole purpose is to have go vet complain loudly about shallow copies, as described in the … Read more
No, you cannot use a primitive type as either the request or response. You must use a message type. This is important because a message type can be extended later, in case you decide you want to add a new parameter or return some additional data.
TL;DR: It’s possible, but it does not generate a compiler warning. Consider to use field-level deprecation. It looks like it’s possible to add a deprecated option to a service, just like on a message and enum like: service MyService { rpc GetThings(GetThingsRequest) returns (GetThingsResponse) { option deprecated = true; }; } Found this in: https://github.com/google/protobuf/issues/1734 … Read more
You can use the class google::protobuf::util::MessageDifferencer for this. I think it’s only available since v3.0.2: Introduced new utility functions/classes in the google/protobuf/util directory: MessageDifferencer: compare two proto messages and report their differences. #include <google/protobuf/util/message_differencer.h> MessageDifferencer::Equals(msg1, msg2);