Hello, I would now like to finally integrate KRPC ...
# kotlinx-rpc
d
Hello, I would now like to finally integrate KRPC into our product to handle communication between the browser and microservices, replacing our custom solution. I have a question about authentication and service instance creation. My approach can be seen in the screenshot. The method jwtUndPortalrechtePruefenBlocking validates the JWT from the call and checks whether the user has the necessary permissions, then returns the user. Is the service now created for every call with the user, or does KRPC internally cache something and authentication needs to be handled differently? If that's the case, is there an example for this?
a
Hi! You should put auth route before the
rpc
Copy code
jwtUndPortalrechtePrufungBlocking(...) {
    rpc { ... }
}
But I don't know what this
resource
route does, so I'm not sure what effect it may have on the code
d
Hello @Alexander Sysoev, thank you very much for your quick response. This is a Ktor function and allows you to work with resource objects (io/ktor/server/resources/Routing.kt) instead of specifying the URL as a string. I use these definitions (resource objects) both in the frontend and the backend. Should it be removed? Does it actually work the way I intended, so that a service instance is created per user, and I can pass the user to it via the constructor?
a
Should it be removed?
Not sure, I never tested Rpc with it. It might just not work, but I'm not that into Ktor specifics here. Rpc route uses ktor 's
websocket
under the hood
Does it actually work the way I intended, so that a service instance is created per user, and I can pass the user to it via the constructor?
If you create one rpc connection (that is one websocket request) per user - than yes. So for each new
RpcClient
on the client side - there will be a new service on the server
I hope it works this way, if not in practice - please feel free to ask questions and fill a bug report if it's indeed our issue
d
I was able to call the service, so I’ll leave it in for now. If it starts behaving strangely in the future, I’ll keep the method in mind and remove it if necessary.
a
great!
And you also found a bug in kotlin. The dsl order you provided in snippets should be forbidden by the compiler to prevent confusion, so I'll file them a ticket. Thank you!