I've gone through RabbitMQ tutorials and have read a few articles, but it's still not clear to me what are the best practices regarding publishing to an exchange and creating an exchange.
My use case is this: We have several REST API's (Node.js) in which I'm calling RabbitMQ. For example, there is a request in which I publish a message to RabbitMQ exchange to create PDF, send email, generate report, etc. All these tasks are important, we don't want to lose any message, so exchange and queues are declared as durable and messages are persistent. However, I'm not sure, if my logic can be considered the best practise. As I said we have different projects, but all of them are publishing to one durable exchange - let's call it main_exchange - it is a direct exchange, and then we have separate queue for each type of task - emails, PDFs, reports etc, so messages are appended to the right queue based on routing key. Is this the right approach for this logic?
And there is this quote from RabbitMQ tutorial three:
The core idea in the messaging model in RabbitMQ is that the producer never sends any messages directly to a queue.
Because of that, in all APIs (which are producers), messages are published to the exchange. Publishers don't know anything about queues. Queues are created in workers (subscribers). But the issue is, if I create new logic, where I'm publishing messages with new routing key (that means to a new queue), I can effectively lose all messages which are sent before that queue is created - that means before starting worker, which creates that specific queue, for the first time. In other words, every time I want to use a new queue, I have to be sure to start worker before deploying the API. What is the standard practise in this case?
