We Keep Coding

Multiple DB in meteor keeping reactivity

There's some way to use more than one MongoDB database in meteor keeping reactivity/Oplog working? I've been reading about it (Post1), (Post2) and still I don't see a straighforward way to achieve this. It's possible? What's the right way? Thank you.

As you say; Default Connection isn't really an option as you can only have one DB and DDP is a bit superfluous when you only need a DB and none of the Meteor stuff. I'd think, therefore, your best approach would be to use the MongoInternals option.
The only thing missing from that option is reactivity; a method of enabling oplog tailing for these additional DB connections is mentioned in this answer. It essentially seems to be a case of passing the oplogUrl when creating the RemoteCollectionDriver, here's the example given in their answer:
var driver = new MongoInternals.RemoteCollectionDriver(
"mongodb://localhost:27017/db",
{
oplogUrl: "mongodb://localhost:27017/local"
});
var collection = new Mongo.Collection("Coll", {_driver: driver});

I'm going to write here what I've discovered until now, but I'm not going to mark the question as answered.
Concepts
What is reactivity?
Using reactivity, the data you show to your users will be updated in real time. You can enable or disable reactivity when you subscribe to a collection. Like this:
// enabled by default
Meteor.publish('top', function() {
return Top.find({},{reactive: false});
});
What is oplog?
Oplog is the MongoDB log. When you tell meteor to use oplog, reactivity performance is much better, unless you have a really high volumne of insert operations. In this cases may be wise to keep it disabled. Oplog can optimize your reactive DB calls by ~x5 ~x20.If you are going to use oplog you should optimize your db calls. You can read more about it here.
What methods exists to connect DBS to meteor?
Default connection:
Reactivity? yes. Oplog? yes. DB Limit? One. Description: Meteor creates a default MongoDB database when you run 'meteor'. You can set a different database using enviromental variables, or just MONGO_URL=mongodb://localhost:27017/db_name meteor.
DDP:
Reactivity? yes. Oplog? yes. DB Limit? no. Description: You need a meteor project for every DB. That's about 600MB in memory for every DB. You can read about it here and here.
MongoInternal (SOLUTION: Thanks to carlevans719):
Reactivity? yes. Oplog? yes. DB Limit? no. Description: You can specify a DB in your subscriptions file like:
ar database = new MongoInternals.RemoteCollectionDriver('mongodb://user:password#localhost:27017/meteor', {oplogUrl: "mongodb://localhost:27017/local"});
var numberOfDocs = database.open('boxes').find().count();
Last Words:
MongoInternal If you are not going to use the default db, you have to tell meteor to do not create it. To achieve this you must always run meteor as MONGO_URL=mongodb://localhost:27017 meteor

Sails.js simple private messaging (pub/sub and models)

My Goal:
Create a private messaging platform using Sails.js with the simplest code possible
Assumptions of Best Practices:
Use Sails.js Webockets for realtime notifications
Use Sails.js PubSub for DB use with websockets
Use Sails.js .watch() to get messages
My Questions:
Can I have a socket watch only certain new models (e.g. find where userid matches sender or recipient id) OR do I need to set up rooms? Selective watching seems much easier, but the documentation doesn't seem to support it.
If any of my above assumptions or questions are not the best way to realize my goal, then what is the simplest way to implement private messaging using Sails?
What I've Tried:
Subscribing and watching a socket
Reading the Sails.js documentation
Looking at the sailsChat example (uses rooms)
Searching StackOverflow and Google for sails chat examples

The simplest way I guess it is using the socket.io implemented in sails, if I remember correctly it is simply called socket.
All controllers can be called with socket.io (client side) IIRC.
The approach that I took is to create a model called messages, and then simply create few endpoints for the messages. If you want to use the models (pub/sub) it is possible to subscribe just to the ones you want. you can subscribe every single user to just a single Model, even if you have plenty of them.
What I used to do is do it manually, when I receive one message, i would emit it to the right client straight away. But if you want to write less code probably you simply have to subscribe the users to your model Model.subscribe()( http://sailsjs.org/documentation/reference/web-sockets/resourceful-pub-sub/subscribe )
so when a message is added to the Database then you can send it to whoever you need to.
Here's another example of a chat built on top of sails.js: https://github.com/asm-products/boxychat-old

Best practice for node - mongo - angular

I have an app I am designing using node/mongo/angular, what I am not getting is how is the best way to get my data from mongo into my pages? I can use node, and thru my routes send back data from mongo with my template(hogan in this case), and bind using mustachejs. That works fine for most things. I have one screen that has a decent amount of drop down lists, to bind them for an edit scenario now seems a challenge. I would like to get them bound to an angular model and go about it that way. Is it better to get the data thru the route in node, then use something like ng-init and get it into angular? Or would I be better off not getting the data thru the route in node, and then using angular to perform a "get" request and bind that way?

From the documentation of ng-init, more precisely from the red warning alert at the top of the page...:
The only appropriate use of ngInit is for aliasing special properties of ngRepeat, as seen in the demo below. Besides this case, you should use controllers rather than ngInit to initialize values on a scope.
So no, do not use ng-init. While that can be a good strategy for lazy migrations from regular applications to single page applications, it's a bad idea from an architectural point of view.
Most importantly, you lose two things:
An API. The benefit of SPAs is that you have an API and that you're constantly developing and maintaining it, even before it has external users
A clean separation of concerns. Views are strictly limited to presentation, can be cached by the client and all data is transferred through JSON API endpoints.

I would say that the best way to get data from Mongo into your page, is as mnemosyn said, using an API.
Basicly, you can have your API route, f.ex '/api/data' configured and then it can be used by a angular service, (which can use ngResource to make things easier). Any controller that wishes to access this data can use the angular service to get it, do some stuff with it, and then update it using the same angular service.

Insert/Upsert to a Meteor Collection with Unacknowldeged Write Concern

In Meteor, how do you Insert/Upsert to a Meteor Collection with Unacknowldeged Write Concern w=0?
Can the write concern be set during the insert/upsert, rather than as a environment variable?

Yes, you can pass writeConcern as of Mongo v2.6:
http://docs.mongodb.org/manual/reference/command/insert/#dbcmd.insert
No, you can't pass that option in Meteor. It's not documented here:
http://docs.meteor.com/#update
I did some digging to see what you'd have to do if you wanted to patch Meteor. Here is the link to their update/insert/upsert code:
https://github.com/meteor/meteor/blob/devel/packages/mongo/collection.js
It looks like it delegates to DDP which is their Distributed Data Persistence framework. Hope that helps.

Meteor & Backbone Sync

I search best way to sync my Backbone.Collection and Meteor MongoDB Collection.
What a best way for it? I want make POST/GET request thru the client.

Meteor already keeps your server collections and client-side cached collections in sync. If you wish to use backbone.js collections, you can do it in two ways.
First way: use an observe on MongoDB cursor, look for all 'added', 'changed' and 'removed' events and deal with them however you want. More in docs.
Second way: to keep memory consumption lower and not keep two copies of every object in both Minimongo and Backbone collections, you can go one level lower and use registerStore - client-side DDP API.
For API docs look at the source code. Also DDP specs can help, look at "Managing Data" section.