Future vision and stability

[Dogacel]

What is the future vision of this library? What are the missing features that you are willing to add and any new features you are willing to add?

For stability, I think this library looks pretty good and I am thinking about using this in production environments, but there are several caveats,

1. I am unsure about stability and correctness of the api considering Fix flaky WellKnownTypesTest junit tests #13 and demonstrate recursion and stackoverflow error #19.
2. I am not sure about how well this will be maintained and whether this is gonna be used by any big project / company.
3. Conformance tests.

Those little thinks add some confidence to me. I really appreciate the work and enthusiasm and will be more than willing to help 👍 I think kotlin - protobuf compatability is something that definetly have a lot of room for improvement.

For example, can you think about reasons for using this project over https://github.com/streem/pbandk or https://github.com/open-toast/protokt?

[mscheong01]

Hi @Dogacel 👋 Thanks for your attention and interest in krotoDC. Here are some information that could help you if you're considering krotoDC for your production services:

• There indeed are some knobs left to tweak, like the issues you mentioned. The current major issue is Add option to make message type fields always nullable #9 which exists due to KrotoDC not handling message type fields as nullable by default which goes against the proto3 premise. I'm thinking of releasing this as v1.1.0, although I don't have a fixed deadline. Other issues like [discussion] compatible with two cases #16 also have to be handled, although these issues occur in specific cases that you would not likely encounter.

• My former company, Mathpresso already uses krotoDC in production. Another use sight I am currently aware of according to Github search is prometheus-proxy. Since I'm also adding an example of krotoDC with Armeria in the line/armeria repo, hopefully more users will emerge. I'm currently back to being a full time student at my university, so all maintainership will be done in whatever time I can spare. Which means that if I'm busy from maybe an exam or other work for payed contracts, I may not be able to react immediately. If krotoDC becomes popular and needs a lot of work, I could maybe receive sponsorship in order to secure the resources needed to maintain this project, but there aren't any plans to do so yet.

• krotoDC vs pbandk, square/wire, protokt: The main advantage of krotoDC is that the stubs that it provides operate exactly the same as that of grpc-kotlin, except for the fact that you can use protobuf classes as krotoDC generated dataclasses. krotoDC also enables access to official protobuf-java features(ex: protobuf serialization) by supporting auto-generated converters. Thus, we don't have our own implementation for these features which prevents it from going wrong completely. I'm aware of other thirdparty Kotlin/gRPC code generation libraries, but pbandk doesn't generate gRPC stubs for you and square/wire has a slightly different gRPC service code compared to grpc-kotlin (does no use Flow for streamed messages, stub response is wrapped with GrpcCall or GrpcStreamingCall, etc) although they have an edge of being multiplatform and support both proto2 and proto3. I wasn't aware of protokt, but took a quick look at its readme and found out that it too has slightly different generated service code: gRPC service methods are received as constructor parameters, not implemented as abstract methods, bindService method has to be defined every time.

In conclusion, although I cannot confidently say that krotoDC is the best one out there, I think that its API would be comfortable to grpc-kotlin users and is the only library that supports compatibility between the generated dataclasses and protobuf-java classes.
If more people use krotoDC, I'm confident that it could be maintained stably with the help of the community since we already have precedents that use krotoDC in production.

[Dogacel]

• My former company, Mathpresso already uses krotoDC in production. Another use sight I am currently aware of according to Github search is prometheus-proxy. Since I'm also adding an example of krotoDC with Armeria in the line/armeria repo, hopefully more users will emerge. I'm currently back to being a full time student at my university, so all maintainership will be done in whatever time I can spare. Which means that if I'm busy from maybe an exam or other work for payed contracts, I may not be able to react immediately. If krotoDC becomes popular and needs a lot of work, I could maybe receive sponsorship in order to secure the resources needed to maintain this project, but there aren't any plans to do so yet.

That's really good to know 👍 I definitely support the idea.

• krotoDC vs pbandk, square/wire, protokt: The main advantage of krotoDC is that the stubs that it provides operate exactly the same as that of grpc-kotlin, except for the fact that you can use protobuf classes as krotoDC generated dataclasses. krotoDC also enables access to official protobuf-java features(ex: protobuf serialization) by supporting auto-generated converters. Thus, we don't have our own implementation for these features which prevents it from going wrong completely. I'm aware of other thirdparty Kotlin/gRPC code generation libraries, but pbandk doesn't generate gRPC stubs for you and square/wire has a slightly different gRPC service code compared to grpc-kotlin (does no use Flow for streamed messages, stub response is wrapped with GrpcCall or GrpcStreamingCall, etc) although they have an edge of being multiplatform and support both proto2 and proto3. I wasn't aware of protokt, but took a quick look at its readme and found out that it too has slightly different generated service code: gRPC service methods are received as constructor parameters, not implemented as abstract methods, bindService method has to be defined every time.

Good idea. I think enabling access to protobuf-java is a huge plus because it unblocks users from accessing unimplemented features. When you use your serializers, your users can be blocked by using certain functionalities.

In conclusion, although I cannot confidently say that krotoDC is the best one out there, I think that its API would be comfortable to grpc-kotlin users and is the only library that supports compatibility between the generated dataclasses and protobuf-java classes. If more people use krotoDC, I'm confident that it could be maintained stably with the help of the community since we already have precedents that use krotoDC in production.

Great job, keep going 👍 😄

I am also personally working on a protobuf code generator as well. My idea is to break the ties completely with protobuf-java to make protobuf support kotlin native 🙂 It uses kotlinx.serialization under the hood and it definitely has some flaws because it is experimental and trying to resolve that.