Lite Python AMQP server for dev and mock?

Question

In Django, running ./manage.py runserver really good for dev, avoiding the hassle of setting up and running a real web server.

If you are not using Django, you can still configure the server for the guns.

Is there something similar for AMQP?

I don't need a full implementation or something reliable, just something that is easy to install and run for dev. PyPi package will be great.

Celery is not the answer. I do not want a client, I want a server. Like the RabbitMq mini python.

Answer 1

I do not know any AMQP broker implemented in Python. And I do not know about the "lite" implementation as a whole; I believe that the implementation of the AMQP broker is complex enough so that those who are trying to do this, either strive to be close to one of the versions of the AMQP specification, or do not worry at all. :)

I also do not quite understand how the broker works with the same problems as launching a test web server for your web application.

The web server does nothing useful if your application does not run inside it, and when developing your application it makes sense to execute it without the need for a full deployment.

But you do not implement the internal functions of the broker, and you can configure it dynamically so that (unlike the web server) it does not need to be restarted every time you change your code. Exchanges, bindings, and queues can be declared by the application under test and then automatically deleted afterwards.

Installing RabbitMQ is not at all complicated, and it is unlikely to need any configuration, if any, because it has a default user account vhost and guest, which are suitable for use in an isolated test environment. Therefore, I never had a problem running RabbitMQ on my test machine.

Perhaps you had some special problem that I did not think about. if so, please leave a comment (or expand your question) to explain this.

---

Edit: Recently, I have conducted quite a few tests of AMQP-based applications, and I found the RabbitMQ Control Plugin very useful. It includes an HTTP API , which I use to do things like create a new vhost for each test run, and then destroy it to clear the brokerage state. This makes the current tests for the general broker much less intrusive. Using the HTTP API to manage this, rather than the testable AMQP client, avoids having the tests become somewhat circular.

Answer 2

I had the same question, and I was shocked to see how dry the space was. Even after all this time, there is hardly a light AMQP server there. I could not even find the toy on Github. AMQP is like a beast protocol. I also found that RabbitMQ is probably about as light as it is.

In the end, I decided to use Docker for my integration tests, which automatically run and kill the RabbitMQ container. You need to install the Docker Python library and, of course, run the Docker daemon on your computer. I already used Docker for other things, so for my setup this was not a big deal; YMMV. After that, basically I do:

 import docker client = docker.from_env() c = client.containers.run( 'rabbitmq:alpine', # use Alpine Linux build (smaller) auto_remove=True, # Remove automatically when stopped detach=True, # Run in daemon mode ports={'5672/tcp' : ('127.0.0.1', None)} # Bind to a random localhost port ) container = client.containers.get(c.id) # Re-fetch container for port port = container.attrs['NetworkSettings']['Ports']['5672/tcp'][0]['HostPort'] # ... Do any set up of the RabbitMQ instance needed on (127.0.0.1:<port>) # ... Run tests against (127.0.0.1:<port>) container.kill() # Faster than 'stop'. Will also delete it so no need to be nice 

It turns out that you need to wait for the entire server to run in the tests, but I suppose that if you wanted to become really smart, you could cache the instance and just clear it before each test and maybe start it at the beginning of your dev and then upgrade to early next. I could do it.

If you need something for a longer time that does not necessarily programmatically start and kill for constant devs, then the normal Docker route will probably serve you better.