3 ms·
"But yes, the server has no control over what data is being written. This is why this type of architecture only serves for personal / shared databases, not for
by OldSchoolJohnny 11y ago
"But yes, the server has no control over what data is being written. This is why this type of architecture only serves for personal / shared databases, not for public records."
A solution that doesn't take into effect security from the start is pretty limited for any real world usage beyond a simple personal data app in which case why over-architect it in the first place?
- daleharvey 11y agoThat generalization isnt totally accurate, CouchDB has in built ability to validate data that gets written to it, and PouchDB was built specifically to make that type of control easy and powerful.
- scoot 11y agoYup. I put together a successful proof-of-concept with React and PouchDB / CouchDB, but quickly concluded the lack of granular security was its Achilles heel. I switched to Meteor with GroundDB for offline support, and haven't looked back.
- pgte 11y agoThis can be addressed in CouchDB, by creating a validating function that validates all the incoming updates. Besides that, I'm addressing this via the architecture (there's an aside in the article where I cover this briefly), which will be a subject of a future article: Central records shouldn't be directly changed by a user. That's now how central record systems should work. Instead, we should view any document as a request to get or change the central records, to be processed by a clerk. The clerk then changes the state of the document according to the permissions and results.