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
Our origins come as a wrapper to RMQ, and then other transports. As a result, some of our "model" of messaging is the RMQ way - well the AQMP 0.9.1 way to be precise.
In some cases this is not "as expected" for users familiar with other transports. One example folks seem to stumble over is routing key vs. topic. Whilst RMQ has RoutingKey, Kafka, SNS etc have Topic. Now, RoutingKey is more accurate in describing what this does - set up a routing table in the broker to decide who gets messages, but without knowing a lot about EiP, you may not get that. If you come from SNS/Kafka etc. it just seems a little jarring.
One option for us is to create a class Topic that derives from RoutingKey and can essentially be used in all the same places, but that matches the name expected. Then on the subscription and publication we can call the field (still of the base class RoutingKey for compatibility) Topic, so as to guide folks better.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Our origins come as a wrapper to RMQ, and then other transports. As a result, some of our "model" of messaging is the RMQ way - well the AQMP 0.9.1 way to be precise.
In some cases this is not "as expected" for users familiar with other transports. One example folks seem to stumble over is routing key vs. topic. Whilst RMQ has RoutingKey, Kafka, SNS etc have Topic. Now, RoutingKey is more accurate in describing what this does - set up a routing table in the broker to decide who gets messages, but without knowing a lot about EiP, you may not get that. If you come from SNS/Kafka etc. it just seems a little jarring.
One option for us is to create a class Topic that derives from RoutingKey and can essentially be used in all the same places, but that matches the name expected. Then on the subscription and publication we can call the field (still of the base class RoutingKey for compatibility) Topic, so as to guide folks better.
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions