Thank you for your answer Tobias,
Using routed RPC between components leads me to think that pub/sub will not
be used within backend components for load balancing purposes.
I understand there is no message persistence feature in WAMP but you can
WAMP has many different message types .. it doesn't make sense to access
or persist eg SUBSCRIBE
achieve similar via `event history` (which does not exist for RPC call I
WAMP event history is part of the WAMP AP profile, and Crossbar.io
WAMP event persistence is a feature we'll add in CrossbarFX -
persistence is outside the scope of even the WAMP AP profile
That means, if one of the backend services is down and client published an
event via RPC, the call will be lost and client will need to handle
I think you are mixing thing up. events are not tied to calls in WAMP
accordingly. where as with pub/sub you can catch up with the old events
when the service comes back up and client does not need to care about
whether the event was received or not.
And now I wonder where else pub/sub will be used besides UI updates.
for many things .. this is an open ended question that cannot be answered
Am 17.08.2018 um 01:35 schrieb Jan:
On Wednesday, August 15, 2018 at 6:52:58 PM UTC+10, Tobias Oberstein wrote:
Am 15.08.2018 um 03:00 schrieb Jan:
I think this question is duplicate
To eliminate direct dependencies between crossbar components, I want to
PubSub as an event bus rather than RPC.
WAMP routed RPC already decouples components
E.g., I want to specify how many subscribers will receive the message.
if Topic abc.topic.some_topic is subscribed by two same services, I
want only one to receive the publication.
see above, and also: