Reaction is an open source platform, and you can run Reaction anywhere just like regular Node.js or Meteor applications. If you are looking to deploy Reaction manually, head on over to the Meteor deployment documentation for an excellent, detailed tutorial.
Docker images are pushed when Reaction successfully builds and passes all tests on the
release-x.x.x branches. These images are released on Reaction Commerce Docker Hub.
There are two Docker images available:
- reactioncommerce:reaction - the latest stable
- reactioncommerce:prequel - tagged pre-release builds.
All Reaction configuration options can be used with these deployment choices.
The Reaction core team recommends using Docker for deploying Reaction.
We recommend you deploy with at least 2GB of memory for Node and Reaction to run well.
The database is included in development, and our containers also include a MongoDB instance inside the container, but it is only intended for development and testing. It’s not a production solution, and you should provide an external replica-set db instance with oplog access enabled for production deployment.
Meteor offers hosting on their Galaxy platform.
While Meteor provide some key framework components to Reaction, the heaviest lifting is the build system. The
reaction-cli command line tool wraps the Meteor command line functionality and provides additional Reaction specific deployment options in addition to the Meteor build system.
You can read the entire guide for the Meteor build system, but the sections below are direct from that page, compiled for just the most Reaction relevant portions.
Meteor build system
The Meteor build system is the actual command line tool that you get when you install Meteor. You run it by typing the
reaction command in your terminal, possibly followed by a set of arguments. Read the docs about the command line tool or type
reaction help in your terminal to learn about all of the commands.
What does it do?
The Meteor build tool is what compiles, runs, deploys, and publishes all of your Meteor apps and packages. It's Meteor's built-in solution to the problems also solved by tools like Grunt, Gulp, Webpack, Browserify, Nodemon, and many others, and uses many popular Node.js tools like Babel and UglifyJS internally to enable a seamless experience.
Reloads app on file change
When you run
reaction, the tool starts up, and you should leave it running continuously while developing your app. The tool automatically detects any relevant file changes and recompiles the necessary changes, restarting your client or server environment if needed.
Compiles files with build plugins
ecmascript package. This package provides support for ES2015 modules, which gives you even more fine grained control over file load order using ES2015
export. As new Meteor releases add new features to this package you just get them for free.
Combines and minifies code
Another important feature of the Meteor build tool is that it automatically concatenates and minifies all of your files in production mode. This is enabled by the
standard-minifier-css packages, which are in all Meteor apps by default. If you need different minification behavior, you can replace these packages. Below, we'll talk about how to switch out a minifier to add PostCSS to your build process.
Development vs. production
Running an app in development is all about fast iteration time. All kinds of different parts of your app are handled differently and instrumented to enable better reloads and debugging. In production, the app is reduced to just the necessary code, and functions like a regular Node.js app. Therefore, you shouldn't run your app in production by running the
reaction command. Instead, follow the directions in the production deployment article.
The current best practice for deploying web production applications is to concatenate and minify all of your app assets. This lets you add all of the comments and whitespace you want to your source code, and split it into as many files as is necessary without worrying about app performance.
Every Meteor app comes with production minification by default with the
standard-minifier-css packages. These minifiers go to some extra effort to do a good job - for example, Meteor automatically splits up your files if they get too big to maintain support for older versions of Internet Explorer which had a limit on the number of CSS rules per file.
Minification usually happens when you
reaction deploy or
reaction build your app. If you have an error in production that you suspect is related to minification, you can run the minified version of your app locally with