5 ms·
One thing I hate about GRPC with Kotlin is the crap of get set that it generates for Request/Response payloads. I've always wanted to used basic POJO objects an
by maxpert 8y ago
One thing I hate about GRPC with Kotlin is the crap of get set that it generates for Request/Response payloads. I've always wanted to used basic POJO objects and this might solve my problem. Although I've seen some unmaintained Kotlin generators for GRPC there is no battle tested solution and this post just might solve my problem. Jackson is performant enough for me.
- throwexceptionz 8y agoCan you elaborate on what these getter setters look like?
- willeh 8y agoI think he is referring to the fact that you use a fluent builder interface when building protobuf messages so you chain together a bunch of `.setFoo(myFoo).myBar(myBar).build()` to build your protobuf, while in Kotlin it is idiomatic to write `foo = myFoo` and `bar = myBar`. There are ways around this with `.apply` in Kotlin, but it all feels really clunky. That said if you want a systematic don't make me think approach for backward and forward compat I think protobuf/GRPC is the way to go you just need to learn a few rules for how to do it and you're set. In terms of static typing protbuf doesn't really get you that much because in order to get backward/forward compat you can't have required fields, so everything needs to be null-checked or have default values.