When creating a Meteor app., Mongo is installed by default and runs automatically when I run my app. In the past, with other non-Meteor apps, I have always tried to place my app code files and database on separate servers to ensure that I can scale them independently. It feels as though this default Mongo install is a convenient way simply for Meteor to use a database out-of-the box, just to get you going. Thinking ahead, I want my app to scale, so should I start thinking about using a Mongo instance on separate server and, if so, what process do I go through to detach this default Mongo instance from my Meteor app?
The instance of mongodb that comes with meteor is only for use when developing your app. In a production environment, you should either install your own mongo instance or use a service.
I strongly recommend using compose.io in production. We've had a really good experience with them and the most basic deployment comes with access to the oplog which is critical for scaling your app.
Either way, in production you will provide two URLs to your app via environment variables:
MONGO_URL
MONGO_OPLOG_URL (this is optional but strongly recommended)
If you go with compose, here is the guide for integrating with meteor.
Related
How the Heroku CLI tool manages DBs. What are the APIs they use? The tasks I am trying to do from the app are create/delete a postgres DB, create a dump, and import a dump using python code and not from the console or cli.
There is no publicly defined API for the Heroku Data products, unfortunately. That said, in my experience, the paths are fairly stable and can mostly be reasoned out. This CLI plugin might give you a head start on trying to work out the routes you'd need to hit in order to achieve your goals.
I am in the process of teaching myself deployment to Heroku, and trying to host a simple MERN stack application to Heroku. So far, every tutorial I've worked on (at least four so far) has told me to use the addon mLab, which is 1) being depricated and 2) currently requires payment.
I've also now tried to use object Rocket which also requires a monthly payment. Is it possible to connect my Heroku app to MongoDB without payment? Perhaps without an add-on? I'm looking to turn around and teach others how to deploy their applications to Heroku, but if there is payment involved, that would be a real issue.
Edit: just to clarify, I am aware that MongoDB atlas is free, but what I'm not aware of, is way to connect Atlas to my Heroku app in a way that is free.
Use the Atlas free tier. No addons are needed.
To connect to your MongoDB Atlas db is best achieved using Mongoose - a node module - at least that is what I am doing with my recently created React/Atlas application. Mongoose is available for Angular as well and makes working with Atlas very easy. A google search will provide many tutorials, I'm sure.
I implemented a server application with Play Framework.
I built native packages for different Operating Systems (Linux, Windows, Mac OS X) with SBT Native Packager.
This application requires a NoSQL Database. In particular, I am using MongoDB. Is there a way to embed MongoDB binary/package in my native package? Is this the best practice? Or do you suggest to install MongoDB and my Play application with two different packages?
If it is not possible / recommended to embed MongoDB in a package, do you suggest another DBMS (for instance Nitrite Database)? Thanks
This is not really best practise. Play has H2 in-memory DB embedded but this is only intended for development (because it is quicker than something that reads/writes to disk as well).
You really want to have your Mongo (or whatever other data store you decide to use) instance running in a different process, and packaged, deployed, stopped, started separately from your Play application.
You could probably figure out how to package it with your Play application and then have some script run during app startup to setup the database and load any existing data in -dbpath ie. whenever you redeploy/restart your application. But then you would have to stop/redeploy your Mongo binaries each time you redeploy a code change. You may update your application several times over a year but you are unlikely going to want to update your Mongo binaries as often. I could go on, but don't do it. It is best practise to manage your data stores separately from your applications.
I'm looking for some suggestions on how I could manage external dependencies when I want to run my Play framework based app locally.
I have a Play based application that connects to a database to look up application data. In order to run this against a specific environment, it is not a problem, but what if say I want to run this locally? With the current setup, if there is no database available, my app would just not start! I mean, without a database running my application also has no meaning as I could not do anything without data!
I'm using MongoDB as my database, so I see the following possibilities to enable running my application locally!
Use in memory mode from MongoDB
Use some sort of docker container to run a MongoDB instance locally
Is there any other possibility that is worth exploring?
I'm developing a Meteor app on cloud9 (c9.io) which is stuck on Meteor v0.5.9.
I'd like to try my app with 0.6.5.1 as I'm having a few unexplained issues.
Q: Is it possible to do a
meteor deploy myapp.meteor.com
and specify the version of Meteor.
I'm assuming not, as I guess everything's packaged up and deployed together, including Meteor itself?
Specify what version of Meteor to use locally suggest you can specify meteor versions, so may be I should set that just before deployment?
Thanks in advance.
Yes. In fact, it's the same argument as in the other question:
meteor deploy --release <tag of meteor> myapp.meteor.com
The tags are the same as in https://github.com/meteor/meteor/releases but without the release/ prefix.
However, in your case, the current version is 0.6.5.1 so if you just did a meteor update on your machine, that would be the default release for any deploy or bundling. Beware that it will be hard to go back to a previous version because of the various changes it will make.