Search code examples
phprubyweb-applicationsfastcgi

Ruby web application working modes


When I write web app on PHP it can works in different modes: like FCGI (php-fpm), like apache module (mod_php) and so on. In all this cases when I am editing my PHP scripts application updates immediatelly without need to restart a server. I know that Ruby web app also can works in different modes (i.e. FCGI withing Unicorn + Nginx). But I want to get an idea about all the most common ways to launch Ruby web app and techincal details about all this means (i.e. when I should restart my server to update scripts), their proc and cons.


Solution

  • There are many ways to write Ruby applications, classic 1990s-style CGI, FastCGI, independent HTTP-capable processes with Mongrel or Thin and the more modern, recommended approach which uses a launcher like Passenger to manage the processes more directly.

    Ruby on Rails can have several operating modes. The default two are development and production. These have some important differences:

    In development:

    • Anything in app/ or config/routes.rb is reloaded for each request.
    • The log/development.log is as verbose as possible, recording each query executed.
    • Assets are served up in their raw form, can be changed any time.

    In production:

    • Application is loaded once and cached, any changes require a restart.
    • The log/production.log file contains only errors and important notifications.
    • Assets are minified, compressed, and served up in bundles. Even minor changes require repackaging everything.

    It's generally a bad idea to be editing scripts on a production server, so the Rails approach is usually a good thing. If you need to rapidly iterate on something, do it on your local copy and push the changes to the server only when you're confident they'll work.

    If you really need to emergency fix something on the server, you can edit the code, then touch tmp/restart.txt to force a reload. When you change assets you'll have to run rake assets:precompile to repackage them.

    Like a lot of things, Rails makes the recommended approach easy and the risky one hard.