CODEWITHSUNDEEP
viewazurecqrs
Pharao2k
Pharao2k

Reputation: 695

CQRS: what backend to use for my View-Store?

My CQRS-based architecture currently has 4 components. It is more of a prototype so nothing is set in stone yet.

My original approach was to use an InMemory-Viewstore. Azure VMs have quite a bit of memory available and I didn't really see the need to add the complexity Blob-Storage etc. Additionally, I am trying to minimize the command-execution latency to at least partially get around the whole asynchronous UI problem so that I can (where needed) simulate a synchronous UI with (fast) callbacks (I hope that sentence made sense ^^).

In creating the web client, I noticed a potential flaw in my plan. The url of the ViewProcessor is obviously different to the WebClient-url, so json requests would fail because of the Same-Origin-Policy. Alternatives/Workarounds like jsonp did not seem that attractive because they don't solve the inherent security problem. Implementing the ajax requests to target the WebClient itself would be an option but then I would have redundant functionality (view-store in both webclient and viewprocessor).

I guess saving the views in blob-storage would solve this problem, but I can't shake the feeling that I am overlooking something important/obvious. 

    Client --command-- CommandProcessor
    CommandProcessor --event-- ViewProcessor
    ViewProcessor --view-- Blob
    (ViewProcessor or CommandProcessor) --notification-- Client
    Blob --view-- Client

That scenario would have quite a bit of latency :|

Upvotes: 4

Views: 530

Answers (1)

Erick T
Erick T

Reputation: 7449

I would look again the blob storage option. We store serialized view objects in blob storage, and it is very fast and stable. Is there some aspect of blob storage that concerns you?

Erick

Upvotes: 1

Related Questions