3 ms·
On the "read" side of things, you control what data is exposed to each subscription, and you'll be able to base access on authentication. The client doesn't ge
by dgreensp 15y ago
On the "read" side of things, you control what data is exposed to each subscription, and you'll be able to base access on authentication. The client doesn't get a direct database connection, but rather a live-updating subset (or arbitrary function, in the general case) of the database.
The rationale is that clients typically end up doing sorting and filtering on subsets of the database anyway, as they get more sophisticated and start caching data. For example, Gmail starts to need a notion of an email message on the client, to avoid going back to the server for the same message. When I worked on Google Wave I saw firsthand the complicated plumbing you need in order to do this in an ad hoc way. (They used GWT to share the model objects, but synchronized the data manually.)
You can also separate this facility from your database completely, and use it as a way of sending "data feeds" to clients; then use methods as RPCs.
- alttab 15y agoThis still doesn't sound like a straight forward answer. I think there is a justifiable cause for trying to minimize the role of the server but controlling the operating environment of the data itself is the essence of modern web security. There would need to be some sort of public key system for authentication, but in the end you are still compromising your data if the client gets hacked. There would have to be a database control layer for the final say, and thats called a server.
- disbelief 15y agoNot sure if Mongo has this feature, but in many classic SQL databases, per-user views can be created which act like tables, but are actually "the user's view into that table". This would mean creating database user accounts on the fly for people, but it would resolve this problem (as long as the views are secure).