I am working on an application in the Mobile/VOIP domain. This is really a gray area for me. Here are some details about the application:

• This is basically like an auto recharge / prepaid mobile service
• Will have logic of medium complexity compared to previous ERP apps I've written.
• The Views sections in the response will be plain text, which will be sent as SMS/USSD pull to user and Voice XML (VXML) that will be sent as an IVR Response to users.
• The routing logic is very simple, as only two to three URLs will be important for each type of reply.

Constraints:

We have the core system built in Perl (it's a legacy system which is serving many other VOIP/Mobile-related services), and an accounting system to keep track of profit and loss, but it has grown very complex. So we decided to make this application separately, and only use SMS/USSD and IVR. However, every user of this application has to be a registered user of the core system for accounting purposes; this we can easily achieve by just an API call.

Now, for sending a reply/response for IVR and USSD, we need to deploy the application at the vendor which provides these facilities. But we don't want to always need to log-in to their servers for daily reports and accounting stuff as, for each of our clients, we will have different flows for the USSD/SMS/IVR System.

So, we decided this new application will be indeed divided into two sub-applications.

• One application will handle the USER Interface with USSD/SMS/IVR domain and will be deployed on vendor's servers, which we will call "clientware".
• The second application will handle all core business logic and reporting systems and will be deployed on our servers, where we will have full access. We will call this "middleware".

The basic flow of the application:

1. The user dials the shortcode.
2. Call lands on our vendor servers where clientware app will handle the request and register it as a user in its local database.
3. Clientware will also make an API call to middleware. To register this user over there as well for core business logic timely auto recharge, etc.
4. The middleware will then also make API call to the core system to register this user over there as well for accounting purposes.

Now, there will be many such clientware applications interacting with a single middleware application. We have decided to build these applications in Ruby. I would be following RESTful architecture for this, as lots of API calls are involved.

Of the three frameworks, Rails, Padrino, or Sinatra, are any of them specially suited for this project? I would appreciate a good comparison detailed relevant pros and cons, if possible.

I am one of the creators of Padrino but I have also worked extensively with Rails and Sinatra. Probably not what you want to hear but no matter what you pick, you will be able to get this project finished fairly easily. I can't say picking one will impact you much over picking any other in the grand scheme.

I am obviously a proponent of the modular and lightweight nature of Rack and Sinatra. Between Rack, Rack Middlewares, Sinatra and extensions, you can get anything done just as easily as in Rails if you are willing to understand the tools.

I would argue that Sinatra and Padrino have a lower learning curve to Ruby newcomers. This is because they promote "take what you need" and "gradual complexity" far better than the more "take it all at once" Rails approach but on the other hand Rails has much more documentation, blogs, support, etc. So the trade offs are clear. Sinatra and Padrino are also much "faster" and "lighter" in terms of memory footprint, requests per second, cpu usage, etc but Rails is fast enough for most situations and the application server is rarely the bottleneck anyways.

All that said, I will try to give you a more direct opinion. If you are doing nothing but a service API (which it sounds like here), I would recommend using Sinatra, Padrino or even another project of ours Renee over Rails. Rails is overkill for a lightweight service API by most measures.

Narrowing it down further, Padrino is Sinatra so you don't have to choose between them. You can start with Sinatra and include standalone modules from Padrino, or use a full-stack Padrino application which is still Sinatra under the hood with a very minimal performance penalty for access to a lot of powerful features (i18n, logger, admin panel, caching, generators, form helpers, mailer, etc). Keep in mind these are all "take them only if you need them" modular extensions.

I would recommend checking out our Padrino Getting Started guide for a place to start exploring Sinatra and Padrino. Our Padrino guides and documentation strive to be thorough. That said, the "safe" bet is Rails since it has a lot more usage, it is more mature, has more contributors and a lot more documentation / googleability. Good luck, hope this was helpful.