-
Notifications
You must be signed in to change notification settings - Fork 30
Configurable server instances factories (singleton, etc) #102
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
Comments
Hi, @ShayOinif ! These are two different requests as I see |
I will rename the issue to address only the second point |
Hi, I came across my usage problem and this seems to be the most relevant issue. |
Hi @tomhula ! Yes your understanding is correct. One client - one server instance. That's the only option now. |
I understand the point, the library is about communication and thus the RpcService is an interface purely between the server and the client. However I will give my example of what I was describing in my project: So now using Kotlinx-rpc, we have example typical user crud interface: @Rpc
interface UserService : RemoteService
{
suspend fun createUser(newUser: CreateUserDto): Int
suspend fun getUser(id: Int): UserDto?
suspend fun getAllUsers(): List<UserDto>
suspend fun updateUser(user: UserDto): Boolean
suspend fun deleteUser(id: Int): Boolean
} On the backend, I would make a DatabaseUserService (database implmentation of the service) class DatabaseUserService(
override val coroutineContext: CoroutineContext,
database: Database
) : UserService
{
override suspend fun createUser(newUser: UserDto, authToken: String?): Int
{
// sql request...
}
override suspend fun getUser(id: Int): UserDto?
{
// sql request...
}
override suspend fun getAllUsers(): List<UserDto>
{
// sql request...
}
override suspend fun updateUser(user: UserDto): Boolean
{
// sql request...
}
override suspend fun deleteUser(id: Int): Boolean
{
// sql request...
}
} This is what I currently do, however from my understanding from this issue, this is not correct. (especially because the class gets instantiated a lot of times) I hope this explains my point, sorry for lengthy explanation. |
That is a good point indeed for the smaller applications, just minimizing unnecessary complexity. |
Hello, i know this lib is very new and things are still moving.
But I like the concept very much, and I would love to use it in some of my projects.
I have 2 main issues:
I would love to simply supply the same instance for all clients.
I understand that the main reason is ID'S not being unique between different client calls.
Maybe uuid v7 which is time based can be used?
Anyhow, I know that some work around could be to make my impl for the service an inner class of main service or singleton and make them very thin and simply redirect the calls to main/singleton service.
But still, I don't like all this instantiation.
Thanks in advance and I am really looking forward to use this lib in my code!
The text was updated successfully, but these errors were encountered: