ruby-on-rails - tutorial - sinatra ruby

Idoneidad de Rails, Padrino y Sinatra para construir un servicio móvil prepago (1)

Estoy trabajando en una aplicación en el dominio de Mobile / VOIP. Esta es realmente una zona gris para mí. Aquí hay algunos detalles sobre la aplicación:

Esto es básicamente como un servicio móvil de recarga automática / prepago
Tendrá una lógica de complejidad media en comparación con las aplicaciones ERP anteriores que he escrito.
Las secciones de Vistas en la respuesta serán de texto sin formato, que se enviarán como SMS / USSD pull al usuario y Voice XML (VXML) que se enviará como una Respuesta IVR a los usuarios.
La lógica de enrutamiento es muy simple, ya que solo dos o tres URL serán importantes para cada tipo de respuesta.

Restricciones:

Tenemos el sistema central integrado en Perl (es un sistema heredado que presta servicios a muchos otros servicios relacionados con VOIP / Mobile) y un sistema de contabilidad para realizar un seguimiento de las pérdidas y ganancias, pero se ha vuelto muy complejo. Así que decidimos hacer esta aplicación por separado y solo usar SMS / USSD e IVR. Sin embargo, cada usuario de esta aplicación debe ser un usuario registrado del sistema central para fines contables; Esto lo podemos lograr fácilmente con solo una llamada a la API.

Ahora, para enviar una respuesta / respuesta para IVR y USSD, necesitamos implementar la aplicación en el proveedor que proporciona estas facilidades. Pero no siempre queremos tener que iniciar sesión en sus servidores para informes diarios y asuntos contables, ya que, para cada uno de nuestros clientes, tendremos flujos diferentes para el sistema USSD / SMS / IVR.

Entonces, decidimos que esta nueva aplicación se dividirá de hecho en dos sub-aplicaciones.

Una aplicación manejará la Interfaz de USUARIO con el dominio USSD / SMS / IVR y se implementará en los servidores del proveedor, lo que llamaremos "software de cliente".
La segunda aplicación manejará todos los sistemas de informes y la lógica empresarial central y se implementará en nuestros servidores, donde tendremos acceso completo. Llamaremos a esto "middleware".

El flujo básico de la aplicación:

El usuario marca el código corto.
La llamada llega a nuestros servidores de proveedores en los que la aplicación clientware manejará la solicitud y la registrará como usuario en su base de datos local.
Clientware también hará una llamada a la API de middleware. Para registrar a este usuario allí también para la lógica de negocio principal, la recarga automática a tiempo, etc.
El middleware también realizará una llamada a la API al sistema central para registrar a este usuario también para fines contables.

Ahora, habrá muchas aplicaciones de software de cliente que interactúen con una sola aplicación de middleware. Hemos decidido construir estas aplicaciones en Ruby. Estaría siguiendo la arquitectura REST para esto, ya que hay muchas llamadas a la API involucradas.

De los tres marcos, Rails , Padrino o Sinatra , ¿alguno de ellos es especialmente adecuado para este proyecto? Apreciaría una buena comparación detallada de los pros y contras relevantes, si es posible

Soy uno de los creadores de Padrino, pero también he trabajado mucho con Rails y Sinatra. Probablemente no es lo que quieres escuchar, pero no importa lo que elijas, podrás terminar este proyecto con bastante facilidad. No puedo decir que elegir uno te afectará mucho al elegir otro en el gran esquema.

Obviamente, soy un partidario de la naturaleza modular y ligera de Rack y Sinatra. Entre Rack, Rack Middlewares, Sinatra y extensiones, puede hacer cualquier cosa tan fácilmente como en Rails si está dispuesto a entender las herramientas.

Yo diría que Sinatra y Padrino tienen una curva de aprendizaje más baja para los recién llegados de Ruby. Esto se debe a que promueven "toma lo que necesitas" y "complejidad gradual" mucho mejor que más "tómalo todo de una vez". Enfoque Rails, pero, por otro lado, Rails tiene mucha más documentación, blogs, asistencia, etc. Los offs son claros. Sinatra y Padrino también son mucho más "rápidos" y "más ligeros" en términos de espacio de memoria, solicitudes por segundo, uso de CPU, etc. Pero Rails es lo suficientemente rápido para la mayoría de las situaciones y el servidor de aplicaciones casi nunca es el cuello de botella.

Dicho todo esto, intentaré darte una opinión más directa. Si no está haciendo nada más que una API de servicio (que suena como aquí), recomendaría usar Sinatra, Padrino o incluso otro proyecto nuestro Renee sobre Rails. Rails es una exageración para una API de servicio ligero según la mayoría de las medidas.

Reduciéndolo aún más, Padrino es Sinatra, por lo que no tienes que elegir entre ellos. Puede comenzar con Sinatra e incluir módulos independientes de Padrino, o usar una aplicación Padrino de pila completa que aún se encuentra bajo Sinatra con una penalización de rendimiento mínima para acceder a muchas funciones potentes (i18n, logger, panel de administración, almacenamiento en caché , generadores, ayudantes de formularios, correo, etc). Tenga en cuenta que estos son todos "tómelos solo si los necesita" extensiones modulares.

Recomendaría consultar nuestra guía de inicio de Padrino para comenzar a explorar Sinatra y Padrino. Nuestras guías y documentación de Padrino se esfuerzan por ser exhaustivas. Dicho esto, la apuesta "segura" es Rails, ya que tiene mucho más uso, es más madura, tiene más contribuyentes y mucha más documentación / googleability. Buena suerte, espero que esto haya sido útil.