Java Backend и Rails Frontend - PullRequest
       28

Java Backend и Rails Frontend

10 голосов
/ 27 октября 2010

У меня есть стартап, рассматривающий создание бэкэнда Java и интерфейса Rails.Бэкэнд Java позаботится о создании слоя кэширования для базы данных и предложит другие дополнительные сервисы.Интерфейс Rails в основном предназначен для создания веб-приложений и инструментов мониторинга.

Какие стартапы / компании используют такой тип настройки?Каковы некоторые проблемы с точки зрения скорости разработки, развертывания, масштабируемости и интеграции?

(Что мне может пригодиться, так это личный опыт или неформальные тематические исследования. Я хотел бы расставить приоритеты и ответить на альтернативы, такие какGrails или JRuby, если это не окажется большой частью уравнения)

Спасибо!

Ответы [ 6 ]

6 голосов
/ 27 октября 2010

Я никогда не занимался разработкой рельсов, но вот мои мысли. Почему бы просто не использовать Grails? Я проделал большую часть разработки Grails, и она хорошо работает для быстрого прототипирования. Он также предлагает всю мощь Java, Spring и Hibernate. Вместо того, чтобы общаться между двумя разными технологиями, вы можете воспользоваться тем, что Grails использует Spring и Hibernate под оболочкой для работы с кэшированием, а также с любыми другими требованиями, которые поддерживают эти технологии. Если у вас есть Java-разработчики, Grails не должно быть трудно поднять. История с плагином Grails достойная. Все они хранятся в центральном месте и их легко получить, но качество зависит от автора плагина. Вы также должны помнить, что, поскольку Grails использует Groovy, который синтаксически похож на Java и работает на JVM, очень легко использовать существующий код Java, включая множество доступных библиотек Java. Я не знаю этого наверняка, но я предполагаю, что существует гораздо больше библиотек для использования с Java и для Grails, чем доступно для языка Ruby и Rails. Я не могу призвать вас к использованию ресурсов, но у меня вопрос, сколько у вас людей с опытом проектирования систем Rails, использующих Java на бэкэнде, со всеми уловками, которые будут сопровождать это? Вы можете обнаружить, что у вас нет никого, кто опытен в отладке, когда что-то идет не так в связи между двумя технологиями.

4 голосов
/ 27 октября 2010

Я использовал подобную пару для одного из моих проектов, но вместо RoR я использовал Python. Я не думаю, что есть большая разница.

В общем, в этом типе программирования нет ничего конкретного. Две самые важные вещи, о которых вы должны заботиться:

  • хорошая модульность;
  • Хорошо продуманный протокол между RoR и Java.

Сначала речь идет о точном разложении функциональности между частями системы. У нас есть некоторые проблемы из-за того, что мы не понимаем, какую часть работы должен выполнять Java, а какую - Python. В общем, вы должны связать вместе все функции, которые находятся близко друг к другу, и вещь, которая находится далеко, должна быть связана в очень немногих местах. Я думаю, вы знаете правила хорошей модульности, но в случае составления разных языков это должно быть продумано гораздо более тщательно. Вы также можете быть заинтересованы в создании нескольких отдельных Java-сервисов (например, один для кэширования базы данных и другой для всех остальных), чтобы иметь возможность свободно комбинировать их или даже использовать позже в других проектах.

Второе касается связи между вашими частями. Я вижу два способа общения: через базу данных и через чистый сетевой протокол. Первые все равно нуждаются в некотором сетевом взаимодействии, поэтому мы использовали чистый сетевой протокол, без какого-либо другого способа соединения частей.
Мы много экспериментировали с SOAP , но он дал сотни ошибок: этот протокол вполне подходит для подключения сервисов, написанных на одном языке (например, от Java к Java), но ужасен для подключения сервисов на разных языках - автоматически инструменты для генерации WSDL дали разные результаты для Java и Python, а создание схемы вручную было трудоемким и трудоемким.
Так мы привыкли ОТДЫХ . Он использует все функции протокола HTTP, такие как все четыре основных метода HTTP (POST, GET, PUT, DELETE), коды ошибок и многое другое, поэтому он охватывает практически все, что вы можете. Единственное ограничение для REST - это то, что он не может хранить состояние, поэтому вам может потребоваться реализовать собственный механизм сессий.
Если вам не очень нравится REST и вы ищете какой-то реальный пример, см. API Graph Facebook , а для реализации служб REST в Java вы можете использовать Restlets .

2 голосов
/ 27 октября 2010

Я настоятельно рекомендую вам рассмотреть возможность использования внешнего интерфейса и внутреннего интерфейса в одной и той же JVM по соображениям производительности.

Для Rails JRuby может запускать Rails, и вы можете иметь его в контейнере Java EE, обеспечивающем быструю связь.между компонентами.

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

2 голосов
/ 27 октября 2010

Возможно, я заявляю здесь об очевидном, но самая большая проблема здесь - факт, что вы объединяете две технологии.Мало того, что разработка будет медленнее - Rails и все Java-фреймворки ожидают иметь полноценное Ruby / Java-приложение - но для других упомянутых вами проблем (развертывание, масштабируемость, интеграция) существующие инструменты и решения не будут работать или, по крайней мерене очень хорошо.

Если у вас есть веская причина объединить эти два, продолжайте, но ожидайте, что потратите больше времени на эти проблемы, чем с одним технологическим решением.Если нет, выберите либо Rails, либо Java.

1 голос
/ 23 октября 2013

Мы использовали Ruby on Rails для front-end и Core-Java SOAP Api для backend. Это сработало очень хорошо.

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

С точки зрения запуска, это лучшая стратегия. Многие считают, что ROR лучше всего подходит для стартапов ... но очень немногие знали об этом, потому что в большинстве MNC мы используем Java, поэтому существует необходимость изучать Rails и Code или нанимать очень мало разработчиков ROR. Таким образом, вместо этого вы можете использовать ROR для внешнего интерфейса (это делают лишь немногие, или его легко освоить) и использовать опытных разработчиков Java для обновления БД и бизнес-логики.

1 голос
/ 05 ноября 2010

Twitter.com предположительно использует бэкэнд Java и Rails для своего веб-интерфейса. Вот некоторые ресурсы:

http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/

http://blog.adsdevshop.com/2008/05/02/twitter-is-not-abandoning-rails/

http://twitter.com/#!/ev/status/801530348

В частности, они используют Scala на бэкэнде (который компилируется в байт-код Java):

http://www.artima.com/scalazine/articles/twitter_on_scala.html

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

Если проблема сегментации экспертизы касается вас, я бы предложил запустить JRuby of Rails. Сейчас он очень зрелый и работает лучше, чем Rails на Ruby 1.8.x.

...