Your main entry point into Grind during dev time is the watch
command:
bin/cli watch
This will start the server on whatever port specified in config/app.json
(3000 by default), and monitor for changes in the app
and config
directories.
Warning Do not use
watch
in production as it will drastically slow your server down.
Grind leverages the the popular chokidar package to monitor changes in your app
and config
directories. When a change is reported, Grind does the following:
- Shuts down the HTTP server
- Loops through node’s require cache and clears all entries related to the
app
directory - Starts the server again
By hot-reloading code, Grind is able to apply changes rapidly and get out of your way.
Since watch
is tightly integrated with Grind itself, if something goes wrong during startup such as a syntax error, it’s able to start a temporary HTTP server on the same port and bring you the error right in your browser:
Unfortunately
watch
is only able to surface errors in browsers during a restart and not initial startup. This is due to not knowing what port to start up on during initial boot. Once it’s successfully booted the first time, it remembers the port and is able to server errors on it should something go wrong.
There’s three extremely important rules to remember when running Grind in production:
- Never use
watch
- Always remember to transpile via
bin/build
- Make sure
NODE_ENV
is set toproduction
— this tells Express to boot up in production mode, turning off certain debug features and otherwise tuning for production use.
There’s other things to know, but as long as you follow the aforementioned rules, you’ll be on the right track.
Actual deployment methods will differ depending on tools, but overall your deploy strategy should look something like this:
git pull productionbin/buildNODE_ENV=production build/bin/cli serve --cluster
Running bin/build
will transpile through Babel right away, avoiding the overhead cost of doing some at runtime.
Be sure to run build/bin/cli serve
once you’ve ran bin/build
otherwise you’ll still be running through Babel, defeating the purpose of proactively transpiling.
Running with the --cluster
flag is important, it let’s Grind start multiple servers (1 per CPU core) which will give you far greater performance at scale.