4

Currently I've already read a lot tutorials teaching about Rails App deployment, almost every one of them use Nginx or other alternatives like Apache to serve static pages. Also in this QA Why do we need nginx with thin on production setup? they said Nginx is used for load balancing.

I can understand the reasons mentioned above, but I write a Rails App as a pure API backend service, the only purpose is to serve JSON formatted data for other client-side apps, no pages rendering at all. So my questions are:

  1. In my situation, do I really need Nginx just to deploy a pure API Rails App?
  2. If not, how should I deploy my app? just running it (with unicorn in production env) at background is good enough? like rails server -e production -d?

I'm so curious about these two question, hope someone can explain the details or show me some good references for me, thanks in advance.

Community
  • 1
  • 1
nightire
  • 1,371
  • 2
  • 11
  • 21

2 Answers2

3

See basically, Unicorn or thin are all single threaded servers. Which in a way means they handle single requests at a time, using defering and other techniques.

For a production setup you would generally run many instances of unicorn or thin ( depending on your load etc ), you would need to load balance b/w those rails application server instances, thats why you need Nginx or something similar on top.

Rishav Rastogi
  • 15,484
  • 3
  • 42
  • 47
  • Let me summarize clearly: so I should run multiple unicorn instances at the same time, and let Nginx dispatch client requests for each of those in balance, and it is nothing to do w/ serving static assets, am I right? – nightire Sep 21 '14 at 11:06
  • Actually, Thin has a threaded mode, so it's not necessarily single-threaded. However, setting it up is really tricky. – D-side Sep 21 '14 at 11:13
  • @nightire yes, thats what i mean. – Rishav Rastogi Sep 24 '14 at 05:17
2

to serve JSON formatted data for other client-side apps, no pages rendering at all

You see, it makes no difference. These tasks are similar: format certain data into a specific text-based structure. Much like rendering a view in HAML, ERB or whatever.

The difference is, you won't be serving static assets. At least, it's not practical for pure JSON APIs.

If you aim for compact JSON responses, your best bet is Unicorn (several workers) + nginx.

Unicorn is simpler and aims for fast single-client response. That is, a slow client could force Unicorn to waste a lot of time serving him a response. When backed by nginx though, it fires the entire response into nginx's buffer and heads for the next one only waiting for nginx to accept the response (since it's usually on the same machine, it's blazing fast). nginx then hands out responses. There could possibly be multiple instances of Unicorn, if one is not enough: but using only one could eliminate any kinds of data races on app level (which are possible in multithreaded apps).

Thin is designed by itself to handle multiple clients concurrently by itself, through use of threads and workers. Keep in mind though that MRI ("classic" Ruby) doesn't have "truly concurrent threads" because of GIL. Technoligies it's based on (Ruby+C) make it inferior to nginx (pure C) in terms of resource usage efficiency. nginx is even used sometimes to counter DDoS attacks, efficiency is proven in the wild (<1> <2> <3> and many more).

You could benefit from Thin if your app implied concurrent service for multiple clients, like Server-Sent Events or WebSocket usage, that require maintaining a constant connection. This one doesn't seem to. Don't count on concurrency too much where it's not required.

Community
  • 1
  • 1
D-side
  • 9,150
  • 3
  • 28
  • 44