How to connect a meteor to an existing server?

Question

I recently discovered Meteor, and I really like the simplicity that it brings to the programming of new applications. My question is: how do you connect it to an existing server? We have a significant amount of existing Clojure code that also works with MongoDB. I would like to use Meteor to create the external interface of my application. I assume that I could connect my Meteor application directly to the MongoDB instance for an external server, but that doesn't seem like good practice ... or is it?

Another option that I imagined was to access the database from webapp or Clojure code and create a separate way to communicate between them with the queue mechanism or sockets. Any hint or pointer to related documentation would be helpful!

Answer 1

Regarding the “how” to point them to the same, @Michael answer is in place; just point the Meteor web servers on the same MongoDB.

Whether it is necessary or not depends on your situation. Everything that works with the same database simplifies things.

Having separate dbs can potentially reduce the load on your db level, as you can selectively select which records / updates will be replicated between clojure and Meteor dbs.

One of the problems with any method is the speed of notification of changes. Meteor servers are currently polling DBs every 10 seconds to recognize changes. Fortunately, as soon as the oplog branch is merged with the wizard, this will give a greater speed of improving how quickly external changes made to the database (as opposed to directly through the Meteor server) are reflected in Meteor clients. Oplog support will allow Meteor servers to emulate an instance of a replica set, discarding oplog, which would mean almost instant notification of db changes.

Using a queue as a mid-tier layer is difficult and adds another point of failure. It also increases the notification delay. However, these problems can be mitigated, and in the future there may be other components of your infrastructure that benefit from this mid-range lineup. For example, other interested systems could register in the queue to receive notification of changes without a request or the need to know about your db. You can also scale your MongoDB instances yourself and set up a queue to determine what “ultimately” means in a “guaranteed consistent” guarantee.

I think the questions asked are:

• how many overlays exist between the clojure dataset and the Meteor dataset
• how fast do you need changes that need to be reflected between the two
• a mid-level queue will be useful in other circumstances as it grows.

Regarding the possible queue technologies for learning, I heard very good things about RabbitMQ . Oct The 2013 clojure meeting at NYC included a description of the transition to RabbitMQ from Amazon SQS due to latency issues with SQS, and anonymously RabbitMQ was strong for them.

Answer 2

Take a look at the settings of the Meteor environment variables. By setting these variables, you can easily define an external instance of MongoDB. In particular, that would be

$export MONGO_URL="mongodb://yourmongodbserver/your-db"

There is a screencast eventedmind.com for this particular topic https://eventedmind.com/feed/sg3ejYnmhxpBNoWan , which is quite resourceful.