Dop: Distributed Object Protocol
distributedobjectprotocol.org
distributedobjectprotocol.org
The slides suggest that a sufficiently complex system will almost immediately get out of sync. The dependency on upstream nodes asserting state about objects before they are acknowledged and successfully applied by the "owner" node means that some subset of nodes will be working on assumptions that haven't been validated by objects they don't in fact own. This seems to conflict with what prior slides say about who can mutate objects.
I think distributed object management is a useful concept, but instance state needs to be owned and managed by multiple nodes for redundancy in anything remotely approximating a production-level system. That doesn't seem to be readily addressed anywhere, either. I'd love to read more about this with the level of detail you'd need from a system that readily has use cases and reference architectures instead of possibilities.
There's a discussion here with the same criticisms: https://www.reddit.com/r/javascript/comments/5sm5d0/distribu...
You are right, is not a library that provides a way to resolve sync conflicts. Consensus algorithms is a difficult topic, and I haven't seen an approach in JavaScript that resolve this problem. Maybe gun, but I haven't tried.
If you just need client-server architecture with reactivity, why don't you give a try to dop?
It doesn't look like this project deals with consensus or linearizability at all. The "distributed" part seems to be about just (1) listening to changes from some master source and (2) issuing fine-grained mutation requests to that master (presumably, you then listen for your update to come through your subscription channel). The notation for mutations seems very basic, too.
As far as I can tell, this isn't really about distributed objects. It's a simple async client/server protocol with change subscription.
Besides dop, DerbyJS/Racer seems to be dead, Apollo might be a solution but seems to require some setup, Meteor is too heavy, and Feathers with RxJS seems like a possibility. I'd be interested in any tools for getting easy client-server sync or reactivity.
Apparently a client for CouchDB.
Edit: Not affiliated with PouchDB, it's FOSS
Statebus can easily synchronize N clients to N servers, and has a very nice wrapper on top for reactive UI widgets to respond to changes in state. Here's a hello world example:
dom.BODY = -> # Let's define the body tag as a function
DIV
backgroundColor: '#eef'
'The time is '
fetch('state://server.com/time').now
' and the weather is '
fetch('state://another.org/weather/oakland,ca').brief
If it can be used seamlessly with Vue/React (as mentioned in older discussions) such that changes are propagated into them, I'd be interested to try it. (Those libraries are in heavy use already so your solution would have to work with them for a decent chance at traction, I think.)
(1) It does work with React natively, and in fact the example I gave above uses React under the hood. Here's how to do the same thing with raw react:
<script src="https://stateb.us/client6.js"></script>
<script>
var body = statebus.create_react_class({
render: () => { // This function will re-run whenever
return React.DOM.div( // any state fetched below changes
{style: {backgroundColor: '#eef'}},
'The time is ',
fetch('state://server.com/time').now,
' and the weather is ',
fetch('state://another.org/weather/oakland,ca').brief
)
},
displayName: 'body'
})
setTimeout(_=> React.render(body(), document.body))
</script>
I would love to help you give it a try and see what you think! Please send me an email or text (toomim@gmail.com or 510-282-4312) for feedback and assistance.
2) We are currently OT/CRDT/Version Control into it. We've come up with a new approach here, which I'm very excited about. I'm also looking for folks to beta-test or give early feedback on our approach as we polish it up.
I'm also interested in adding Vue support. If you'd like it, I'll add it.
If you are familiar with state management libraries such a Redux, Mobx, etc. Dop is more or less the same. With the difference that the initial state of your app can be initialized in the server.
I have to work better explaining this.
For a simple example of why that's a big problem imagine you have a state which has some boolean and an rcp that toggles that boolean which you fire based on that state (where both just want to turn it off). If two non-owning nodes say to toggle before the state has propagated from the other's change, it would turn off and back on again, cancelling each other out.
If this is just meant for toy projects where the worst case scenario has no real consequences that may be fine, but the polished look of the project is what's a little scary. It looks too professional for something that simply won't work.
Is the responsibility of the implementation to apply the patches/mutations in the correct order of the version.
I can see a number of ways that it can be accomplished that would take a good amount of work but it begs the question, is this worth the effort? You now have lots of security concerns, issues with nodes disconnecting, and nodes becoming overloaded. What benefit does this have over plain old fashioned AJAX? What problem does this solve?
Also you decide what to do when a client call a specific function: https://github.com/DistributedObjectProtocol/web/blob/master...