🎄 Happy Holidays! 🥳

Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.

Happy Holidays!

Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.

Send a message to the Queue instead the Topic

murillocg
murillocg Member Posts: 11

After hours of studying in Solace Documentation, Youtube Channel and etc, I believe I've ended up with some points to check with you:

Although we have some samples of sending a message to a queue, the best practice is to send a message to a topic. As I could see in the Spring Cloud Streams samples, this is the only way to send a message. Is it OK?

Since I have some legacy applications that use directly the Java JCSMP API (which allows me to send messages to a queue) and other new applications that use the Spring Cloud Stream with the Solace PubSub+ Binder, should I always send messages to topics to ensure only one standard in all applications of my architecture?

Best Answer

  • TomF
    TomF Member, Employee Posts: 412 Solace Employee
    #2 Answer ✓

    Hi @murillocg,

    The short answer is "yes!" Our best practice is to always send to a topic, and to map this topic to a queue.

    The reason is pretty simple: you may have a simple 1 to 1 pattern that you need to implement. But architectures are never static, and the chances are good that in the future someone else will need this data. If you use a topic, adding extra consumers is trivial. If you send to a queue, lots of pain awaits you.

    Even if you know no other application will ever need your data, conforming to the best practice other need to adopt will make your application easier to understand.

Answers

  • TomF
    TomF Member, Employee Posts: 412 Solace Employee
    #3 Answer ✓

    Hi @murillocg,

    The short answer is "yes!" Our best practice is to always send to a topic, and to map this topic to a queue.

    The reason is pretty simple: you may have a simple 1 to 1 pattern that you need to implement. But architectures are never static, and the chances are good that in the future someone else will need this data. If you use a topic, adding extra consumers is trivial. If you send to a queue, lots of pain awaits you.

    Even if you know no other application will ever need your data, conforming to the best practice other need to adopt will make your application easier to understand.