17

For production why should I "bundle" the meteor application and not just copy the sources on the server use the "meteor" command?

Basically what is the difference between:

  • "meteor bundle app.tar.gz", then installing the right version of fibers and nodejs and extracting the archive and starting with "node main.js" the app,

  • and copying the project sources on the server and just writing "meteor" to start the app?

esgy
  • 392
  • 3
  • 11
  • 1
    I can't quit answer your question, but one thing I have observed when I was faced with this decision was that running meteor uses a lot more CPU cycles on the server than starting the bundle (node.js). The amount of CPU time spent by meteor also seemed directly proportional to the number of files in the project (reactive) directories. So my suspicion is that meteor keeps monitoring the directories for changes, whereas the running bundle doesn't. Also, for what it's worth, I had stability issues with `meteor --production` but not with the bundle (though I also upgraded node.js in between). – Christian Fritz Jan 23 '14 at 18:30

2 Answers2

16

This won't be an exhaustive list, but here are some things that the meteor command does:

  1. creates a local database
  2. watches on every dependent file in your app or in your packages
  3. sends every file separately and unminified to the client (this is super inefficient unless you are developing locally)

In contrast, bundling an app:

  1. does not create a local database
  2. does not spend CPU watching your files for changes
  3. creates two minified files (js and css) which is perfect for putting on a CDN or hosting from a reverse proxy. These are also efficient for clients to download and are highly cacheable.

In general, deploying shouldn't be a huge pain if you use a good set of scripts.

Community
  • 1
  • 1
David Weldon
  • 63,632
  • 11
  • 148
  • 146
  • 1
    if you run "meteor run --production" your files are minified and i'm not sure but i think that hot code reload is also disabled in this mode – Rebolon Jan 24 '14 at 15:11
  • 1
    No, hot push reloads are enabled in production mode as well. It is useful for soft updating your clients in production making sure they are always on the latest version – imslavko Jan 25 '14 at 08:20
  • 4
    It does not seem that `meteor run --production` is all that different from bundling if you are hosting an app for not a huge number of users, and you can spare the CPU for watching (besides, the watching happens by the OS if supported, not polling.) – Andrew Mao Jan 30 '14 at 16:13
1

When using a bundle:

  1. It will not spawn meteor-mongo(Mongodb inside meteor)
  2. No hot reloads
  3. Meteor will not watch your files.
  4. You can leave/quit the server without killing your app.
  5. You can manage node processes smoothly by using pm2 or other similar npm packages.
  6. You can decide where to put your mongoDB and decide what port to use.
  7. You can connect to your mongodb remotely by not having to run your meteor app.

While using a copy or running meteor command in the project directory:

  1. You can't leave/quit the server while keeping the project running without using any screen multiplexers (e.g. tmux)
  2. You can only use meteor's assigned mongodb which is spawned in localhost:3001 -- if meteor is using port 3000.
  3. You are letting meteor to watch over file changes which uses CPU.
  4. When your app dies, your db dies. :)
gone43v3r
  • 397
  • 1
  • 6
  • 1
    Well, if you use:
    *set MONGO_URL=mongodb://localhost:27017/*, you can host your mongo db outside meteor. Your mongo database will live outside your app and if you kill your app, your database is still perfectly available.     – Manuel Rivera Jun 11 '17 at 23:51