[rabbitmq-discuss] Writing applications using AMQP, basic design questions

Thu Mar 4 17:34:10 GMT 2010

On Thu, Mar 4, 2010 at 11:30 AM, Laurens Van Houtven <lvh at laurensvh.be> wrote:
> (Messages were cut liberally for brevity reasons.)
>
> On Thu, Mar 4, 2010 at 12:32 AM, Garrett Smith <g at rre.tt> wrote:

-snip-

>> Working with an AMQP interface is considerably different from working
>> with a REST or other RPC interface. If you're thinking along these
>> lines, I'd float the idea by some of your users to see what they think
>> of the approach. That's also assuming you have a technical requirement
>> to use AMQP for the public interface.
>
> I'm mostly interested in using it for the internal interfaces for
> flexibility reasons. I don't think any of the properties of AMQP
> particularly interest my monitoring users (which would be AMQP
> consumers if we let them speak AMQP). The mobile clients just want
> their data to be persisted and possibly reported, they don't really
> care what I do internally to make it happen.

Okay, I think I have a bead on what you've got going.

For AMQP's role, I'd approach this as an internal-only problem, which
will simplify your thinking. I'd keep everything external facing
strictly HTTP based.

You can opt to introduce the broker early in the process, but you
don't *need* to. I'd recommend starting with a relational database
(avoiding the temptation to go with some "nosql" thing) for your
persistence layer. This is super simple and, from what I'm
understanding, will work just fine to start. Once you have the rest of
your system working, you can introduce a messaging tier to address
specific pain points.

System architectures evolve so don't think you need to build
everything up front.

On the other hand, it sounds like you've got an itch to explore this
stuff. If your project can tolerate some speculative R&D work, go for
it! As far as selecting an AMQP platform, I think you're looking at
the right one.

Garrett