sbking

Eventually. It's on the roadmap: https://trello.com/c/sWcxRwxN/31-redis-support

One of the core developers seems to be working on it: https://github.com/meteor/redis-livedata

In production in bundles and minifies all JS and HTML into one file that is sent to the client. Then all further communication happens with JSON over WebSockets/SockJS. If changes are made to the JS/HTML, the server will send down a new application bundle and hot-reload the app without interrupting the user if you are storing the user's app state in the Session.

The CSS is also bundled in production. When further changes are made to the CSS, the new stylesheet is live-injected into the running apps without reloading the browser.

It seems like too much magic until you've been exposed to it a bit. It's actually pretty simple to visualize what's going on under the hood, but it takes a bit to click. Reading the DDP spec and the tracker package definitely helped me grasp the concepts. The new subprojects page is also great at explaining the major Meteor components: https://www.meteor.com/projects

You need to be running the Node.js Meteor application. The client relies on DDP rather than REST and right now Meteor is the only server framework using DDP. There is, however, an isomorphic HTTP library which makes it easy to communicate with third party REST APIs on both the client and server. It is also easy to create REST endpoints for your Meteor collections, so that third party services which don't support DDP can communicate with your app.

It is very possible to use other client side frameworks such as Angular or Polymer, rather than just using Meteor's Blaze UI engine. However I find that Blaze's Template<--Helper<--Data<--Event system is extremely easy to understand and reason about.

Edit: Actually, they do seem to have a decoupled version of the Blaze UI that you could use just for your reactive DOM code and hook into a REST API. You just won't get any of the server-dependent features like full-stack automated data synchronization, hot-reload, live CSS injection, or Meteor's build chain. You just get a simple reactive template/helper/events system. http://meteor.github.io/blaze/

Another point to add is Meteor's EJSON, which is a simple spec for defining how any complex, constructed or factory-made JavaScript objects should be serialized to JSON, and then deserialized back into a full JS object with behavior. Objects inserted/retrieved to/from the MongoDB or Session variables are automatically serialized/deserialized if you have made them EJSON compatible (quite easy to do, and built-in for Date and binary objects). By sharing EJSON definitions on the client and server, you have a flexible basis on which you can build an isomorphic model layer to your liking. The constructed model objects you're working with can easily be made identical (truly or superficially, depending on your needs) on both the client and server code.

It is a full stack web framework, where you write in 100% JavaScript on the client and server, sharing much of the code with isomorphic APIs. It is not meant to be used on top of Rails, but rather as a full replacement for the combination of, say, Rails+Ember.

More that it fully simulates the mongo api. When you perform an insert/update on the client, the following will happen:

1. The command will be sent to the server.

2. The command will be performed on the local database, but backing up the original local DB state so that it can be reverted if needed.

3. Immediately, any helper functions used by templates which rely on data from the DB will react to the change in the local DB and inform their template instances to update just the relevant part of the DOM.

4. The server will eventually get the request, and authorize it based on allow/deny rules.

5. If the command was allowed, the server will update the actual DB, and use MongoDB's oplog to notify all other server instances that the data has changed.

6. Server instances will send the changed data down to all subscribed clients, which update the state of their local DBs, causing the templates to re-render the relevant parts of the DOM.

7. If the request was denied on the server, the server informs the requesting client, and the client patches up its local DB to the actual DB's state, also reverting the DOM state.

So you have built-in latency compensation and full-stack reactivity by default. The client anticipates the server's response, making the application feel extremely responsive. But if something goes wrong, the client patches itself up with the actual result. Of course you can avoid latency compensation altogether where you don't want it - just avoid using the isomorphic API on the client and use RPCs instead. The servers will still inform the other server instances and push the changed data down to all the subscribed clients, but the requesting client has to wait like everyone else before the DOM is updated.

The reasons I prefer Meteor (in no particular order):

* Fully automated build chain. No matter what kind of preprocessors I use, all my code is compiled, bundled, and hot reloaded into the application. CSS updates are automatically live injected into running applications without a browser refresh. I don't have to write any build chain code, just application code.

* Isomorphic client/server APIs, with code sharing built into the build chain. I'm using the same language with the same APIs in both environments, drastically decreasing redundant code. Clients can simulate server RPCs using the same function as the server while it waits for the server's response. If I want, I can easily make the client's simulation code different from the server's such as when I want to obfuscate something, or simply disable client simulation for certain RPCs. The package system incorporates both server and client assets, allowing drop-in full-stack components, such as...

* The Accounts UI component. A drop-in, automated SRP+OAuth authentication system that's easy to customize and restyle, or build from scratch using the simple JS authentication APIs. It takes minutes to make a web application with a fully-featured and secure authentication system with password-based and 3rd party OAuth login methods. And logging in never requires a refresh.

* Already glued together. Endpoints don't have to be hooked up; they're hooked up from default. Publish data on the server. Subscribe on the client. Add authorization rules, and I have a fully functional web application with realtime data updates, with virtually no glue code.

It was fixed about two years ago in October of 2012, when they added the accounts system and allow/deny rules. Since then they've added additional security features such as the browser policy package.

Meteor doesn't use two-way data binding. You have template instances, which are wrapped domranges based on handlebars templates that call helper functions (one way binding). You then have event handlers for templates that you assign to class selectors, which will be delegated to each template instance that is created. You then manually change the data within event handlers.

No, it's a full-stack framework, using Node.js on the server and sending down a client app bundle containing all HTML templates and JS. The client and server then communicate exclusively with JSON through a purpose-invented pubsub WebSockets/SockJS protocol they call DDP. The client has a simulated MongoDB database and thus much of the API is isomorphic, so the client will simulate the server's code while it awaits the actual server response. Client changes to the data are immediately effected in the browser DB, while the change is authorized on the server, synced to other server instances with MongoDB oplog, and then pushed down to all clients subscribed to that data. The templating engine is then reactively informed of the data change, and the DOM is updated at the lowest level possible such as modifying an individual text node.