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 system which automatically does a conversion here. Either by macros, by generating code or some other way of avoiding the boilerplate programming you have to do. Yet, there tend to be a point in the systems growth where this automatic conversion breaks down. If you never reach that point, you win. But if you ever reach it, you are in trouble.
If your marshalling format were just a tad less expressive, as in being strings or JSON, you would likely write some interpretative code to intern the data from the outside source. This is worth considering, now you have a more expressive format at your disposal. I often structure such code with a lower and upper half. The lower half is faithful to the external world. The upper half provides a higher-level abstraction on the data which is highly amenable to the application at hand. By converting in the boundary layer of the application, you can often reduce the internal application complexity by a lot and in some cases this yields a far simpler program. Programming is, in many cases, the quest for a good data representation. If you have the right structure, the program algorithms almost writes themselves by analysis of the data at hand. Which is why I am a bit weary when people want easy boilerplate automation. On Wed, May 20, 2020 at 10:20 AM Steve Simon <quint...@gmail.com> wrote: > 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 RPC. > > i decided this is the price i have to pay for the type security that > protobufs offer. if anyone comes up with a clean solution i would be > interested. > > -Steve > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/dc6ff8cd-a52a-49a4-8c28-4d0259293ad1%40googlegroups.com > . > -- J. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiUJaSp1QK86SjZCejuKBc8u_xVWk2-%2BNDXAb0dTVUzdpA%40mail.gmail.com.
