8

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?

Cristian Ciupitu
  • 6,226
  • 2
  • 41
  • 55
agent provocateur
  • 236
  • 3
  • 14
  • 7
    In the beginning Apache served static files and it was good. Then apache served CGI, and it was not so good. Ever since then we have come up with a bajillion different methods attempting to deal with the fact that plain old CGI sucks. Thin is one of those tools. – Zoredache Jun 17 '14 at 22:08
  • @Zoredache More SO answers should be written Biblically. +1! – ceejayoz Jun 19 '14 at 23:15
  • 1
    This question is less obvious than some of my colleagues seem to think. It took me quite a while to figure out how web applications in Ruby were structured. – Michael Hampton Jun 20 '14 at 22:25

1 Answers1

12

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.

Community
  • 1
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • That helps clarify things a lot, truly appreciate it. When you say that those web servers have a "single purpose," does that mean that it ONLY works with the middleware? Can Thin also serve static content like Apache? – agent provocateur Jun 20 '14 at 22:40
  • Thin _can_ serve static content, as I mentioned, it just isn't as fast at it as a traditional web server. – Michael Hampton Jun 20 '14 at 22:41