适用于Rails，Padrino和Sinatra用于构建预付费移动服务 [英] Suitability of Rails, Padrino, and Sinatra for building a prepaid mobile service

问题描述

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

I am working on an application in the Mobile/VOIP domain. This is really a gray area for me. Here are some details about the application:

• 这基本上类似于自动充值/预付费移动服务

<

• 响应中的Views部分将是纯文本，将作为SMS / USSD拉到发送


• 路由逻辑非常简单，因为只有两到三个网址对每种类型的回复都很重要。

• This is basically like an auto recharge / prepaid mobile service
• Will have logic of medium complexity compared to previous ERP apps I've written.
• The Views sections in the response will be plain text, which will be sent as SMS/USSD pull to user and Voice XML (VXML) that will be sent as an IVR Response to users.
• The routing logic is very simple, as only two to three URLs will be important for each type of reply.

我们有内建的核心系统它是一个传统系统，服务于许多其他VOIP /移动相关服务）和一个会计系统来跟踪损益，但它已经变得非常复杂。所以我们决定单独做这个应用程序，只使用SMS / USSD和IVR。然而，该应用程序的每个用户必须是用于会计目的的核心系统的注册用户;这个我们可以通过一个API调用轻松实现。

We have the core system built in Perl (it's a legacy system which is serving many other VOIP/Mobile-related services), and an accounting system to keep track of profit and loss, but it has grown very complex. So we decided to make this application separately, and only use SMS/USSD and IVR. However, every user of this application has to be a registered user of the core system for accounting purposes; this we can easily achieve by just an API call.

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

Now, for sending a reply/response for IVR and USSD, we need to deploy the application at the vendor which provides these facilities. But we don't want to always need to log-in to their servers for daily reports and accounting stuff as, for each of our clients, we will have different flows for the USSD/SMS/IVR System.

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

So, we decided this new application will be indeed divided into two sub-applications.

• 将处理具有USSD / SMS / IVR域的USER接口，并将部署在供应商的服务器上，我们称之为客户端软件。


• 第二个应用程序将处理所有核心业务逻辑和报告系统，并将部署在我们的服务器上，我们将有充分的访问。我们称之为中间件。

1. 用户拨打短代码。


2. 在我们的供应商服务器上呼叫，客户端应用程序将处理请求并将其注册为本地数据库中的用户。


3. Clientware对中间件的API调用。


4. 然后，中间件还会对核心系统进行API调用，以在这里注册此用户会计目的。

1. The user dials the shortcode.
2. Call lands on our vendor servers where clientware app will handle the request and register it as a user in its local database.
3. Clientware will also make an API call to middleware. To register this user over there as well for core business logic timely auto recharge, etc.
4. The middleware will then also make API call to the core system to register this user over there as well for accounting purposes.

现在，将有许多这样的客户端应用程序与单个中间件应用程序交互。我们决定在Ruby中构建这些应用程序。

Now, there will be many such clientware applications interacting with a single middleware application. We have decided to build these applications in Ruby. I would be following RESTful architecture for this, as lots of API calls are involved.

在这三个框架中， Rails ， Padrino 或 Sinatra ，他们是否特别适合这个项目？

Of the three frameworks, Rails, Padrino, or Sinatra, are any of them specially suited for this project? I would appreciate a good comparison detailed relevant pros and cons, if possible.

推荐答案

我是Padrino的创作者之一，但我也与Rails和Sinatra广泛合作。可能不是你想听到的，但无论你选择，你将能够得到这个项目完成相当容易。我不能说挑选一个会大大影响你在选择任何其他在大计划。

I am one of the creators of Padrino but I have also worked extensively with Rails and Sinatra. Probably not what you want to hear but no matter what you pick, you will be able to get this project finished fairly easily. I can't say picking one will impact you much over picking any other in the grand scheme.

我显然是一个模块化和轻量级性质的支持者Rack和Sinatra 。在Rack，Rack Middleware，Sinatra和扩展之间，如果你愿意理解工具，你可以像Rails一样轻松地完成任何事情。

I am obviously a proponent of the modular and lightweight nature of Rack and Sinatra. Between Rack, Rack Middlewares, Sinatra and extensions, you can get anything done just as easily as in Rails if you are willing to understand the tools.

我认为Sinatra和Padrino对Ruby新手来说的学习曲线较低。这是因为他们促进采取你所需要的和渐进的复杂性，远远好于立即采取一切Rails方法，但另一方面Rails有更多的文档，博客，支持等。因此，权衡是明确的。 Sinatra和Padrino在内存占用，每秒请求，cpu使用等方面也是更快和更轻，但Rails对大多数情况来说足够快，而且应用服务器很少是瓶颈。

I would argue that Sinatra and Padrino have a lower learning curve to Ruby newcomers. This is because they promote "take what you need" and "gradual complexity" far better than the more "take it all at once" Rails approach but on the other hand Rails has much more documentation, blogs, support, etc. So the trade offs are clear. Sinatra and Padrino are also much "faster" and "lighter" in terms of memory footprint, requests per second, cpu usage, etc but Rails is fast enough for most situations and the application server is rarely the bottleneck anyways.

这么说，我会尽量给你一个更直接的意见。如果你只是一个服务API（这听起来像这里），我建议使用Sinatra，Padrino或我们的 Renee 的另一个项目在Rails。 Rails对于大多数措施的轻量级服务API是过度的。

All that said, I will try to give you a more direct opinion. If you are doing nothing but a service API (which it sounds like here), I would recommend using Sinatra, Padrino or even another project of ours Renee over Rails. Rails is overkill for a lightweight service API by most measures.

进一步缩小，Padrino 是Sinatra ，因此您不必在它们之间进行选择。您可以从Sinatra开始，包括来自Padrino的独立模块，或使用全栈Padrino应用程序这仍然是Sinatra在引擎盖下极少的性能损失访问许多强大的功能（i18n，记录器，管理面板，缓存，生成器，表单帮助，邮件等）。请记住，这些都是只有当你需要他们模块化扩展。

Narrowing it down further, Padrino is Sinatra so you don't have to choose between them. You can start with Sinatra and include standalone modules from Padrino, or use a full-stack Padrino application which is still Sinatra under the hood with a very minimal performance penalty for access to a lot of powerful features (i18n, logger, admin panel, caching, generators, form helpers, mailer, etc). Keep in mind these are all "take them only if you need them" modular extensions.

我建议检查我们的Padrino 入门指南指南，了解如何开始探索Sinatra和Padrino。我们的Padrino指南和文档努力是彻底的。也就是说，安全的赌注是Rails，因为它有更多的用法，它是更成熟，有更多的贡献者和更多的文档/ googleability。祝你好运，希望这是有帮助的。

I would recommend checking out our Padrino Getting Started guide for a place to start exploring Sinatra and Padrino. Our Padrino guides and documentation strive to be thorough. That said, the "safe" bet is Rails since it has a lot more usage, it is more mature, has more contributors and a lot more documentation / googleability. Good luck, hope this was helpful.

这篇关于适用于Rails，Padrino和Sinatra用于构建预付费移动服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！