4 ms·

You still have to handle cases where the server state has been updated (possibly via another medium, event, ...) and when the user's internet comes back it's no

by Fiahil 10y ago

You still have to handle cases where the server state has been updated (possibly via another medium, event, ...) and when the user's internet comes back it's not a matter of pushing clients' commands anymore. Instead you have to merge changes (either backend or front end side) before fetching the new state. For example, I try to purchase an item on my desktop, but can't because I lost connectivity. So, I proceed to buy it on my mobile. When the net comes back, did I mean to buy this item two times or just one ? In this case, it's easy to find a workable solution (cancel the second order command), but you get the idea: It's not trivial. CQRS and ES, are wonderful tools in such situations. Past that point, your web app is far away from the little CRUD mashup it was at the beginning.

mbrock 10y ago
Yeah, heavy transactions like purchases need special care, but that's true in general. At least you'd want a confirmation from the user. In our case, a simple command queue solved the vast majority of use cases, and the corner cases were not disasters but at worst somewhat confusing.
junaidajmal 10y ago
Stay at home mom Kelly Richards from New York after resigning from her full time job managed to average from $6000-$8000 a month from freelancing at home… This is how she done ,,,,,,,,,,,,,,,HERE ►WWW.bizcash3.COM
andrewstuart2 10y ago
Conflicts are actually not all that difficult to solve. We had to solve this exact problem with a time entry solution that needed to be mostly available offline. Taking most of our inspiration from Git, it was simple. Define the atomic unit of conflict, and the definition of a conflict that cannot be automatically resolved, and simply help the end user understand and resolve the conflict. 95% of cases were fairly easy to merge without interaction, once we had defined "conflict." And the remaining 5% just required a little extra user experience design to help surface the appropriate resolution.
- amelius 10y ago
  The problem I have with this approach is that you don't encode the intention with each change. You just encode the data itself. This makes it a bit of a hack, unfortunately. You can end up in conflict-resolution cases which you cannot always predict beforehand. Yes, from this viewpoint, Git (and every similar version control system) is a hack. But it works well in practice because humans are running it, not machines.
  - raquo 10y ago
    I've once built a system (an outliner app) that actually encodes intent, and uses a command queue ("transaction queue"). Intent could be for example to insert this new item as a first child of that other one, or to move these items to a position right before some other item, or to set font size on this item to 4. The data structure was a tree of item objects linked via next/prev/children/parent. Automatic conflict resolution works wonderfully in this case.
  - andrewstuart2 10y ago
    The intention was "I want to change this guy's hours from 5 to 8." I don't know what else you might mean by "encode the intention." Unless you're referring to something I'm utterly overlooking, I don't see how you'd get around the invalidated assumptions that came from being offline and having outdated information. Intent doesn't matter if the intentions were invalidated. When assumptions change, you really have a management problem on your hands. There's more information (sometimes very complicated information, like "the back office changed his hours to at least 8 because of union contracts, so now he has 11") that must be communicated and decided upon, sometimes by more than one person (e.g. foreman and superintendent) to figure out the appropriate resolution. In version control systems, this is the same, and unavoidable for asynchronous workflows. It's basically optimistic locking, really. You make changes hoping that nobody else has altered the data, then check to see if any of your assumptions (i.e. nobody else is making changes) have held. If they haven't held, then you need to recheck your assumptions and resolve the conflict; there's no way around that.
    - 10y ago
pkaeding 10y ago
JSON-Patch [1] can be helpful here. You can maintain a list of changes that need to be applied, such that they only touch the parts of the document that need to change (other changes to other parts can be interleaved). If necessary, you can include tests to assert that some value in the document is what you expect it should be, and the patch can be rejected if that test fails. [1]: http://jsonpatch.com/ http://jsonpatch.com/
- coldtea 10y ago
  That's if what's to be changed is a document (which is a big if). Things get ugly quickly for any more complicated scenario.
  - pkaeding 10y ago
    Yeah, that's true. JSON-patch won't help with all situations. It is still an under-utilized tool, IMO.
- amelius 10y ago
  I think it's strange that it doesn't efficiently handle patches of strings. By the way, I'm still looking for a 3-way merge algorithm for any datatype in Javascript.
rattray 10y ago
CQRS = Command Query Responsibility Segmentation – http://martinfowler.com/bliki/CQRS.html http://martinfowler.com/bliki/CQRS.html ES seems to be Event Sourcing – http://martinfowler.com/eaaDev/EventSourcing.html http://martinfowler.com/eaaDev/EventSourcing.html

by Fiahil 10y ago

mbrock 10y ago

Yeah, heavy transactions like purchases need special care, but that's true in general. At least you'd want a confirmation from the user. In our case, a simple command queue solved the vast majority of use cases, and the corner cases were not disasters but at worst somewhat confusing.

junaidajmal 10y ago

Stay at home mom Kelly Richards from New York after resigning from her full time job managed to average from $6000-$8000 a month from freelancing at home… This is how she done ,,,,,,,,,,,,,,,HERE ►WWW.bizcash3.COM

andrewstuart2 10y ago

Conflicts are actually not all that difficult to solve. We had to solve this exact problem with a time entry solution that needed to be mostly available offline. Taking most of our inspiration from Git, it was simple. Define the atomic unit of conflict, and the definition of a conflict that cannot be automatically resolved, and simply help the end user understand and resolve the conflict. 95% of cases were fairly easy to merge without interaction, once we had defined "conflict." And the remaining 5% just required a little extra user experience design to help surface the appropriate resolution.

amelius 10y ago
The problem I have with this approach is that you don't encode the intention with each change. You just encode the data itself. This makes it a bit of a hack, unfortunately. You can end up in conflict-resolution cases which you cannot always predict beforehand. Yes, from this viewpoint, Git (and every similar version control system) is a hack. But it works well in practice because humans are running it, not machines.
- raquo 10y ago
  I've once built a system (an outliner app) that actually encodes intent, and uses a command queue ("transaction queue"). Intent could be for example to insert this new item as a first child of that other one, or to move these items to a position right before some other item, or to set font size on this item to 4. The data structure was a tree of item objects linked via next/prev/children/parent. Automatic conflict resolution works wonderfully in this case.
- andrewstuart2 10y ago
  The intention was "I want to change this guy's hours from 5 to 8." I don't know what else you might mean by "encode the intention." Unless you're referring to something I'm utterly overlooking, I don't see how you'd get around the invalidated assumptions that came from being offline and having outdated information. Intent doesn't matter if the intentions were invalidated. When assumptions change, you really have a management problem on your hands. There's more information (sometimes very complicated information, like "the back office changed his hours to at least 8 because of union contracts, so now he has 11") that must be communicated and decided upon, sometimes by more than one person (e.g. foreman and superintendent) to figure out the appropriate resolution. In version control systems, this is the same, and unavoidable for asynchronous workflows. It's basically optimistic locking, really. You make changes hoping that nobody else has altered the data, then check to see if any of your assumptions (i.e. nobody else is making changes) have held. If they haven't held, then you need to recheck your assumptions and resolve the conflict; there's no way around that.
  - 10y ago

pkaeding 10y ago

JSON-Patch [1] can be helpful here. You can maintain a list of changes that need to be applied, such that they only touch the parts of the document that need to change (other changes to other parts can be interleaved). If necessary, you can include tests to assert that some value in the document is what you expect it should be, and the patch can be rejected if that test fails. [1]: http://jsonpatch.com/ http://jsonpatch.com/

coldtea 10y ago
That's if what's to be changed is a document (which is a big if). Things get ugly quickly for any more complicated scenario.
- pkaeding 10y ago
  Yeah, that's true. JSON-patch won't help with all situations. It is still an under-utilized tool, IMO.
amelius 10y ago
I think it's strange that it doesn't efficiently handle patches of strings. By the way, I'm still looking for a 3-way merge algorithm for any datatype in Javascript.

rattray 10y ago

CQRS = Command Query Responsibility Segmentation – http://martinfowler.com/bliki/CQRS.html http://martinfowler.com/bliki/CQRS.html ES seems to be Event Sourcing – http://martinfowler.com/eaaDev/EventSourcing.html http://martinfowler.com/eaaDev/EventSourcing.html