What is a QueryBus for? What is Query handling

[Simon Zambrovski]

Hi folks,

Axon 3.1 introduces the concept of Query Handler / Query Bus. The documentation describes how to configure them (https://docs.axonframework.org/v/3.1/part2/query-handling.html), but omits the purpose of them.

My naive interpretation of the view part of the application was to create an event listener and to construct some view projection based on events. 

This can be in-memory (Hashmap?) or persistent - from H2 DB to real JPA data store with a RDBMS behind. 

If I want to query this view side, I would put a Repository (e.g. a JPARepository) and expose the read methods.

Could you explain what are the Query Handlers used for and how they match into this picture?

Kind regards,

Simon

[Allard Buijze]

Hi Simon,

Axon aims to decouple components by providing abstractions for the communication between them. In essence, this means that messages like commands and events are sent over a bus, and the sender doesn't know (nor should care) where the recipient of that message is located.

This is exactly the same for queries. It has been a part of the architecture that has been skipped for a long time, in the belief that it was about command and events, primarily, and queries would be "business as usual". 

However, that vision has changed in the last couple of years. Axon is not "just" a CQRS framework, but rather an "Evolutionary Event-Driven Microservices" framework. Queries can follow quite complex patters, way beyond the HTTP-GET-style "hey you, give me this". For example the scatter-gather query (everyone, tell me what you know about ..) or the subscription query (keep me up to date on ...).

That's the goal of the Query Bus. 

Hope it makes sense.

Cheers,

Allard

PS. The API doesn't quite work great yet, so we're expecting to make some slight (backwards compatible) changes and additions to it.

Op di 12 dec. 2017 om 13:09 schreef Simon Zambrovski <szamb...@gmail.com>:

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

--

Allard Buijze

CTO

E: allard...@axoniq.io

T: +31 6 34 73 99 89

AxonIQ Conference - 29th September - in Amsterdam

[Rene Svetina]

Hello,

I would like to know more about subscription style queries. Where can I read more about them?

[Steven van Beelen]

Hi Rene,

As to some extent apparent from Allard his response, we're currently working on expanding the functionality of the QueryBus to be more robust.

One of the feature which still needs introduction is the subscription based query.

In short, you can imagine you've got several components which tell the framework they supply certain queryable data.

Additionally, you can have another component which subscribes to that queryable data to be able to receive it.

The specifics on how this will work or should be set up when using the Axon Framework or not fully described yet, so please stay tuned for that.

Cheers,

Steven

[Rene Svetina]

Hi Steven,

Thank you I taught that this is already in Axon but it is not documented yet.

[Steven van Beelen]

Hi Rene,

No worries, it will be documented once it is in! :-)

If I do not forget it, I'll replay in this thread once it is in.

Cheers,

Steven

[Simon Zambrovski]

Hi Allard,

that makes absolutely sense. Knowing that every change is reasoned by an event, interesting caching strategies on the query side may apply.

I wish more references to architectural discussiona or whitepapers on this or other Axon/CQRS features. 

Will look under the Christmas tree, may be I'll find some :-)

Thank you

Simon

[Rene Svetina]

I especialy like the subscription style of query it would be verry nice for server send events or GraphQL subscriptions. 

[Allard Buijze]

That's exactly what we are planning to use it for as well!

We hope to be able to include the subscription queries in 3.2. There's a few nitty gritty API related things to sort out before we can...

In one of my previous project, we have built something like this specific to the project. It was a blast to work with. The server would just use JsonDiff to send updates to the client, which would JsonPatch to apply these to its model. Using Angular (but most frameworks would allow you to do this), this would automatically trigger the view to be updated as well. Result: real-time views on the client. Updating view models (also structural changes between updates) were very simple to make, because the server essentially dictated how the view on the client was built....

Coming soon.....

Op do 21 dec. 2017 om 15:38 schreef Rene Svetina <rene.s...@gmail.com>: