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

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

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

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

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