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

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

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

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

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

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

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

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

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

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

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

из трех рамок, рейлинги, Падрино или Синатра, кто-то из них специально подходит для этого проекта? Я был бы признателен за хорошее сравнение подробных соответствующих плюсов и минусов, если это возможно.

17
comparison padrino ruby ruby-on-rails sinatra

1 ответов

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

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

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

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

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

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

82