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

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

  • Это в основном похоже на автоматическое пополнение / предоплаченный мобильный сервис.
  • Будет иметь логику средней сложности по сравнению с предыдущими приложениями ERP, которые я написал.
  • Разделы Views в ответе будут представлять собой обычный текст, который будет отправлен пользователю в виде запроса 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, подходят ли какие-либо из них специально для этого проекта? Я был бы признателен за хорошее сравнение с подробными соответствующими плюсами и минусами, если это возможно.


ruby ruby-on-rails comparison sinatra padrino
person Jai Madhav    schedule 11.11.2011    source источник
comment
Мета-обсуждение достоинств этого вопроса находится здесь.   -  person Wayne Conrad    schedule 24.04.2015

Ответы (1)


arrow_upward
83
arrow_downward

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

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

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

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

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

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

person Nathan    schedule 11.11.2011
comment
Спасибо Натан. Я рассмотрю ваш совет... хорошо объяснил :) - person Jai Madhav; 14.11.2011
comment
Я согласен с Натаном, для сервисного API я использую Sinatra и вызываю модули Padrino (маршрутизация, генераторы и кэширование) и Rails (ORM). Отлично работает для меня и экономит мне немного оперативной памяти, поэтому я могу запускать больше процессов Unicorn :) - person complistic; 21.05.2013