Meteor: Front-end data collaboration mechanism

For meteor applications, the model is opaque, that is, while modeling and model operations and business operations control in the backend, the front end still needs to understand the model structure to properly carry out the front-end business.

The relationship between the front end and the data, mainly change and query two categories.

Front-end to perform data changes, you need to invoke the methods (reference) provided by the backend.

Front-end data query, mainly through the PUB/SUB model to achieve. The backend can conditionally publish subsets of certain collections, and the front end can subscribe to these collections on demand, i.e., the front end maintains a subset copy of the back-end real data (and is reactive). Front-end where needed, just like querying a normal database, consult a local subscription to these copies of the data.

Since meteor is reactive, this change will eventually pass through (method-> back-end model operations, backend pub-> front end sub-> data source rendering), if the front-end initiates data changes, Reaction to the front-end rendering. This also provides the possibility of delay compensation.

Meteor: Front-end data collaboration mechanism