Пригодность Rails, Padrino и Sinatra для построения предоплаченного мобильного сервиса

Question

Я работаю над приложением в домене Mobile / VOIP. Это действительно серая зона для меня. Вот некоторые подробности о приложении:

• Это в основном похоже на автоматическое пополнение счета / предоплаченный мобильный сервис
• Будет иметь логику средней сложности по сравнению с предыдущими приложениями ERP, которые я написал.
• Разделы представлений в ответе будут представлять собой простой текст, который будет отправлен в виде SMS / USSD-запроса пользователю и Voice XML (VXML), который будет отправлен в виде ответа IVR пользователям.
• Логика маршрутизации очень проста, поскольку для каждого типа ответа будут важны только два-три URL.

Ограничения:

У нас есть базовая система, встроенная в Perl (это устаревшая система, которая обслуживает многие другие VOIP / мобильные услуги), и система бухгалтерского учета для отслеживания прибылей и убытков, но она стала очень сложной. Поэтому мы решили сделать это приложение отдельно и использовать только SMS / USSD и IVR. Однако каждый пользователь этого приложения должен быть зарегистрированным пользователем базовой системы для целей бухгалтерского учета; этого мы легко можем достичь, просто вызвав API.

Теперь для отправки ответа / ответа для IVR и USSD нам нужно развернуть приложение у поставщика, который предоставляет эти возможности. Но мы не хотим, чтобы нам всегда приходилось входить на их серверы для ежедневных отчетов и учета, поскольку для каждого из наших клиентов у нас будут разные потоки для системы USSD / SMS / IVR.

Итак, мы решили, что это новое приложение действительно будет разделено на два подприложения.

• Одно приложение будет обрабатывать интерфейс USER с доменом USSD / SMS / IVR и будет развернуто на серверах поставщиков, которые мы будем называть «клиентским ПО».
• Второе приложение будет обрабатывать все основные бизнес-логики и системы отчетности и будет развернуто на наших серверах, где у нас будет полный доступ. Мы будем называть это «промежуточным программным обеспечением».

Основной поток приложения:

1. Пользователь набирает шорткод.
2. Звонки поступают на серверы наших поставщиков, где клиентское приложение обработает запрос и зарегистрирует его как пользователя в своей локальной базе данных.
3. Clientware также выполняет API-вызов для промежуточного программного обеспечения. Чтобы зарегистрировать этого пользователя, а также для своевременного автоматического пополнения основной бизнес-логики и т. Д.
4. Промежуточное программное обеспечение затем также выполнит API-вызов к основной системе, чтобы зарегистрировать этого пользователя и для целей учета.

Теперь будет много таких клиентских приложений, взаимодействующих с одним промежуточным приложением. Мы решили построить эти приложения в Ruby. Я бы следовал архитектуре RESTful для этого, так как задействовано много вызовов API.

Из трех каркасов, Rails , Padrino или Sinatra , какие из них специально подходят для этого проекта? Буду признателен за хорошее сравнение подробных релевантных плюсов и минусов, если возможно.

Answer 1

Я один из создателей Padrino, но я также много работал с Rails и Sinatra.Вероятно, не то, что вы хотите услышать, но независимо от того, что вы выберете, вы сможете завершить этот проект довольно легко.Я не могу сказать, что выбор одного сильно повлияет на вас по сравнению с выбором другого в грандиозной схеме.

Я, очевидно, сторонник модульной и легкой природы Рэка и Синатры.Между Rack, Rack Middleware, Sinatra и расширениями вы можете делать все так же легко, как и в Rails, если вы хотите понять инструменты.

Я бы сказал, что у Синатры и Падрино более низкая кривая обучения для новичков в Ruby.Это потому, что они продвигают подход «возьми то, что тебе нужно» и «постепенную сложность» гораздо лучше, чем подход «возьми все сразу», но с другой стороны у Rails есть намного больше документации, блогов, поддержкии т.д. Таким образом, компромиссы очевидны.Sinatra и Padrino также намного «быстрее» и «легче» с точки зрения использования памяти, количества запросов в секунду, использования процессора и т. Д., Но Rails достаточно быстр для большинства ситуаций, и в любом случае сервер приложений редко является узким местом.

* 1008Все сказанное, я постараюсь дать вам более прямое мнение.Если вы ничего не делаете, кроме служебного API (как это звучит здесь), я бы рекомендовал использовать Sinatra, Padrino или даже другой наш проект Renee over Rails.Rails является избыточным для облегченного API сервиса по большинству показателей.

Сужая его дальше, Падрино - это Синатра , поэтому вам не нужно выбирать между ними.Вы можете начать с Sinatra и включить автономные модули от Padrino или использовать полнофункциональное приложение Padrino, которое по-прежнему находится под капотом Sinatra, с минимальными потерями производительности для доступа ко многим мощным функциям (i18n,регистратор, панель администратора, кеширование, генераторы, помощники по формам, почтовые программы и т. д.).Имейте в виду, что это все модульные расширения «бери их, только если они тебе нужны».

Я бы порекомендовал обратиться к нашему руководству Padrino Getting Started , чтобы узнать, где начать изучать Синатру и Падрино.Наши руководства и документация Padrino стремятся быть тщательными.Тем не менее, «безопасная» ставка - это Rails, так как она имеет гораздо большее использование, она более зрелая, имеет больше участников и намного больше документации / гугл.Удачи, надеюсь, это было полезно.