Idoneidad de Rails, Padrino y Sinatra para crear un servicio móvil prepago

Question

Estoy trabajando en una aplicación en el dominio móvil/VOIP. Esta es realmente una zona gris para mí. A continuación algunos detalles sobre la aplicación:

• Esto es básicamente como una recarga automática/prepago de servicios móviles
• Tendrá lógica de complejidad media en comparación con aplicaciones ERP anteriores que he escrito.
• Las secciones Vistas en la respuesta serán texto sin formato, que se enviarán como SMS/USSD al usuario y Voice XML (VXML) que se enviará como 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 de la base construida en Perl (que es un sistema heredado que está sirviendo a muchos otros servicios de VoIP/relacionada con el móvil), y un sistema de contabilidad para realizar un seguimiento de las ganancias y pérdidas, pero se ha vuelto muy complejo. Así que decidimos hacer esta aplicación por separado, y solo usamos 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 solo con una llamada API.

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

Por lo tanto, decidimos que esta nueva aplicación se dividirá 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 cliente".
• La segunda aplicación manejará todos los sistemas de informes y la lógica empresarial básica y se implementará en nuestros servidores, donde tendremos acceso completo. Llamaremos a esto "middleware".

El flujo básico de la aplicación:

1. el usuario marca el código corto.
2. Llamar aterriza en nuestros servidores de proveedores donde la aplicación cliente gestionará la solicitud y la registrará como usuario en su base de datos local.
3. Clientware también realizará una llamada API al middleware. Para registrar a este usuario allí también para la lógica de negocio central, recarga automática oportuna, etc.
4. El middleware también realizará una llamada API al sistema central para registrar a este usuario allí también para fines contables.

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

De las tres estructuras, Rails, Padrino, o Sinatra, ¿son algunas de ellas especialmente adecuadas para este proyecto?Apreciaría una buena comparación de pros y contras relevantes, si es posible.

Answer 1

Soy uno de los creadores de Padrino pero también he trabajado extensamente con Rails y Sinatra. Probablemente no sea lo que quiere escuchar, pero no importa lo que elija, podrá terminar este proyecto con bastante facilidad. No puedo decir que escoger uno te impactará mucho más que cualquier otro en el gran plan.

Soy obviamente un defensor de la naturaleza modular y liviana de Rack y Sinatra. Entre Rack, Rack Middlewares, Sinatra y extensiones, puedes hacer cualquier cosa tan fácilmente como en Rails si estás 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 Ruby. Esto se debe a que promueven "tomar lo que necesita" y "complejidad gradual" mucho mejor que el enfoque "tomarlo todo de una vez" de Rails, pero por otro lado Rails tiene mucha más documentación, blogs, soporte, etc. Así que las compensaciones son claras. Sinatra y Padrino también son mucho más "rápidos" y "más ligeros" en términos 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 raramente es el cuello de botella.

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

Estrechando aún más, Padrino es Sinatra por lo que no tiene que elegir entre ellos. Puede comenzar con Sinatra e incluir standalone modules desde Padrino, o utilizar una aplicación Padrino de pila completa que todavía es Sinatra bajo el capó con una penalización de rendimiento muy mínima para acceder a un montón de características potentes (i18n, registrador, panel de administración, almacenamiento en caché, generadores, formularios auxiliares, anuncios publicitarios, etc.). Tenga en cuenta que estas son todas las extensiones modulares "tómelas solo si las necesita".

Recomiendo consultar nuestra guía de Padrino Getting Started para conocer un lugar donde comenzar a explorar Sinatra y Padrino. Nuestras guías y documentación Padrino se esfuerzan por ser minuciosas. 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/capacidad de búsqueda de Google. Buena suerte, espero que esto haya sido útil.