mscheong01
commented
1 year ago 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 #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 #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
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,
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?