Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Backend Communication (e.g. REST API) #20
One thing we should also consider is providing not only a REST/AJAX api for CRUD, but also a sockets based one as well, allowing us to move from polling data, to a pub/sub method of data. This has somewhat been proven to be possible via the sync plugin
On a completely seperate topic, it would be great if the GUIs we create could be agnostic to the backend. This could be implemented in one of these ways I think:
Not sure if the right solution is 1 or 2 or a combination of both. 1 makes sense from standardizing a particular API and moving forward fast (for instance with our rapid progress here with DocPad and the GUI) and then allowing others to follow. 2 makes sense from a longevity point of view in terms of it opens up the platform to other backends.
Personally, I think the quickest way forward would be to use 1 then follow up to 2. However, I'm open to having that countered.
/cc @laktek your thoughts?
referenced this issue
Aug 27, 2013
As discussion is not closed and any vision documents are lacking to be able to contribute to via Pull Requests, I am dumping some general thoughts to the topic here, as I may not be misunderstood for once:
When I see issues like Central user Database, User Authentication and Local User Database a strange feeling arrives regarding federated identity. Why do we see tendencies here to recentralize an aspect of an application?
Talking about the Unhosted, Offline First and noBackend approaches by remoteStorage.js and hood.ie. Yet again brewing their own soup. New buzzword: Front-End First.
Following discussions like Sync to non-commercial storage makes me wonder the importance of independent storage is not as prevailent as I believed.
I see DocPad's role here as the reference implementation for decoupled human interfaces. A way in helping to keep the dependency graph small for each component.
Why is it now that I can't replicate, say, from LevelDB running in IndexedDB, not even leveraging any other local PouchDB, to CouchDB or remoteStorage? Why can't we have data portability as simple as copying files?
I like the definition of a webwrite spec, something similiar to writing remoteStorage or ouch (which they sometimes even just call JSON-over-HTTP), but closer to Hydra-style Hypermedia APIs.
But still, what is lacking to let APIs actually talk to each other, explain themselves and make the desired content flow? I'm yielding at the Federated Wiki's API now, which uses verbs like fork in a distributed manner (GitHub would dream of) that allows us to use the term federated.
GitHub is not the decentralized vision
Now, why can't I just fork everything into a federated wiki worksheet (IPython style) right now? The technology seems to be there.
But what we're lacking are the social protocols.
Loomio aims at facilitating these conversations, and we're also trying to design these kinds of rhizomatic social activities in JSON-LD, but it remains hard. When do we know the competition is over? When do we start to cooperate on a truly global scale?
Basically what I'm asking is: How can we operate backend agnostic and abstract all possible use cases away to replicate anywhere while remaining adaptive to special environments and their certain needs? Where's the interoperable by design factor?
webwrite itself doesn't sound too far from ReadWriteWeb, i.e., but remains incompatible (WebID and stuff).