Не секрет, что часто разработчикам приходится переходить на новые фреймворки, при этом, зачастую, приходится менять свои привычки. Эта статья как раз об этом - о впечатлениях опытного RoR разработчика, переходящего на CUBA Platform. В чем сходства и различия, что более эффективно, а что - более доступно для понимания - читайте в этой статье.
Herby Raynaud, оригинальная статья здесь
Проработав около 6 лет с приложениями на Rails, я был заинтригован и даже немного напуган, когда узнал, что на новой работе мне придется в основном кодить на Java и, в частности, использовать неизвестный мне фреймворк под названием CUBA. Несколько лет назад я писал на Java на предыдущей работе, так что я был знаком с Java, и этот язык мне нравился. Однако, меня всегда смущала и напрягала солянка из инструментов для сурового enterprise’а, таких как EJB, J2EE, JMS, JMX, Struts, AWT, Swing, JSF, Spring и т.д., необходимых, чтобы считаться компетентным Java -разработчиком, да и даже для того, чтобы построить простейшее веб-приложение.
Позже, когда я узнал о Ruby и Ruby on Rails, я почувствовал себя Дороти, попавшей из серого и унылого Канзаса в блистающий чудесный сад страны Оз. И это вполне понятно, учитывая, что, даже будучи новичком в разработке на Ruby, я был способен создать рабочее веб-приложение с помощью Rails буквально за минуты, просто выполнив восемь команд в строке терминала:
Конечно, это гипотетическое приложение для управления продажами, созданное с помощью указанных команд, довольно примитивно, но сам факт того, что я смог продвинуться так далеко и так просто - это было похоже на волшебство. Фреймворки вроде Grails и Play, испытавшие большое влияние Ruby on Rails, привносят в JVM языки похожие вещи.
Не так-то просто провести полноценное сравнение CUBA и Rails (или Grails, или Play, раз уж на то пошло), так что я остановлюсь на области, в которой эти фреймворки, в особенности Rails, пересекаются, а именно - быстрая разработка корпоративных приложений с экранами CRUD.
Возвращаясь к созданному выше приложению - вот что мы получаем после выполнения всех команд: у нас есть модель клиента с двумя строковыми полями: имя и email, у нас есть модель заказа с полем “количество” и ссылка на модель клиента по внешнему ключу. Есть скрипты миграции БД, которые создают таблицы с клиентами и заказами в БД, а также RESTful-пути к ресурсам покупателей и заказов. Наконец, команда generate scaffold генерирует базовые шаблоны экранов CRUD и для клиентов, и для заказов.
CUBA, позиционирующая себя как “Java-платформа для создания корпоративных приложений” (снова это жуткое слово на букву К на русском или E на английском), следует другому подходу к построению приложений. Для начала, чтобы работать на CUBA максимально эффективно, желательно скачать и установить отдельное приложение - CUBA Studio. Хотя оно и не является обязательным, но автоматизирует множество задач, таких как генерация шаблонного кода на Java и XML и обновление конфигурационных файлов spring и gradle. А самое главное, что в нем есть drag-and-drop конструктор GUI. Как только Studio установлена и запущена, для создания приложения нужно выполнить примерно те же действия:
- Создать новый проект
- Создать сущность Customers (клиенты)
- Создать сущность Orders (заказы)
- Сгенерировать БД и таблицы
- Сгенерировать экраны интерфейса клиентов
- Сгенерировать экраны интерфейса заказов
- Скомпилировать приложение Sales
- Запустить приложение
- Перейти на localhost:8080 в вашем браузере
Главное отличие от Rails состоит в том, что для выполнения задачи нужно действовать через Studio UI. Также, чтобы не удлинять пост, я пропустил несколько промежуточных шагов в процессе создания приложения на CUBA, таких как добавление полей к сущностям (моделям) “клиенты” и “заказы” и настройка связей между ними.
Я также добавил несколько коротких видео от команды CUBA, подробно демонстрирующих процесс создания приложения для управления продажами.
В целом, создание приложения в CUBA требует написания кода руками на каждом этапе создания приложения, что делает процесс менее эффективным, чем использование командной строки, как в Rails и других фреймворках. Тем не менее, это довольно безболезненно, а дополнительные функции CUBA более чем полностью компенсируют дополнительную работу.
Теперь, вернувшись к приложению на Rails, мы видим, что на данном этапе оно, конечно, функционально, но это всего лишь эскиз, оцениваемый неоправданно высоко.
Нет стилей в шаблонах генерации страниц, нет навигации между клиентами, заказами и продуктами, нет аутентификации или авторизации, клиенты и заказы связаны на уровне БД и моделей, но на уровне UI нет ни визуальных, ни логических признаков связи. Все это нужно создавать и настраивать перед тем, как показывать приложение конечному пользователю.
Приложение CUBA, напротив, практически готово к использованию, как можно видеть на скриншоте ниже.
В него включены:
- Встроенная тема оформления UI
- Навигация с использованием меню
- Встроенная авторизация и управление пользователями
- Встроенный настраиваемый контроль доступа: CUBA позволяет и разработчикам, и авторизованным конечным пользователям настраивать ограничения операций с сущностями, страницами и их элементами на основе ролей и принадлежности к группе с определенными правами - и все это делается внутри приложения.
- Автоматическое связывание ассоциированных сущностей в UI (т.е. можно искать клиентов через экран заказов и наоборот)
- Встроенные функциональные поисковые фильтры: пользователи могут создавать любое количество фильтров с произвольными комбинациями полей (потенциально - с заранее заданными значениями), сохранять их и передавать другим пользователям
- Возможность прямого импорта и экспорта данных для всех таблиц
- Встроенное формирование отчетов
- Системный профайлер
- Консоль JMX
- Drag-and-drop редактор интерфейса с компонентами, которые могут быть связаны с данными
- Один только GUI конструктор с лихвой компенсирует затраты времени и усилий на создание приложения.
Безусловно, CUBA и Rails - очень разные фреймворки. Цель сравнения - вовсе не в том, чтобы доказать, что CUBA - это новая замена Rails (или любому другому упомянутому фреймворку), или, что CUBA лучше Rails и наоборот. Моя цель скорее в том, чтобы продемонстрировать, что для разработчиков, которые уже вложились в Java и хотят создавать современные функциональные веб-приложения для бизнеса - и делать это очень быстро - CUBA является отличным выбором. Вы получаете удобство и простоту в использовании и множество полезных функций, как в других современных веб-фреймворках вроде Rails, и при этом обходитесь без затрат на смену платформы.
Для команды, делающей внутренние приложения у нас в Yieldmo, CUBA стала поворотным моментом. Мы стали делать приложения, которые раньше делали бы месяцами, за недели. Сейчас мы переносим внутренние приложения, созданные с помощью таких технологий, как React, Angular и Node.js. Благодаря CUBA нам не приходится каждый раз тратить время на изобретение велосипеда. Мы даже задействовали некоторые наиболее продвинутые функции CUBA для создания нашего нового флагманского продукта SAAS Engagement Management Platform (EMP™).
Конечно, есть и некоторые минусы. CUBA еще не приобрела широкую известность, и у нее нет такого огромного сообщества, как у более популярных open source платформ. Но, несмотря на это, основная команда и форум для разработчиков всегда готовы помочь. Также у разработчиков CUBA свой взгляд на некоторые вещи; по мере развития вашего приложения и его использования вы можете заметить, что есть ваш способ разработки, а есть - способ CUBA, и они разнятся. Опытным Java-разработчикам в некоторых случаях придется забыть старые шаблоны разработки и приспособиться к новым.
Примерно за 10 месяцев использования CUBA я был приятно удивлен тем, что можно сделать с ее помощью, и теперь надеюсь узнать о ней больше и увидеть, как CUBA растет и развивается. Надеюсь, этот пост побудит к этому и вас.
Cuba Studio Quickstart
Cuba Studio Quickstart 2
Cuba Studio Quickstart 3