Thin, ou Passenger, ou WEBrick, ou qualquer outro servidor web, tem um único propósito. Ele recebe uma solicitação HTTP da rede e a envia para o Rack e retorna a resposta do aplicativo na rede.
(Normalmente, o Rack é usado como um componente de um aplicativo Ruby completo escrito com uma estrutura como Rails ou Sinatra. Ele processa solicitações HTTP de entrada por meio de seu próprio middleware e garante que eles sejam roteados para o código correto do aplicativo.
O que acontece com o pedido depois que Thin o envia para o Rack geralmente não é uma preocupação do Thin; é a preocupação do aplicativo e do desenvolvedor do aplicativo.
A razão pela qual um servidor web Ruby é normalmente colocado atrás de um servidor web mais tradicional, como Apache ou nginx, é para desempenho. O servidor da Web Ruby é escrito em Ruby e otimizado para lidar com a pilha de aplicativos que está sendo usada. Em particular, não é necessariamente muito bom servir rapidamente a ativos estáticos. Na configuração de produção usual, um servidor da Web tradicional servirá os ativos estáticos, que O Rails pré-compila como uma tarefa de rake durante a implantação ou no primeiro acesso , e Thin (ou o seu servidor de escolha) passará todo o resto para o aplicativo. Como resultado, executar Thin alone é útil apenas em um ambiente de desenvolvimento, já que o desempenho geralmente não é um problema. Não é algo que faríamos. (E normalmente o WEBrick é usado para esse propósito, já que é o servidor web padrão para aplicações Rails.)
Como administradores de sistemas, geralmente não nos importamos com o código do aplicativo, embora em alguns casos você queira trabalhar com o desenvolvedor para avaliar qual dos vários servidores Web Ruby possíveis deve ser usado com um determinado aplicativo. Embora, como regra geral, do ponto de vista da aplicação, eles devem ser intercambiáveis.