As a general rule, be cautious when your external data representation is
one-to-one with your internal data representation. There is a risk of tight
coupling in this case. The wire format is not always how you want to handle
data internally in the application. The lure is that you can build a syste
i feel your pain. i have had exactly the same problem using protobufs over nats.
i think it comes down to the competing demands of the data representations of
different applications, and keeping a clean, minimal layout on the wire. i
ended up with a disappointing amount of boilerplate code per R
пт, 8 мая 2020 г. в 22:22, Robert Engels :
>
> Have the compute struct contain the proto struct.
>
I think that question is more about how to copy fields from one struct
to another. For example one struct contains some tags (for example to
work with some db orm), and proto struct don't have such t
Have the compute struct contain the proto struct.
> On May 8, 2020, at 1:56 PM, cheng dong wrote:
>
>
> i use protobuf to do rpc in golang . for every message XXX in proto, i have
> to define a struct XXX in go, compute and then copy its field one by one to
> pb.XXX（because struct XXX have
i use protobuf to do rpc in golang . for every message XXX in proto, i
have to define a struct XXX in go, compute and then copy its field one by
one to pb.XXX（because struct XXX have some field not in pb.XXX), when i
have many struct XXX, it is very ineffective and very slow.
so how could i us
