2

This question is probably obvious, but I don't quite get it yet. To my knowledge a Rails app is deployed by using a web server like Apache or nginx or a cloud provider like Heroku.

What is the responsibility of a webserver like Apache/nginx. Why is the Rails app not simply run on WEBrick only by running rails server.

Mahoni
  • 7,088
  • 17
  • 58
  • 115
  • possible duplicate of [Webrick as production server vs. Thin or Unicorn?](http://stackoverflow.com/questions/10859671/webrick-as-production-server-vs-thin-or-unicorn) – JAL Oct 19 '13 at 23:00

2 Answers2

2

Basically, it sounds like your question is:

Q: Why not just use WebBrick as a production server (instead of only for RoR development)?

Here are several good discussions:

And from the Arch Linux documentation:

While the default Ruby On Rails HTTP server (WeBrick) is convenient for basic development it is not recommended for production use. Generally, you should choose between installing the Phusion Passenger module for your webserver (Apache or Nginx), or use a dedicated application-server (such as Mongrel or Unicorn) combined with a separate web-server acting as a reverse proxy.

Community
  • 1
  • 1
paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • Well not so much. Apparently, it's a more convenient deployment and of course a lot faster. No, the question is more like. What tasks does Apache/nginx fulfill? Do they take in the requests and route them to the Ruby process running the Rails app? – Mahoni Oct 19 '13 at 21:52
  • 1) Ruby is a programming language, 2) Rails is a framework programmed in Ruby, 3) a user interacts with an RoR application via a web browser, and 4) HTTP is the transport used to communicate between the user and the application. For development purposes, Webbrick is a perfectly good HTTP server. For production purposes, Apache is often a much better choice. It's really as simple as that: Apache's "responsibility" is to mediate the HTTP transport layer. – paulsm4 Oct 19 '13 at 22:31
  • Q: Is your question answered? Q: What is the role of Apache/nginx? A: to provide an HTTP transport between the RoR application and the end user. Same for webBrick, IIS, and a hundred other alternatives. Also look at this: [How does PHP interface with Apache?](http://stackoverflow.com/questions/2772400/how-does-php-interface-with-apache/2772423#2772423). The principle is similar for any web server, with any language interpreter (like the Ruby interpreter). 'Hope that helps... – paulsm4 Oct 20 '13 at 01:27
2

I'd probably rephrase your question as "why is there a separate web and application tier in Ruby apps?"

In production deployments of Ruby applications there is typically a web tier (e.g. Apache or Nginx) and an application tier (e.g. Unicorn, Thin, Passenger). The web tier and application tiers serve different purposes:

  1. Web tier - Manages HTTP connections, which are potentially persistent and long-lived. Usually responsible for some configuration of the production deployment (normalizing URLs through rewrites, blocking categories of bad requests, etc.). Sometimes responsible for HTTPS termination (especially in environments without a load balancer). Sometimes responsible for serving static assets, a task at which web servers excel. Most web servers can handle thousands of concurrent requests, with minimal resources needed per request. So if the web server can handle a request without hitting the app tier, it's strongly preferable for the web server to handle the request.

  2. Application tier - Manages requests to the application itself, which usually require some amount of application logic and access to the data storage tier. Requests are generally expected to be short lived (max a few seconds and ideally a few 10s of msec, Rails Live Streaming excepted). Concurrency is far more limited in the application tier - most app servers can handle a much smaller number of concurrent requests (1 per process for Thin/Unicorn).

Note this architecture is relatively common to other languages - PHP, Java - as these differentiations largely hold true in systems running those languages as well.

It is possible to run with a unified web and application tier, but that generally requires a system that decouples requests from threads or processes - meaning that one doesn't need a thread or process for each concurrent request. It adds some complexity to the development side (see Node.js) but can have significant scalability benefits.

Peter Goldstein
  • 4,479
  • 2
  • 19
  • 17