
Hutch: Inter-Service Communication with RabbitMQ - hcm
https://gocardless.com/blog/hutch-inter-service-communication-with-rabbitmq/
======
whisk3rs
I've built something similar as part of renovations to a large, legacy PHP
code base.

We're writing our consumers in Go using some impressively well written AMQP
libraries
([https://github.com/streadway/amqp](https://github.com/streadway/amqp)) and
some custom framework code. The framework code takes care of retries and
acking, so the consumers are very simple (in: an envelope, out:
fail/done/retry-later). Each worker runs as its own binary. I'm currently
adding standardized variable exports for monitoring, and ephemeral queue-based
reply capability.

On the PHP side, I found none of the PHP AMQP libraries to be worth using.
They all have compilation problems or bugs or seem to be unmaintained.
Instead, I'm using RabbitMQ's STOMP plugin w/default login and then wrote a
simple TCP client in PHP using persistent connections. The client supports
timeouts and multiple backends.

So far, this is working really well. Anybody doing their own RPC
implementations using HTTP should take a look at using something like
RabbitMQ. It solves a host of real-world problems and introduces much
flexibility into your architecture.

~~~
old_sound
> On the PHP side, I found none of the PHP AMQP libraries to be worth using.
> They all have compilation problems or bugs or seem to be unmaintained.

I take care of this one [https://github.com/videlalvaro/php-
amqplib](https://github.com/videlalvaro/php-amqplib) and it's very well
maintained and used by many companies in production.

Also is, it's a pure PHP library so there's no need to compile it. It's been
installed +72000 times already
[https://packagist.org/packages/videlalvaro/php-
amqplib](https://packagist.org/packages/videlalvaro/php-amqplib)

~~~
whisk3rs
Oh, that's great to hear. I'm surprised I didn't find that previously. I
vaguely remember trying a php-amqplib and having issues with error messages,
but your client promises to be strict-compliant so perhaps I was using an
ancient version somehow.

For the sole purposes of producing messages, STOMP and a few dozen lines of
PHP seems more attractive to me than using the full library (plain text
protocol, easy persistent connections, simple retry behaviors, and no
surprises). I'll use your library when we add PHP consumers, though, because
consumption is harder to get right.

Thanks.

------
jbarmash
This looks analogous to Promiscuous from CrowdTap, also a framework for Rails
/ RabbitMQ. Promiscuous takes a different approach in that it also allows you
to go to an SOA architecture but by decomposing your app to run across
multiple servers.

From the repo readme: "Promiscuous is a publisher-subscriber framework for
easily replicating data across your Ruby applications."

[https://github.com/crowdtap/promiscuous](https://github.com/crowdtap/promiscuous)

~~~
kkouddous
Thanks for sharing jbarmash. Promiscuous has enabled us to break up our
monolithic application into 10 single purpose apps. It's essentially MVC
application level replication.

