Why HTTQ? #

If you’re developing distributed systems, they must communicate with each other in some way. When doing this, you must pick from a myriad of different implementations and protocols:
ZeroMQ, RabbitMQ, Amazon’s SQS, Google’s Pub/Sub, Microsoft’s Azure Web PubSub, etc.

While we don’t deny that these are all very powerful solutions, they are not always easily approchable, especially when considering many of them don’t provide simple integration support leveraging the web’s most ubiquitious protocol: HTTP.

HTTP is simply the most straightforward protocol for web developers. While it may not be perfect, it’s everywhere, it’s reliable, easy to understand, text-based, builds nicely on top of TCP, and it gets the job done for pushing data back and forth between servers and clients.

It stands to reason then, that a message queueing system built on top of HTTP would offer all of HTTP’s straightforwardness while getting the problem of message queueing solved, too.

This is how we envisioned HTTQ: to be the simplest, easiest to use, deploy, analyse and understand message queueing system leveraging HTTP as its communication protocol. And even considering that some message queueing systems do offer good support for HTTP, HTTQ was designed to innovate within the problem space of message queueing as a whole, by leveraging a fully polymorphic internal architecture, while always retaining a completely stable HTTP API.

We hope you enjoy using HTTQ as much as we’ve enjoyed writing, testing, and otherwise working on it. We wish you success on your endeavours, and are happy to be a part of your own journey as a software engineer.