Better way to get messages

[guttizin]

Hey guys.
I'm new using RabbitMQ.
So what's the difference using the API and using dotnet RabbitMq.Client BasicGet()? There is any performance difference?

Why BasicGet i can't set the amount of messages or get all messages at once?

[lukebakken]

Hello, thanks for using RabbitMQ. Please take the time to do the .NET tutorials:

• https://www.rabbitmq.com/tutorials
• https://github.com/rabbitmq/rabbitmq-tutorials/tree/main/dotnet

You should never use the HTTP API to get messages, and you should never use BasicGet().

Your application should set up a consumer and use BasicConsume.

[guttizin]

How do you define the recommendations against "never use API" and "never use BasicGet()"? Are these concerns related to performance, security, or another aspect?

We're exploring RabbitMQ for building a messaging server to dispatch notifications to mobile apps.
Is this approach fundamentally wrong?
Our requirement includes handling situations where consumers may not always be online, necessitating them to query the server for available notifications upon reconnecting.

Could you recommend an architectural approach?

[lukebakken]

https://www.rabbitmq.com/docs/consumers#fetching

The HTTP API is unsuitable for the above reasons as well, since it uses basic.get under the hood.

We're exploring RabbitMQ for building a messaging server to dispatch notifications to mobile apps. Is this approach fundamentally wrong?

This sounds like a good use-case for RabbitMQ, but a one-sentence description is pretty insufficient.

Our requirement includes handling situations where consumers may not always be online, necessitating them to query the server for available notifications upon reconnecting

Great, your consumers re-connect, and then use BasicConsume to get the latest messages.

[michaelklishin]

@guttizin the docs answer that question and others:

• Connections
• Channels
• Consumers
• Publishers

Polling-based consumption, in particular over the HTTP API, goes against most of what messaging and streaming has to offer. And yes, it performs terribly, too.

And in this particular case, I agree with the "never" part. Never except some integration tests, perhaps, but even those can usually use a consumer. RabbitMQ's own test suites have a very large number of examples.