
Webhooks: The Devil in the Details - cnj
https://techblog.commercetools.com/webhooks-the-devil-in-the-details-ca7f7982c24f
======
vertex-four
So part of the issue here is that many message queue systems have rather
terrible authentication, certain cloud-hosted systems aside - it often seems
to be that authentication allows you to post any message you like and listen
on any queue you like. A message queue designed for external entities to
access would require far more rigorous security mechanisms.

I'd also suggest that it would want some form of federation - so instead of
external entities pushing directly into your message queue, they'd push to
theirs, and your message queue would pull from theirs and push to your
consumers. That way, you don't lose messages from your provider when your
connection to them fails.

~~~
fusiongyro
RabbitMQ has more granular permissions:

    
    
      https://www.rabbitmq.com/access-control.html
    

I am starting to use it at my work but I'm pretty sure I wouldn't open it up
to the public, ACLs or not.

------
fiatjaf
It is not as easy to get some thing running with a message queue as it is with
webhooks. The API documentation would be complicated and large, also special
libraries would be needed.

------
jlward4th
Or a more simple solution... Have a webhook receiver send the messages to
Kafka. Then you don't have to change to a more complex delivery protocol.

~~~
lmm
Isn't Kafka a "Message Queue" exactly as recommended in the article?

