JRuby on Rails vs Grails

Я ищу разработку нового веб-приложения, которое будет использовать много компонентов Java. Для меня очевидными вариантами для этого являются Grails или jRuby on Rails, но мне трудно найти объективные сравнения этих двух. Существуют ли какие-либо четкие причины для выбора одного из них в отношении:

  1. легкость интеграции с существующими компонентами Java (за пределами постоянного домена), например. JMS, EIP
  2. поддержка функциональных систем тестирования
  3. производительность на одной машине
  4. Масштабируемость

Я не ищу ответов, касающихся доступности разработчиков или активности сообществ.

(Я проверил Grails vs. Rails, и это не относится ко мне)

ОТВЕТЫ

Ответ 1

  • легкость интеграции с существующими компонентами Java:

проще с groovy, причиной groovy является в основном java. у вас нет больших контекстных переключателей.

  • поддержка функциональных систем тестирования

Ruby имеет свою собственную кучу тестовых фреймворков, таких как rspec/shoulda/oucumber/steak, и больше тонн. так как мне нравится синтаксис ruby, я бы предпочел те

  • производительность на одной машине

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

  • Масштабируемость

оба масштаба с помощью jvm environement. если у вас есть работающая инфраструктура для java, grails легче интегрировать.

Ответ 2

Попробуйте оба, и выберите язык и среду, которая вам подходит. Правда, пакет Grails из коробки больше подходит для интеграции Java, но многие компоненты - всего лишь несколько строк кода Ruby от интеграции с Rails. Rails 3 - отличный релиз, который не требует использования ActiveRecord, на самом деле было бы тривиально использовать Hibernate для ваших моделей. См. Также DataMapper, MongoMapper и целый набор адаптеров базы данных для баз данных SQL и NoSQL.

Кроме того, JUnit!= функциональное тестирование. Вместо этого взгляните на Cucumber + Cucumber-Rails + Capybara + Selenium для интегрированного тестирования автоматизации работы с браузером. Посмотрите https://github.com/elabs/front_end_testing для примера приложения, демонстрирующего этот стек.

Я предполагаю, что Ruby лучше подходит для использования в качестве языка веб-интеграции, а JRuby поражает сладость интеграции с Java как легко, так и приятна, одновременно предоставляя вам множество библиотек, отличных от Java. Не думайте, что Groovy автоматически выигрывает, потому что он "ближе" к Java. Иногда вам нужно перейти в освежающе другую среду, чтобы иметь новый взгляд на то, как решить проблему.

Раскрытие информации: как член команды JRuby мое смещение очевидно в моем ответе.

Ответ 3

Я знаю, что Grails очень хорошо (сейчас я работаю над проектом Grails), но не JRuby, поэтому считайте это скорее предвзятым мнением: глядя на документацию JRuby, похоже, что интеграция JRubys с Java немного более громоздким, поскольку Java более родная в Groovy, чем в Ruby; поэтому в JRuby у вас есть много специфичных для Java ключевых слов и методов (например, java_import, java_send). Проще говоря, Groovy - это язык, ориентированный именно на мир Java, а JRuby - это, ну, Ruby на JVM.

У Grails есть встроенные тесты JUnit.

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

Ответ 4

  • Как сказал phoet, Grails имеет первоклассную поддержку Spring, поэтому, как правило, очень легко интегрировать библиотеки Spring - то, что делают многие плагины, включая плагин JMS.

    Java-код может быть предоставлен в JAR или помещен в каталог src/java проекта. Groovy классы могут ссылаться на классы Java, которые могут ссылаться на классы Groovy. Это довольно бесшовно.

  • У Grails есть поддержка HtmlUnit, Selenium-rc и WebDriver через различные плагины. Geb имеет большой интерес на данный момент, особенно в сочетании со Spock.

  • Протестируйте их. Я не знаю, есть ли какие-либо недавние сравнения, но производительность обычно сильно зависит от вашего приложения. http://grails.org/ и http://beta.grails.org/ работают на одна машина - и оба приложения Grails.

  • Я собираюсь довольно легко сгруппировать Grails через Terracotta. Вы также можете сделать это с простым Tomcat, если хотите. Есть варианты для распределенного кэширования - SpringSource имеет свое (коммерческое) предложение в виде GemFire.

Надеюсь, что это поможет, и в интересах полного раскрытия я являюсь членом команды Grails.

Ответ 5

В конце концов, вы собираетесь принять решение о личном выборе, комфорте с двумя языками и наличии ресурсов, но, в конце концов, тот факт, что Grails основан на Spring, привел меня к выводу, что это был правильный выбор для меня. Я знал, что если все остальное не сработает, я могу вернуться к использованию проверенной и достоверной Spring Framework

Ответ 6

Для новичков, заинтересованных в этом вопросе в 2012 году...

"С @CompileStatic производительность Groovy примерно в 1-2 раза медленнее, чем Java, и без Groovy, она примерно в 3-5 раз медленнее. (...) Это означает, что Groovy готов для приложений, производительность которых должна быть несколько сопоставима с Java.

Тест производительности: Groovy 2.0 против Java http://java.dzone.com/articles/groovy-20-performance-compared

И кроме автора, я использовал Groovy с 2008 года с большим успехом, а не только для CV, просто для того, чтобы сделать работу в нужное время. Производительность всегда относительно того, что вы хотите сделать.

Об интеграции, Grails действительно "это хорошо". Мне никогда не нужно было сделать еще один шаг, чтобы интегрировать его с существующими библиотеками. Напротив, природа Grails, основанная на Spring, сделала работу еще проще.

Для тех, кто может жаловаться на микро-тесты и реальные варианты использования, вот несколько старых (Grails 1.8), но хороших с веб-фреймворками (Grails 1.3.7): http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

Надеюсь, это поможет!

PS: Мне бы хотелось увидеть недавние бенчмарки с JRuby и другими действительно динамичными языками JVM.