I am working on a very typical web application. The main component of the user experience is a widget that a site owner would install on their front page. Every time their front page loads, the widget talks to our server and displays some of the data that returns.

So there are two components to this web application:

1. the front end UI that the site owner uses to configure their widget
2. the back end component that responds to the widget's web api call

Previously we had all of this running in PHP. Now we are experimenting with Rails, which is fantastic for #1 (the front end UI). The question is how to do #2, the back serving of widget information, efficiently. Obviously this is much higher load than the front end, since it is called every time the front page loads on one of our clients' websites.

I can see two obvious approaches:

A. Parallel Stack: Set up a parallel stack that uses something other than rails (e.g. our old PHP-based approach) but accesses the same database as the front end

B. Rails Metal: Use Rails Metal/Rack to bypass the Rails routing mechanism, but keep the api call responder within the Rails app

My main question:

1. Is Rails/Metal a reasonable approach for something like this?

But also...

1. Will the overhead of loading the Rails environment still be too heavy?
2. Is there a way to get even closer to the metal with Rails, bypassing most of the environment?
3. Will Rails/Metal performance approach the perf of a similar task on straight PHP (just looking for ballpark here)?

And...

1. Is there a 'C' option that would be much better than both A and B? That is, something before going to the lengths of C code compiled to binary and installed as an nginx or apache module?

Thanks in advance for any insights.