Process Manager in a CQRS http application

[F]

Based in the following example:

The Customer sends a "PlaceOrder" command, which is handled by the "PlaceOrderCommandHandler", which mutates the OrderAggregate, which throws the "OrderCreated" Event, which is handled with a Process Manager (aka Saga), which talks with others aggregates, and finally returns the "OrderConfirmed" Event to the Customer.

In a websocket/socket application it's easy, the customer just fire the PlaceOrder command and waits until "something happens" (an OrderConfirmedEvent, or an OrderCannotBeConfirmedEvent, or whatever).

But, my question is: how to deal with it in a typical http application (without websockets)?

The world is full of synchronous requirements, for example, imagine a "spin to win" service, where you spin the wheel and the backend must determine the result.

The client should be stuck until the backend gives to it the response. You cannot fake the result in the client and continue guessing that the backend would determine your exactly result. You should wait for it.

I imagined some "possible" approaches:

1. Synchronous layer over the Command Handlers:

The http controller which manages the command handling (creating and dealing it) would wait until the process manager finishes his work, and then the controller would return the response back to the consumer based on X domain event.

2. Send the command as fire and forget and do polling:

Just send the command as a http request and return a 202 Accepted response (the request has been accepted but isn't completed yet).
And then, do polling to the backend looking for the result:
- request: spin the wheel | response: job id: 123456789
- request: get spin the wheel result (job id: 123456789) | response: not completed yet
- request: get spin the wheel result (job id: 123456789) | response: not completed yet (again)
- request: get spin the wheel result (job id: 123456789) | response: not completed yet (again)
- request: get spin the wheel result (job id: 123456789) | response: you won a TV!

3. End point to read events and do polling:

Similar to the last mentioned, send a fire and forget command, and having an endpoint which allows the client to read the produced "backend events" (based on some Round Robin Database, storing last X events of the user)
But may be some problems with sensible events...

What do you think? Is possible to fit a CQRS application in the real http world where the flows require a real response (result of commands) to continue?

[Greg Young]

"But, my question is: how to deal with it in a typical http application (without web sockets)?

See atom feeds.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[F]

what do you mean?

[Greg Young]

Atom feeds can do event delivery.

[Félix Carmona]

atom feed works as a website offering an atom.xml which users (mostly rss feeds clients) do polling to this xml which. It differs from a traditional cqrs application, as explained in the example

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/bl60fpvIrWo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Greg Young]

That's odd since this is one of the APIs for eventstore and it is commonly used for dispatching events back to clients.

SubmitOrder -> 201 created Location: http://mydomain.com/atomfeed

client follows to atom feed to get notifications about the order (just like getting events back over say a web socket)

[Félix Carmona]

Yes, I understand what you say, it's like the "3. End point to read events and do polling:" which I said, the feed works as an endpoint to read events

[Kyle Cordes]

On September 18, 2015 at 8:05:53 AM, Greg Young (gregor...@gmail.com(mailto:gregor...@gmail.com)) wrote:

> That's odd since this is one of the APIs for eventstore and it is commonly used for dispatching events back to clients.
>
> SubmitOrder -> 201 created Location: http://mydomain.com/atomfeed
>
> client follows to atom feed to get notifications about the order (just like getting events back over say a web socket)

Greg,

I think this is a really clever use of atom in event store. I have not studied how event store performs immediate delivery of new events - perhaps something like long polling? Over here we rolled our own means of implementing and talking to an event store, and no Atom was used, but I still think it is a great idea and may do it in the future.

Regardless though, that’s not what I really intended to write about here.

Rather, I think it is not all that obvious to some people who stumble into the CQRS/ES world and find EventStore, that Atom is a suitable and reasonable technology for the purpose. People tend to associate Atom with blogs, as a more consistent replacement for RSS, rather than as a way for arbitrary programs to talk to each other about data that has nothing to do with blogs. Is there something written somewhere, that explains it in more depth?


--
Kyle Cordes
http://kylecordes.com

[Greg Young]

"I have not studied how event store performs immediate delivery of new
events - perhaps something like long polling?"

Yes and adding an option for SSE

[Greg Young]

Sorry separating my replies for people with threaded email clients.

"Rather, I think it is not all that obvious to some people who stumble
into the CQRS/ES world and find EventStore, that Atom is a suitable
and reasonable technology for the purpose. People tend to associate
Atom with blogs, as a more consistent replacement for RSS, rather than
as a way for arbitrary programs to talk to each other about data that
has nothing to do with blogs. Is there something written somewhere,
that explains it in more depth?"

I did a talk about atom here
http://www.infoq.com/presentations/event-store-web-apps

To be fair when you need to secure data much of the caching stuff goes
out the window but much else still applies (remember you can also use
caching inside of your "trusted zone")

On Fri, Sep 18, 2015 at 4:18 PM, Kyle Cordes
<kyle....@oasisdigital.com> wrote:

[Greg Young]

btw check here:

http://docs.geteventstore.com/http-api/3.2.0/optional-http-headers/longpoll/

[Kyle Cordes]

On September 18, 2015 at 8:21:28 AM, Greg Young (gregor...@gmail.com(mailto:gregor...@gmail.com)) wrote:

> "I have not studied how event store performs immediate delivery of new
> events - perhaps something like long polling?"
>
> Yes and adding an option for SSE

I think this is an excellent choice. Over where most of my work happens (the regime of complex, large “single page apps” and the servers that run behind them), far too many people reach for web sockets when what they really needed was SSE. It has just the right set of features for lots of problems out there, but it gets little attention.

[Greg Young]

Hell atom feeds are good enough for a huge number of web apps. They
also scale better for huge numbers of consumers.