Exinferis

Although the article is too generic, or not detailed enough regarding examples of what he states, I have to agree with what he is trying to say. React hooks are a mess, or at least code based around it tends to be. We have had our share of hooks based applications and they've become unmaintainable when reaching a certain size and I am glad that we are back to class based components wherever we can. In may opinion this comes down to the fact - as he states - that the mental model (what will happen, when I do this) is not simple to grasp, thus not predictable for many people.

This is a lot more than pub/sub.

A message queue stores messages so that nothing gets lost, when there are no subscribers listening.

A new message will be delivered to only one recipient at a time while in a pub/sub system all subscribers would receive a message and would either all work on the same message/job or would have to decide who does what.

Whoever receives a message will "work" on that message and after success will delete the message. Usually within seconds. So no one will ever receive that message again. If a receiving process crashes or some error happens the message will just pop up again and will be received again after a set invisibility time (default is 30s).

So dropping messages in this message queue keeps them there until some receiver(s) delete them. It does not matter how many message producers / consumers there are. The queue handles the problem of not delivering a message to two consumers within a set time.

We're have been using this in production for a few months now. We never tried kue but used the rsmq-worker module extensively.

Currently we're processing about 30 million messages per day on a single redis server with two worker instances.