ruby-on-rails - Rails、Padrino 和 Sinatra 构建预付费移动服务的适用性

Question

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

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

约束条件:

我们在 Perl 中构建了核心系统(它是一个遗留系统，为许多其他 VOIP/移动相关服务提供服务)，以及一个用于跟踪损益的会计系统，但它变得非常复杂。所以我们决定单独做这个应用，只用SMS/USSD和IVR。但是，出于会计目的，此应用程序的每个用户都必须是核心系统的注册用户；我们可以通过 API 调用轻松实现这一点。

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

因此，我们决定将这个新应用程序确实分为两个子应用程序。

• 一个应用程序将处理与 USSD/SMS/IVR 域的用户界面，并将部署在供应商的服务器上，我们将其称为“客户端软件”。
• 第二个应用程序将处理所有核心业务逻辑和报告系统，并将部署在我们的服务器上，我们将在其中拥有完全访问权限。我们将称之为“中间件”。

应用的基本流程:

1. 用户调用简码。
2. 调用到达我们的供应商服务器，客户端应用程序将在其中处理请求并将其注册为本地数据库中的用户。
3. 客户端也将对中间件进行 API 调用。在那里注册这个用户以及核心业务逻辑及时自动充值等。
4. 然后，中间件还会对核心系统进行 API 调用，以便在该系统中注册该用户以及用于记帐目的。

现在，将有许多这样的客户端应用程序与单个中间件应用程序进行交互。我们决定用 Ruby 构建这些应用程序。我将为此遵循 RESTful 架构，因为涉及大量 API 调用。

在这三个框架中，Rails , Padrino , 或 Sinatra , 他们中有没有特别适合这个项目的？如果可能的话，我将不胜感激详细比较相关的利弊。

Answer 1

我是 Padrino 的创建者之一，但我也广泛使用 Rails 和 Sinatra。可能不是您想听到的，但无论您选择什么，您都可以相当轻松地完成这个项目。我不能说在宏伟计划中选择一个对你的影响比选择其他任何一个都要大。

我显然是 Rack 和 Sinatra 的模块化和轻量级特性的支持者。在 Rack、Rack Middlewares、Sinatra 和扩展之间，如果您愿意了解这些工具，您可以像在 Rails 中一样轻松地完成任何事情。

我认为 Sinatra 和 Padrino 对 Ruby 新手来说学习曲线较低。这是因为他们提倡“随心所欲”和“逐渐复杂化”，远胜于“一次搞定”的 Rails 方法，但另一方面，Rails 有更多的文档、博客、支持等。所以权衡是明确的。 Sinatra 和 Padrino 在内存占用、每秒请求数、CPU 使用率等方面也“更快”和“更轻”，但 Rails 在大多数情况下都足够快，而且应用服务器很少成为瓶颈。

综上所述，我会尽量给你一个更直接的意见。如果你只做一个服务 API(在这里听起来像)，我会推荐使用 Sinatra、Padrino 或什至是我们的 Renee over Rails 的另一个项目。在大多数情况下，Rails 对于轻量级服务 API 来说是大材小用。

进一步缩小范围，Padrino 是 Sinatra，因此您不必在它们之间做出选择。您可以从 Sinatra 开始并包含 standalone modules来自 Padrino，或者使用一个全栈 Padrino 应用程序，它仍然是 Sinatra 引擎盖下的，具有非常小的性能损失，可以访问许多强大的功能(i18n、记录器、管理面板、缓存、生成器、表单助手、邮件程序等) ).请记住，这些都是“仅在需要时使用它们”的模块化扩展。

我建议您查看我们的 Padrino Getting Started开始探索 Sinatra 和 Padrino 的指南。我们的 Padrino 指南和文档力求全面。也就是说，“安全”的赌注是 Rails，因为它有更多的用途，更成熟，有更多的贡献者和更多的文档/googleability。祝你好运，希望这对您有所帮助。