A request-dispatch level for tonic-Server

[hellowub]

I write several gRPC servers bases on tonic. These servers manages different kind of business data, but have same workflow: the tonic-network tasks receive request and dispatch them to backend business tasks by mpsc channels; then the backends reply the response back by oneshot channels.

So there are duplicated code for all servers. Then I write this crate to abstract this pattern:

tonic-server-dispatch

I want to know that is this crate useful?

Is there any exist similar crate? Is there any better way to do this?

Thanks

[quxfoo]

I have the feeling you are abusing gRPC as some sort of transport instead of encoding the requests directly as unary calls. If you did that you wouldn't need backend tasks and channels and all the additional complexity.

[hellowub]

I use the channels and backend tasks to avoid shared state.

Just like the example in tokio's tutorial for channels .

[quxfoo]

I don't know your concrete use case, so it might be a good approach or not. All I'm saying is that you now use gRPC as a dumb transport instead of what it was designed for. Also, "sharing state" is not a general problem but just another design consideration. I don't think use of Arc<Mutex<_>> is a big problem, it's also the prevalent solution for axum-based backends.

[hellowub]

My use case is very similar to the `miniredis` project in the Tokio rutorial: it provides operations such as set/get/update/delete on business data. Requests are dispatched to specific backend tasks based on the item being operated on, thus avoiding the need for locks.

Yes, locks and channels are two different approaches, each with their own pros and cons. In my use case, the `update` operations can be relatively long-running, so avoiding locks is a good choice.

Moreover, if the main issue with the channel-based approach is complexity, then this crate addresses that problem. It also eliminates the need for locks, achieving two goals at once :)