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

Question

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

• 这基本上就像自动充值/预付费移动服务
• 与我之前编写的 ERP 应用程序相比，逻辑复杂度中等。
• 响应中的视图部分将是纯文本，将作为 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 开始，并包含 Padrino 的独立模块，或者使用一个全栈 Padrino 应用程序，其底层仍然是 Sinatra，访问许多强大的功能（i18n、记录器、管理面板、缓存、生成器、表单）的性能损失非常小助手、邮寄者等）。请记住，这些都是“仅在需要时才使用”的模块化扩展。

我建议您查看我们的 Padrino 入门 指南，了解如何开始探索 Sinatra 和帕德里诺。我们的 Padrino 指南和文档力求详尽。也就是说，“安全”的选择是 Rails，因为它有更多的用途，更成熟，有更多的贡献者和更多的文档/谷歌搜索能力。祝你好运，希望这对你有帮助。