Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeSpec support #137

Open
natanfudge opened this issue Jul 15, 2024 · 1 comment
Open

TypeSpec support #137

natanfudge opened this issue Jul 15, 2024 · 1 comment

Comments

@natanfudge
Copy link

natanfudge commented Jul 15, 2024

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.

@Mr3zee
Copy link
Collaborator

Mr3zee commented Jul 16, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants