Rails,Padrino和Sinatra适用于构建预付费移动服务

时间:2011-11-11 06:56:51

标签: ruby-on-rails ruby comparison sinatra padrino

我正在开发Mobile / VOIP域中的应用程序。这对我来说真的是个灰色地带。以下是有关该应用程序的一些详细信息:

  • 这基本上就像是自动充值/预付费移动服务
  • 与之前编写的ERP应用程序相比,它具有中等复杂度的逻辑。
  • 响应中的视图部分将是纯文本,将作为SMS / USSD拉到用户和语音XML(VXML)发送,将作为IVR响应发送给用户。
  • 路由逻辑非常简单,因为每种类型的回复只有两到三个URL。

的约束:

我们拥有内置于Perl的核心系统(它是一个为许多其他VOIP /移动相关服务提供服务的遗留系统),以及一个跟踪盈亏的会计系统,但它已经变得非常复杂。因此我们决定单独制作此应用程序,并仅使用SMS / USSD和IVR。但是,该应用程序的每个用户必须是核心系统的注册用户才能进行会计处理;这可以通过API调用轻松实现。

现在,为了发送IVR和USSD的回复/响应,我们需要在提供这些功能的供应商处部署应用程序。但我们不希望总是需要登录他们的服务器以获取日常报告和会计资料,因为对于我们的每个客户,我们将为USSD / SMS / IVR系统提供不同的流程。

因此,我们认为这个新应用程序确实会分为两个子应用程序。

  • 一个应用程序将处理带有USSD / SMS / IVR域的USER接口,并将部署在供应商的服务器上,我们称之为“clientware”。
  • 第二个应用程序将处理所有核心业务逻辑和报告系统,并将部署在我们的服务器上,我们将拥有完全访问权限。我们称之为“中间件”。

应用程序的基本流程:

  1. 用户拨打短代码。
  2. 在我们的供应商服务器上调用登陆,其中clientware应用程序将处理请求并将其作为用户注册在其本地数据库中。
  3. Clientware还会对中间件进行API调用。在那里注册该用户以及核心业务逻辑及时自动充值等
  4. 然后中间件也会对核心系统进行API调用,以便在那里注册该用户以进行会计。
  5. 现在,将有许多此类客户端应用程序与单个中间件应用程序交互。我们决定用Ruby构建这些应用程序。我会关注RESTful架构,因为涉及到很多API调用。

    在这三个框架RailsPadrinoSinatra中,是否有任何特别适用于此项目的框架?如果可能的话,我将很感激比较详细的相关利弊。

1 个答案:

答案 0 :(得分:83)

我是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的standalone modules,或者使用一个完整的Padrino应用程序,它仍然是Sinatra,对访问许多强大功能的性能损失非常小(i18n,logger,admin面板,缓存,生成器,表单助手,邮件程序等)。请记住,这些都是“仅在您需要时才使用它们”模块化扩展。

我建议您查看我们的Padrino Getting Started指南,了解一下开始探索Sinatra和Padrino的地方。我们的Padrino指南和文档力求彻底。也就是说,“安全”的赌注是Rails,因为它有更多的用法,它更成熟,有更多的贡献者和更多的文档/ googleability。祝你好运,希望这很有帮助。