What will be the story around Kotlinx-Rpc for api routes (or similar)

[apatrida]

With Kotlinx-Rpc and how it integrates with KTOR, and the custom KTOR server here, how will it be integrated in the future to allow it over the current server API routes?

[apatrida]

Maybe related to: #22

[apatrida]

Looking at the server plugin model, the problem would be that there is no hot reload. And since you need to register the server code when initializing KTOR it would be in that JAR instead of in part of the codebase that could reload on changes. Would be nice to have a hook in the multi-platform project for jsMain to install custom plugins to KTOR and keep its normal hot reload of JVM resources working. Currently you need a separate server for the API to resolve this.

[apatrida]

Easiest path looks like: (untested but in theory can't think of a blocker)

• add a custom kobweb server plugin that is a KTOR plugin to do a reverse proxy (see Reverse Proxy Sample)
• add this to kobweb and configure it to proxy through just your Kotlinx-RPC API route path
• run a separate server for Kotlinx-RPC sharing RPC definitions in common code, doing the client in jSMain and the server bit in another module that runs independently
• start the two servers

Hoping that the CORS setup of kobweb already handles what is needed there.

[bitspittle]

Note that we've done some initial experimentation with kotlin rpc, although it's too early to tell how we plan to support it (especially as the library is still in an experimental stage).

Kobweb websocket support (aka API streams) is pretty robust AND live reload capable. The experimentation that we are doing currently layers on top of it, so this may be how we support it. We may also add an RPC endpoint to Kobweb servers, it's hard to say at this point.

[apatrida]

In some cases, if crossing to other platforms from shared code, Kotlinx-RPC will be a required option that works in various places. Whereas API streams is only Kobweb. Glad it is being considered.

[apatrida]

I'll give API streams a go in my current utility app as it is needing tight access to data from the server being read at fast intervals, and will let me test out more of the framework.