djmashko2

Meteor's RPCs support automatic optimistic UI updates, where the same code can be used to update the client side data store and the server side database, resulting in the perception of zero latency between server and client.

Building that functionality out yourself from scratch could be difficult, since all of the components of Meteor work together to make that experience possible.

Meteor's solution will also use containerization: http://info.meteor.com/blog/meteor-and-a-galaxy-of-container...

Database modifications on the client are usually disabled in Meteor. There are two ways to control database access in Meteor:

1. You can write allow/deny permissions rules to allow only certain modifications: http://docs.meteor.com/#/basic/Mongo-Collection-allow

2. You can not use client-side modifications at all and instead write all of your database code inside Methods, which are basically supercharged RPCs that give you automatic optimistic UI updates: https://www.meteor.com/try/10

I think this issue comes up a lot because new Meteor apps come with the "insecure" package by default to enable faster initial development and debugging, but most or all production apps will remove this package.

(I work at Meteor)

Here's step 10 of the tutorial, which demonstrates how you can write custom RPCs to handle writing data in Meteor: https://www.meteor.com/try/10

You don't have to use the client-side insert/update/remove syntax if you don't want to. Unless you add an 'allow' call to let some of them through, they will all be automatically rejected by the server.

(I work at Meteor)

I'm curious why the #2 concern is that the installation takes 20 GB. I bet most users don't have enough files and programs to fill up even a small 256 GB hard drive.

For some power users this might matter, but as far as I can tell most baseline laptops you can get with Windows offer more than enough storage.

(Disclaimer: I work at Meteor) That box is referring to the data syncing, event handling, and view rendering code that you don't have to write when you use Meteor, compared to some of the previous generation frameworks.

If you put together the right list of cutting-edge components like React, Firebase, Bootstrap, and some build tools, you might get a similar improvement in code simplicity. Our goal at Meteor is to give you the same benefits without making you write code to plumb between several different frameworks.

(I work at Meteor) We'll fix this soon! Thanks for the feedback.

Meteor has an oplog-tailing MongoDB driver, implemented here: https://github.com/meteor/meteor/blob/devel/packages/mongo/o...

You could use Meteor as your server, and talk to it over DDP from your frontend C++ app.

(Disclaimer: I work at Meteor) I'm sorry that you had such a bad experience with the transition to Blaze. We have been moving very fast on changes trying to nail down a good API for 1.0, which is coming very soon at this point. Hopefully you will give it another try when 1.0 comes out, and the API becomes stable.

One of our goals is to be suitable for enterprise and consulting shops, and that means we will need to declare a point after which we will do everything we can to maintain backwards compatibility. That point will be the 1.0 release.