4 ms·

I'd recommend transforming protobuf types to domain types at your API boundary. Then you have domain types through the whole application.

mxey 2y ago
At which point I loose all the benefits of lazy decoding that the accessor methods can provide, so I could just decode directly into a sensible struct, except you can’t with Protobuf.
- mort96 2y ago
  Accessor methods aren't for lazy decoding but for more efficient memory layouts.
  - aktau 2y ago
    Both, actually. Without accessor methods, laziness couldn't be implemented.
  - mxey 2y ago
    But that will also not transfer over to the domain struct
    - mort96 2y ago
      Well it depends. If your data model doesn't include "this bool is optional", you can just include the bool directly in the struct and get all the memory layout advantages, and then you decide in your protobuf -> domain type conversion code whether it's an error if that field is missing or if it just defaults to 'false'. You only need to make ways for a field to be optional (such as naming it a pointer where nil represents "missing") when that actually makes sense in your data model.
AYBABTME 2y ago
I found that this ends up being a giant amount of useless code, and a ton of memory allocation noise, that only satisfied my desire for elegance. I've given up that approach and just use protobuf types throughout as the base type. I got sick of writing dumb conversion funcs.
- mrbadguy 2y ago
  It’s fairly mindless boilerplate for sure, but it does mean that when something happens that causes a change like this protobuf update, the change in your codebase is isolated just to the interface between it and your code ie your dumb conversion funcs. Otherwise you end up with the problem the original commenter had. It’s good to isolate your dependencies within the code :)
matrix87 2y ago
I've done this, it only makes sense to me if you're trying to recycle some legacy code that's already using the domain types. Or else there's a bunch of extra conversion logic and unnecessary copying, feels like an antipattern

mxey 2y ago

At which point I loose all the benefits of lazy decoding that the accessor methods can provide, so I could just decode directly into a sensible struct, except you can’t with Protobuf.

mort96 2y ago
Accessor methods aren't for lazy decoding but for more efficient memory layouts.
- aktau 2y ago
  Both, actually. Without accessor methods, laziness couldn't be implemented.
- mxey 2y ago
  But that will also not transfer over to the domain struct
  - mort96 2y ago
    Well it depends. If your data model doesn't include "this bool is optional", you can just include the bool directly in the struct and get all the memory layout advantages, and then you decide in your protobuf -> domain type conversion code whether it's an error if that field is missing or if it just defaults to 'false'. You only need to make ways for a field to be optional (such as naming it a pointer where nil represents "missing") when that actually makes sense in your data model.

AYBABTME 2y ago

I found that this ends up being a giant amount of useless code, and a ton of memory allocation noise, that only satisfied my desire for elegance. I've given up that approach and just use protobuf types throughout as the base type. I got sick of writing dumb conversion funcs.

mrbadguy 2y ago
It’s fairly mindless boilerplate for sure, but it does mean that when something happens that causes a change like this protobuf update, the change in your codebase is isolated just to the interface between it and your code ie your dumb conversion funcs. Otherwise you end up with the problem the original commenter had. It’s good to isolate your dependencies within the code :)

matrix87 2y ago

I've done this, it only makes sense to me if you're trying to recycle some legacy code that's already using the domain types. Or else there's a bunch of extra conversion logic and unnecessary copying, feels like an antipattern