You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I stumbled upon psrpc and I find it really useful. I'd like to use it in some of my projects, but there are some downsides I'd like to address and they might be of interest for other people too:
There are multiple messaging technologies out there: NATS, RabbitMQ, Kafka etc. Each has its own set of pros and cons, especially regarding delivery guarantees, depending on the use case. Being able to swap the messaging backbone of psrpc from one project to another would be of great use and would help with adoption - e.g. you already use one of the messaging solutions in your infrastructure.
It seems that the above goal was somewhat addressed via the MessageBus interface which abstracts away the differences between Redis and NATS. Unfortunately, this approach will always limit the API of the MessageBus to the least feature rich technology involved - in this case probably Redis being the limiting factor.
Let's take NATS as an example. The request-response (1-to-1) pattern is already implemented at Core NATS level with random inbox subjects and response multiplexing as an optimisation. If you want to implement claims / affinity logic or even 1-to-M pattern, you can do it via scatter-gather.
Due to the MessageBus interface, the above features cannot be used and had to be (re)implemented at the psrpc library level. One might argue that you can live at the application level with the fact that Core NATS subjects are hardcoded inside psrpc together with the flow of exchanged messages.
But what if you want to make use of JetStream delivery guarantees / features for psrpc's Queue or Stream patterns? Then you have to (re)implement logic for this, both at the psrpc library level and at the application level.
I've taken NATS as an example because psrpc already provides an implementation over it, but the same arguments are also valid for RabbitMQ, Kafka etc.
My proposal, if you find the above scenario interesting and want to address it, is to:
group the RequestSingle, RequestMulti, OpenStream, Join, JoinQueue functions into a client interface, let's call it ClientTrigger
group the RegisterHandler, RegisterStreamHandler functions into a server interface, let's call it ServerHandler
Use the current implementation as default wire providers for these interfaces. Let community developers come up with alternative implementations for different messaging backbones. One solution to use the alternative implementations at the application level would be to fork the psrpc library and just change the wiring file.
Please let me know if you are interested in this subject and if it's worth the time to make a PR with a proof-of-concept.
The text was updated successfully, but these errors were encountered:
Wire is a great tool, but it sounds like this could be better achieved by expanding MessageBus to inherit more of the logic from client Request/Open/Join functions and server Register functions. Then, you wouldn't need to fork the repo and change the wire file, just supply your MessageBus.
We are very open to PRs, but our focus is more on the LiveKit stack so we probably won't be making these changes in the near future unless we need to
I stumbled upon
psrpc
and I find it really useful. I'd like to use it in some of my projects, but there are some downsides I'd like to address and they might be of interest for other people too:There are multiple messaging technologies out there:
NATS
,RabbitMQ
,Kafka
etc. Each has its own set of pros and cons, especially regarding delivery guarantees, depending on the use case. Being able to swap the messaging backbone ofpsrpc
from one project to another would be of great use and would help with adoption - e.g. you already use one of the messaging solutions in your infrastructure.It seems that the above goal was somewhat addressed via the
MessageBus
interface which abstracts away the differences betweenRedis
andNATS
. Unfortunately, this approach will always limit the API of theMessageBus
to the least feature rich technology involved - in this case probablyRedis
being the limiting factor.Let's take
NATS
as an example. Therequest-response (1-to-1)
pattern is already implemented atCore NATS
level with random inbox subjects and response multiplexing as an optimisation. If you want to implement claims / affinity logic or even 1-to-M pattern, you can do it via scatter-gather.Due to the
MessageBus
interface, the above features cannot be used and had to be (re)implemented at thepsrpc
library level. One might argue that you can live at the application level with the fact thatCore NATS
subjects are hardcoded insidepsrpc
together with the flow of exchanged messages.But what if you want to make use of
JetStream
delivery guarantees / features forpsrpc
'sQueue
orStream
patterns? Then you have to (re)implement logic for this, both at thepsrpc
library level and at the application level.I've taken
NATS
as an example becausepsrpc
already provides an implementation over it, but the same arguments are also valid forRabbitMQ
,Kafka
etc.My proposal, if you find the above scenario interesting and want to address it, is to:
RequestSingle
,RequestMulti
,OpenStream
,Join
,JoinQueue
functions into a client interface, let's call itClientTrigger
RegisterHandler
,RegisterStreamHandler
functions into a server interface, let's call itServerHandler
Use the current implementation as default
wire
providers for these interfaces. Let community developers come up with alternative implementations for different messaging backbones. One solution to use the alternative implementations at the application level would be to fork thepsrpc
library and just change the wiring file.Please let me know if you are interested in this subject and if it's worth the time to make a PR with a proof-of-concept.
The text was updated successfully, but these errors were encountered: