我正在开发Mobile / VOIP域中的应用程序。这对我来说真的是个灰色地带。以下是有关该应用程序的一些详细信息:
我们拥有内置于Perl的核心系统(它是一个为许多其他VOIP /移动相关服务提供服务的遗留系统),以及一个跟踪盈亏的会计系统,但它已经变得非常复杂。因此我们决定单独制作此应用程序,并仅使用SMS / USSD和IVR。但是,该应用程序的每个用户必须是核心系统的注册用户才能进行会计处理;这可以通过API调用轻松实现。
现在,为了发送IVR和USSD的回复/响应,我们需要在提供这些功能的供应商处部署应用程序。但我们不希望总是需要登录他们的服务器以获取日常报告和会计资料,因为对于我们的每个客户,我们将为USSD / SMS / IVR系统提供不同的流程。
因此,我们认为这个新应用程序确实会分为两个子应用程序。
答案 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。祝你好运,希望这很有帮助。