Каковы пределы рубина на рельсах?

Question

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

Итак, я хотел бы знать, какие функции / требования выходят за рамки Ruby on Rails или, по крайней мере, требуют таких перекосов, что лучше использовать другую, более гибкую среду, даже если вам придется потерять некоторую элегантность или напишите дополнительный шаблонный код.

Answer 1

Rails (не сам по себе ruby) гордится тем, что является «Программным обеспечением с открытым исходным кодом».

На практике это означает, что авторы рельсов имеют в виду определенную целевую аудиторию (в основном сами) и специально нацеливают рельсы на это. Если функция X не нужна для этой целевой аудитории, она не добавляется.

Вдобавок ко всему, вещи, которые явно рельсы не поддерживают, которые могут волновать людей:

1. Внешние ключи в базах данных
2. Соединения с несколькими БД одновременно
3. SOAP веб-сервисы (начиная с версии 2.0)
4. Соединения с несколькими базами данных серверов одновременно

Тем не менее, очень легко расширять рельсы с помощью плагинов, и есть плагины, которые добавляют все перечисленные выше функции к рельсам, и многое другое, поэтому я бы не стал считать их ограничениями.

Единственное другое предостережение: рельсы построены вокруг идеи создания веб-приложений CRUD с использованием MVC. Если вы пытаетесь сделать что-то, что НЕ является веб-приложением CRUD (например, Twitter, который на самом деле является системой обмена сообщениями, или если вы безумны и хотите использовать такую ​​модель, как веб-формы ASP.NET), вы также столкнетесь с проблемами. В этом случае вам лучше не использовать рельсы, поскольку вы, по сути, пытаетесь построить лодку из велосипедных деталей.

По всей вероятности, проблемы, с которыми вы столкнетесь, которые не могут быть просто исправлены быстрым плагином или одним или двумя днями кодирования, являются внутренними проблемами с базовой средой выполнения C Ruby (утечки памяти, зеленые потоки, производительность дерьма) и т. д.).

Answer 2

Ruby on Rails не поддерживает двухфазную фиксацию "из коробки", которая может потребоваться, если ваше приложение на основе базы данных должно гарантировать немедленную согласованность И вам необходимо использовать две или более схем базы данных.

Для многих веб-приложений я бы рискнул сказать, что это не обычный вариант использования. Можно прекрасно поддерживать возможную согласованность с двумя или более базами данных. Или можно поддерживать немедленное согласование с одной схемой базы данных. Первый случай - большая проблема, если ваше приложение должно поддерживать огромное количество транзакций (обратите внимание на технический термин :). Последний случай более типичен, и Rails прекрасно работает.

Честно говоря, я бы не стал беспокоиться об ограничениях использования Ruby on Rails (или любой инфраструктуры), пока вы не столкнетесь с реальными проблемами масштабируемости. Создайте приложение killer сначала , а затем беспокойтесь о масштабируемости.

УТОЧНЕНИЕ: Я думаю о вещах, которые Rails будет трудно поддерживать, потому что это может потребовать фундаментального изменения в его архитектуре. Я буду щедрым и включу некоторые вещи, которые являются частью экосистемы гемов / плагинов, такие как принудительное использование внешнего ключа или сервисы SOAP.

Под двухфазной фиксацией я подразумеваю попытку выполнить две фиксации для физически различных серверов в одном транзакционном контексте.

Вариант использования № 1 для двухфазного принятия: вы кластеризовали свою базу данных, чтобы у вас было 2 или более серверов баз данных, и ваша схема распределялась по обоим серверам. Возможно, вы захотите зафиксировать данные на обоих серверах, потому что вы хотите, чтобы ActiveRecord решил создать «карту внешних ключей», проходящую через разные серверы.

Вариант использования № 2 для двухэтапной фиксации: вы пытаетесь внедрить решение для обмена сообщениями (извините, я разработчик J2EE по дням). Производитель сообщений связывается с брокером обмена сообщениями (один сервер) и с базой данных (другой сервер).

Answer 3

Ruby не имеет такой функциональности, как IsPostBack в ASP.Net

Answer 4

Я думаю, что здесь есть больший «мета-вопрос», на который можно было бы ответить, а именно: «когда можно положиться на внешние библиотеки, чтобы ускорить время разработки?»

Сторонние библиотеки часто хороши и могут значительно сократить время разработки, однако есть серьезная проблема, Джоэл Спольски называет это «законом утечек абстракций». Если вы посмотрите на Google, его пост появится первым. По сути, это означает, что компромисс во времени разработки означает, что вы понятия не имеете, что происходит под покровом. Поэтому, когда что-то ломается, вы полностью застряли и имеете очень ограниченные методы отладки. Это также означает, что если вы нажмете на одну из функций, которые просто не поддерживаются в RAILS, которая вам действительно нужна, у вас не будет другого шага, кроме как написать эту функцию самостоятельно, если вам повезет. Многие библиотеки могут затруднить это.

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

Сторонние библиотеки могут быть полезны для небольших и средних приложений; они могут значительно сократить время разработки и скрыть сложности, с которыми нет необходимости сталкиваться на ранних стадиях разработки. Однако, в конце концов, они догонят вас, и вам, вероятно, придется переписать или переработать свое решение, чтобы преодолеть «закон об утечках»

Answer 5

Также найдено хорошее обсуждение о пределах ActiveRecord .

Answer 6

Ответ Ориона правильный. Есть несколько жестких ограничений для AR / Rails: развертывание в Windows, разъемы AR, которые не часто используются, например, Firebird,), но даже в тех вещах, о которых он упомянул, о нескольких базах данных и серверах БД, существуют гемы и плагины, которые предназначены для устаревших, шардирующих и других причин.

Реальным ограничением является то, как много времени уходит на то, чтобы быть в курсе всех вещей, над которыми работают разработчики rails, и исследовать конкретные проблемы, учитывая количество блогов и объем рассылки.