Comments on: Eventual consistency, CQRS and interaction design http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/ Strong opinions, weakly held Wed, 22 May 2013 13:39:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Initial thoughts on some new-fangled things part 1 « The Shade Tree Developer http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-5137 Initial thoughts on some new-fangled things part 1 « The Shade Tree Developer Fri, 26 Oct 2012 21:26:46 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-5137 [...] Jimmy Bogard recently blogged about the downsides of eventual consistency with a user interface.  We had some similar issues on a previous project   Rather than repeat everything Jimmy said, I’ll simply add that you must be cognizant of eventual consistency during testing.  A typical testing pattern is going to be something like: [...] [...] Jimmy Bogard recently blogged about the downsides of eventual consistency with a user interface.  We had some similar issues on a previous project   Rather than repeat everything Jimmy said, I’ll simply add that you must be cognizant of eventual consistency during testing.  A typical testing pattern is going to be something like: [...]

]]> By: CQRS and user experience | Jimmy Bogard's Blog http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4852 CQRS and user experience | Jimmy Bogard's Blog Thu, 23 Aug 2012 14:57:03 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4852 [...] “View” side of things is in a separate store than the “Form” side of things. I elaborated earlier on UI designs when you chose eventual consistency, but there is a choice beforehand. In cases where we’re introducing CQRS, it can be fairly [...] [...] “View” side of things is in a separate store than the “Form” side of things. I elaborated earlier on UI designs when you chose eventual consistency, but there is a choice beforehand. In cases where we’re introducing CQRS, it can be fairly [...]

]]> By: Sam Critchley http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4810 Sam Critchley Wed, 08 Aug 2012 06:55:00 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4810 I'm stuck on this too. If event handlers fail how to recover! Another doozy is if you change the system is the only way to deploy by replaying your entire event store - what if you have millions of events? I’m stuck on this too. If event handlers fail how to recover! Another doozy is if you change the system is the only way to deploy by replaying your entire event store – what if you have millions of events?

]]> By: Friday links 34 « A Programmer with Microsoft tools http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4658 Friday links 34 « A Programmer with Microsoft tools Fri, 29 Jun 2012 19:43:18 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4658 [...] Eventual consistency, CQRS and interaction design | Jimmy Bogard’s Blog [...] [...] Eventual consistency, CQRS and interaction design | Jimmy Bogard’s Blog [...]

]]> By: Distributed Weekly 161 — Scott Banwart's Blog http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4657 Distributed Weekly 161 — Scott Banwart's Blog Fri, 29 Jun 2012 11:47:39 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4657 [...] Eventual consistency, CQRS and interaction design [...] [...] Eventual consistency, CQRS and interaction design [...]

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #1133 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4655 The Morning Brew - Chris Alcock » The Morning Brew #1133 Wed, 27 Jun 2012 08:30:31 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4655 [...] Eventual consistency, CQRS and interaction design - Jimmy Bogard follows on from Gabriel Schenker’s series of posts on CQRS and Event Sourcing, taking a look at Eventual Consistency, the scenarios it arises in, along with how eventual consistency is presented to users. [...] [...] Eventual consistency, CQRS and interaction design – Jimmy Bogard follows on from Gabriel Schenker’s series of posts on CQRS and Event Sourcing, taking a look at Eventual Consistency, the scenarios it arises in, along with how eventual consistency is presented to users. [...]

]]> By: Daniel Lang http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4654 Daniel Lang Tue, 26 Jun 2012 18:42:00 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4654  Yes, I see your point, but in how far does it relate to the the event-sourcing topic of the post?  Yes, I see your point, but in how far does it relate to the the event-sourcing topic of the post?

]]> By: Tracker1 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4653 Tracker1 Tue, 26 Jun 2012 15:36:00 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4653 There's a serious issue dealing with synchronous communication, as in via XHR in the actual browser.  That is the single-threaded nature of JavaScript within the browser.  Most recently I looked at the client demos for ADL's Project TinCan (an eLearning specification being worked on)... the default client scripts are using Synchronous XHR requests... The problem is if your page has other interactions, such as animation that is script driven while this communication is happening.  This can also include GIF animations, and other issues that are in effect locked during transmission. It's less about async being more correct for a transactional state from a browser to a server, and more about the function of the browser's nature.  Just wanted to make this point. There’s a serious issue dealing with synchronous communication, as in via XHR in the actual browser.  That is the single-threaded nature of JavaScript within the browser.  Most recently I looked at the client demos for ADL’s Project TinCan (an eLearning specification being worked on)… the default client scripts are using Synchronous XHR requests… The problem is if your page has other interactions, such as animation that is script driven while this communication is happening.  This can also include GIF animations, and other issues that are in effect locked during transmission.

It’s less about async being more correct for a transactional state from a browser to a server, and more about the function of the browser’s nature.  Just wanted to make this point.

]]> By: Anonymous http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4652 Anonymous Tue, 26 Jun 2012 14:14:00 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4652 I'll have a follow-up on this one, it's a whole topic in an of itself! I’ll have a follow-up on this one, it’s a whole topic in an of itself!

]]> By: Tyrone Michael Avnit http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4651 Tyrone Michael Avnit Tue, 26 Jun 2012 14:09:00 +0000 http://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/#comment-4651 I have been thinking about this quite a bit lately, and I am wondering why more applications dont implement the following. Take Backbone for example which has changed recently to allow optimistic updating when saving/updating the model. Now I am unsure if this is directly applicable to the article, but it seems so. When doing updates or creates to a model (non transactional), do I need to wait for a success response from the server? Or can I presume that the update/create was successful? Obviously the latter will lead to a snappier application because results are immediate. How would you handle errors with an optimistic application? I have been thinking about this quite a bit lately, and I am wondering why more applications dont implement the following. Take Backbone for example which has changed recently to allow optimistic updating when saving/updating the model. Now I am unsure if this is directly applicable to the article, but it seems so. When doing updates or creates to a model (non transactional), do I need to wait for a success response from the server? Or can I presume that the update/create was successful? Obviously the latter will lead to a snappier application because results are immediate. How would you handle errors with an optimistic application?

]]>