Rails，Padrino和Sinatra适用于构建预付费移动服务
我正在开发Mobile / VOIP域中的应用程序。 这对我来说真的是个灰色地带。 以下是有关该应用程序的一些细节：
- 这基本上就像是自动充值/预付费移动服务
- 与我之前编写的以前的ERP应用程序相比，它具有中等复杂度的逻辑。
- 响应中的视图部分将是纯文本，将作为SMS / USSD拉到用户和语音XML（VXML）发送，将作为IVR响应发送给用户。
- 路由逻辑非常简单，因为对于每种类型的回复，只有两到三个URL很重要。
约束：
我们拥有内置于Perl的核心系统（它是一个为许多其他VOIP /移动相关服务提供服务的遗留系统），以及一个跟踪盈利和亏损的会计系统，但它已经变得非常复杂。 因此我们决定单独制作此应用程序，并仅使用SMS / USSD和IVR。 但是，该应用程序的每个用户必须是核心系统的注册用户才能进行会计核算; 这可以通过API调用轻松实现。
现在，为了发送IVR和USSD的回复/响应，我们需要在提供这些function的供应商处部署应用程序。 但我们不希望总是需要登录到他们的服务器以获取日常报告和会计资料，因为对于我们的每个客户，我们将为USSD / SMS / IVR系统提供不同的流程。
因此，我们决定将这个新应用程序分成两个子应用程序。
- 一个应用程序将处理带有USSD / SMS / IVR域的USER接口，并将部署在供应商的服务器上，我们称之为“clientware”。
- 第二个应用程序将处理所有核心业务逻辑和报告系统，并将部署在我们的服务器上，我们将拥有完全访问权限。 我们称之为“中间件”。
应用程序的基本流程：
- 用户拨打短代码。
- 在我们的供应商服务器上调用登陆，其中clientware应用程序将处理请求并将其作为用户注册在其本地数据库中。
- Clientware还将对中间件进行API调用。 在那里注册该用户以及核心业务逻辑及时自动充值等。
- 然后，中间件还将对核心系统进行API调用，以便在那里注册该用户以用于记帐目的。
现在，将有许多此类客户端应用程序与单个中间件应用程序交互。 我们决定用Ruby构建这些应用程序。 我会遵循RESTful架构，因为涉及到大量的API调用。
在这三个框架中， Rails ， Padrino或Sinatra是否特别适合这个项目？ 如果可能的话，我将很感激地比较详细的相关利弊。
我是Padrino的创造者之一，但我也与Rails和Sinatra进行了广泛的合作。 可能不是你想听到的，但无论你选择什么，你都可以很容易地完成这个项目。 我不能说选择一个会影响你在宏观计划中挑选任何其他人。
我显然支持Rack和Sinatra的模块化和轻量级特性。 在Rack，Rack Middlewares，Sinatra和扩展之间，如果您愿意理解这些工具，您可以像在Rails中一样轻松地完成任何工作。
我认为Sinatra和Padrino对Ruby新手的学习曲线较低。 这是因为他们推广“拿你需要的东西”和“渐进的复杂性”远远超过“一劳永逸”的Rails方法，但另一方面Rails有更多的文档，博客，支持等等。所以交易很明显。 在内存占用，每秒请求数量，CPU使用率等方面，Sinatra和Padrino也“更快”和“更轻”，但Rails在大多数情况下都足够快，而且应用服务器很少成为瓶颈。
总而言之，我会尽力给你一个更直接的意见。 如果你什么都不做，除了服务API（听起来像这里），我建议使用Sinatra，Padrino甚至是我们的Renee over Rails的另一个项目。 对于轻量级服务API，Rails在大多数情况下都是过度的。
将其缩小，Padrino 是Sinatra所以你不必在它们之间做出选择。 你可以从Sinatra开始，包括来自Padrino的独立模块 ，或者使用一个完整的Padrino应用程序，它仍然是Sinatra，对访问许多强大function的性能损失非常小（i18n，logger，admin panel，caching ，发电机，表格助手，邮件等）。 请记住，这些都是“仅在您需要时才使用它们”模块化扩展。
我建议您查看我们的Padrino 入门指南，以便开始探索Sinatra和Padrino。 我们的Padrino指南和文档力求彻底。 也就是说，“安全”的赌注是Rails，因为它有更多的用法，它更成熟，有更多的贡献者和更多的文档/ googleability。 祝你好运，希望这对你有所帮助。