You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a big ask but it's something I could implement myself once the compiler plugin stabilizes (I have already done something similar).
As it stands a kotlinx.rpc service is only consumable by a Kotlin client. However, most clients in the wild are not Kotlin. This can be solved by generating TypeSpec declarations for your rpc service.
TypeSpec is a specification by Microsoft for defining APIs. Once an API is defined, client libraries exist for each language to generate typed declarations from the TypeSpec.
The vital point is that kotlinx.rpc is in a unique position to do this - it already analyzes your API and knows exactly what the API surface is.
Obviously, this is not useful for everyone so it would be a separate module.
The text was updated successfully, but these errors were encountered:
Hi! This is an interesting topic. You see, the point for API specs is to work with specific protocols or formats, like protobuf, gRPC, HTTP, etc.
In kotlinx.rpc protocols may vary. Right now we have one build-in protocol - kRPC. And it is Kotlin only in the current state. Once and if we stabilise it and provide a clear way to use it from non-Kotlin clients - it would make sense to have specs generated. So the issue should wait until then.
This is a big ask but it's something I could implement myself once the compiler plugin stabilizes (I have already done something similar).
As it stands a kotlinx.rpc service is only consumable by a Kotlin client. However, most clients in the wild are not Kotlin. This can be solved by generating TypeSpec declarations for your rpc service.
TypeSpec is a specification by Microsoft for defining APIs. Once an API is defined, client libraries exist for each language to generate typed declarations from the TypeSpec.
The vital point is that kotlinx.rpc is in a unique position to do this - it already analyzes your API and knows exactly what the API surface is.
Obviously, this is not useful for everyone so it would be a separate module.
The text was updated successfully, but these errors were encountered: