Server-only RPC services

[rnett]

Is your feature request related to a problem? Please describe.

If you don't need a client (i.e. because you're using an integration that only consumes the server implementation, or because you're using a client in a different language, etc), having to define the service and server separately is needless boilerplate.

Describe the solution you'd like

The ability to annotate server implementations directly with @Rpc and not need a separate interface.

Describe alternatives you've considered

There aren't really alternatives, other than just living with the pain.

[Mr3zee]

Hi @rnett !

because you're using an integration that only consumes the server implementation

Can you please provide an example

or because you're using a client in a different language

Not intended with kRPC, as it is a Kotlin-first protocol

---

But these questions aside, I don't really understand this part:

just living with the pain.

This is a common patter even with the RPC - separating interface and implementation, even when these is only one implementation intended. This provides better readability, features discoverability, and I can't see any downsides

[rnett]

Hi there, this is specifically for non-KRPC servers. For example, a gRPC server being used by non-Kotlin clients, or any other cross-language RPC framework. It also came up in the context of #496 when I was looking into adding additional "server types" that weren't traditional RPC servers (e.g. using RPC methods as tools for a MCP server), and didn't even have the concept of a client.

[Mr3zee]

Hi there, this is specifically for non-KRPC servers.

Ok, got it, thanks.

So then again, I don't understand what do you mean by pain in this config:

@Rpc
interface MyServiceWithNoClient {
    suspend some()
}

class MyServiceWithNoClientImpl : MyServiceWithNoClient {
    override suspend some() {
        // do something
    }
}

This is clear separation of purposes: interface for the definition and implentation, even when you don't have a client and you don't call the service yourself from Kotlin.

These are UX reasons why we don't do this, there are also technical like that the compiler plugin would need to have a special relaxed mode in order for this to work, which means we need to support it, maintain it, etc, without the clear gain for users when there is a working 'workaround' (quotes because it's the way to do it)

So, I come back to the question: what is the pain point exactly? If we can understand it and there is real pain there (in the development process, reading code or maintaining it) - then we can come up with a solution

[rnett]

My end goal is something like this: https://docs.spring.io/spring-ai/reference/1.1/api/mcp/mcp-annotations-server.html, where any Rpc methods annotated with @McpTool would be exposed as tools (I'm aware that annotations on methods aren't currently exposed). The added pain is just now needing to maintain a separate interface and keep them in sync. Admittedly it's not that large, but can lead to cases where you add a @McpTool on the server implementation by accident and it's silently ignored, and adds overhead every time you want to change an exposed method because now you need to change both, etc. Although working through it, you'd probably need some way to select which public methods should be exposed (like an annotation), and it would end up being a whole different mode, so maybe it isn't worth it, vs using an interface and exposing everything.

[Mr3zee]

Why would you need to copy annotation both on a server impl and on the interface declaration? I would expect the annotation only on the interface

[rnett]

You wouldn't, if you had an interface it would only be on the interface. My concern is more someone adding it on the server and not getting any feedback that it doesn't work, plus the overhead from having the interface in the first place (e.g. changing methods, etc). But it's not a huge deal. Something like a @RpcInfo meta-annotation might be a better solution to the first problem anyways.

[Mr3zee]

Ok, got it now, thank you for a lot of clarifications!
We can definitely do a @RpcInfo kinda stuff, which would make sense, if someone wants to keep the annotations on RPC interfaces only. I'll log this into our design decisions

[rnett]

That would be great, thanks. I'm assuming you'd include that @RpcInfo annotations would be accessible from the RpcCallable instances?