Is CQRS a good approach for implementing a social application on Google App Engine?

Question

It seems to me that the CQRS (Command and Query Responsibility Segregation) approach might be suitable for implementing a robust and responsive social application server on GAE, because:

1. CQRS doesn't require a SQL database (which GAE doesn't provide)
2. It does require a database capable of holding serialised objects, which GAE does in fact provide
3. It requires event queues, which GAE also provides
4. It supports a non-blocking, asynchronous, message based architecture, which neatly works round GAE's limitations on long-running transactions
5. It is advertised as being highly scalable, which is after all why optimists choose GAE

The trouble is, I'm a rusty Java programmer with little experience relevant to this choice, and I would very much appreciate any comments from anyone who has used the two together, or at least investigated using one from the experience of using the other.

I think that my main questions are:

1. Is CQRS over-complex for the early stages of a new application?
2. Are there any booby-traps that would make them a poor match, such as such as GAE's Datastore perhaps not being a good match to CQRS requirements?
3. Can anyone recommend either Axon or Jdon as being particularly suitable (or unsuitable) for GAE?
4. What other questions should I be asking?

Provencher

Ah - just noticed somewhat overlapping question at #3782028 - is there a "correct" way of linking? – Provencher

did you end up making up your mind if CQRS is adequate for implementing a social network ? Can you elaborate on that ? – Jutta

I stalled on the GAE application after prototyping the UI, so I never got to an outcome, I'm afraid. But please leave a comment or reply if you do it and learn something! – Provencher

Answer 1

CQRS is not overly complex or difficult, but it does take time to adjust your thinking away from the traditional request/response and client/server interactions that have been pounded into our heads over the years.

In CQRS with event sourcing, the data store is insignificant because you don't require a lot from your storage engine--the NEventStore project (written in C#) can easily support 40-50 different types of storage engines without much difficulty.

Both pure Amazon Web Services and Google App Engine are both great platforms for a CQRS application because they guides you to all of the correct infrastructure choices--asynchronous, non-blocking communication using messaging.

I've never heard of Jdon, but Axon has been around for a while. Try not to lean too heavily on the framework. As your understanding of CQRS deepens, this will become more apparent--basically it's like trying to avoid the use of Hibernate everywhere in your code. You should only use the Axon (or whichever you choose) exactly where it should be used and no more.

Some of the better questions that you might ask surround where to go for help and what resources are already available to help guide your understanding of CQRS. There are a number of good blogs and websites--including cqrsinfo.com--which can help you get started. Also, Greg Young's six-hour video is a must if you're going to start with CQRS.

Seeing

@Jonathan Oliver As you saying "asynchronous, non-blocking communication using messaging" support from GAE. Can you guide me what are the GAE services that facilitate this infrastructure? – Narcosynthesis

@Narcosynthesis The specific technology isn't what I'm promoting. It's the style of communication. – Seeing