5

Hello awesome Erlang community!

I'm making a little project that contains a Client and a Backend. (Complicated.. right?) :)

I'm making it in erlang.

The client and backend will be two separate processes and I'm wondering if I would need to (or should I) use some sort of message queue to get them to interact?

I know I can get them to interact using their PIDs and send messages using the "!" operator.

I guess what I'm trying to say is I'm struggling with finding an answer for this question:

"Why or when should I use message queues such as RabbitMQ, ZeroMQ in Erlang"?

Robbie
  • 620
  • 1
  • 5
  • 17

3 Answers3

5

You want to use a messaging library when you need something that the native message passing facility won't provide.

These include:

  • If you need to guarantee that your messages are processed at least once, exactly once etc. (i.e. transaction)
  • If your system load is such that it would be convenient if you could hold your messages on disk instead of memory (persistence)
  • You need other bells and whistles like security, interop with other systems, complex messaging pattern (routing) etc.
Enno Shioji
  • 26,542
  • 13
  • 70
  • 109
2

I would go for a messaging component when you need to decouple the different layers of my system. Also, a messaging component allows you to be able to do different integration patters with your messages/requests like topic/fanout/route based on headers... A messaging system is also used for scalibility purposes, so you can have multiple instances of the same process running simultaneously consuming from the same queue.

Last thing I want to mention is that RabbitMQ is a message broker but ZeroMQ is not, it is a messaging library.

hveiga
  • 6,725
  • 7
  • 54
  • 78
1

If you can sacrifice reliability for performance, use ZeroMq.

If you need reliability (message persistence, etc), and can give up some performance, use a brokered solution like RabbitMq.

raffian
  • 31,267
  • 26
  • 103
  • 174