agent provocateur asked:
This is a very noob question, and since I never really understood it, I would like an explanation:
- What is Thin (or Passenger or other alternative)?
- What is the purpose of Thin (or other alternative)?
- Why do I need Thin (or other alt.) with Apache (or Nginx or other alternative)?
- Can Thin (or other alt.) be used without Apache (or other alt.)?
- What are the differences between Thin (or other alt.) and Apache (or other alt.)?
At the moment, my current (limited and possibly mistaken) understanding of the problem is….Apache is a http web server (that acts like a reverse proxy in this case(?)) and Thin is a ruby web app server. Why they are what they are and how they work somewhat evades me.
Wording can be very confusing (e.g. web server vs. web app server, among others… (sort of like how “host” or “hostname” can be very confusing)) around the internet as well.
Where can I go to develop my “minimal understanding of the problem being solved”, if all the reading material I find online is not very clear to me?
Thin, or Passenger, or WEBrick, or any other such web server, has a single purpose. It takes an HTTP request from the network and passes it up to Rack, and returns the application’s response onto the network.
(Typically, Rack is used as one component of a complete Ruby application written with a framework such as Rails or Sinatra. It processes incoming HTTP requests via its own middleware and ensures that they get routed to the correct application code.)
What happens to the request after Thin sends it to Rack is generally not Thin’s concern; it’s the concern of the application and the application developer.
The reason that a Ruby web server is typically placed behind a more traditional web server such as Apache or nginx is for performance. The Ruby web server is written in Ruby and optimized to deal with the application stack that it is serving. In particular, it is not necessarily very good at serving static assets quickly. In the usual production setup, a traditional web server will serve the static assets, which Rails precompiles either as a rake task during deployment or on first access, and Thin (or your server of choice) will pass along everything else to the application. As a result, running Thin alone is useful only in a development environment, since performance there is generally not an issue. It is not something we would do. (And usually WEBrick is used for that purpose, as it’s the default web server for Rails applications.)
As system administrators, we generally don’t care about the application code, though in some cases you will want to work with the developer to evaluate which of several possible Ruby web servers should be used with a given application. Though as a general rule, from the perspective of the application they should be interchangeable.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.