Привет! Меня зовут Дима Татаринов, я занимаюсь бэкенд-разработкой в К2Тех. Мы живем в эпоху «великого переселения» СУБД с SQL Server, IBM DB2 и Oracle на отечественную СУБД Postgres Professional или аналоги. Подобные проекты «паровозиком» цепляют за собой потребность в модернизации бизнес-приложений, которые на них работали. Ранее зарубежные производители накладывали сильный вендор-лок с помощью экосистемы своих инструментов: от специализированного языка написания бизнес-логики (PL/SQL для Oracle) до сервера приложений. Именно поэтому особенно злободневной становится старая шутка про Oracle - «Oracle doesn't have clients. It has hostages» (У Oracle нет клиентов. Есть только заложники).
Цена освобождения уже стала известна российским вендорам прикладного ПО, которые реализовали в своих продуктах миграцию на отечественные СУБД. Но что делать с тысячами так называемых «учетных систем», которые используют компании на момент принятия решения о миграции. Понятно, что затрат не избежать, но как сделать их предсказуемыми и не получить новый «вендор-лок» взамен старого?
С таким запросом к нам стали часто обращаться корпоративные заказчики, и мы решили посмотреть на предложения вендоров в этом сегменте.
Что такое учетная система (CRUD-приложение)
Учетная система — это разновидность прикладного решения, часто сделанная самостоятельно руками продвинутых пользователей, которая предполагает работу с табличными данными через графический интерфейс. Для учетных систем характерна сложная модель данных: множество таблиц с взаимосвязями между ними в отношении 1:1, 1:N, M:N. Иногда такие системы еще называются Access-подобными из-за отсылки к старому-доброму продукту Microsoft Access, который выполнял одновременно и функцию базы данных, и среды разработки, и среды исполнения написанной программы для работы с данными. В мире разработчиков их называют «корпоративные CRUD-приложения». Учетные системы часто включают в себя бизнес-логику, которая представляет собой расчеты одних полей таблиц на основании других полей по определенной пользователем функции преобразования и валидацию вводимых значений. Несмотря на кажущуюся простоту, количество учетных систем в корпоративном ИТ-ландшафте на порядок превышает количество систем уровня подразделения или дивизиона. И так практически везде – вне зависимости от уровня зрелости компании, использования/неиспользования ERP системы и вида деятельности. Количество учетных систем, разнообразие предметных областей и ответственных за их поддержание сотрудников может стать настоящим блокером при миграции СУБД, если не найти адекватную технологию на отечественном рынке. Причем технология должна учитывать современные реалии – быть платформонезависимой, внесенной в реестр отечественного ПО и другие реестры, профильные для отрасли корпоративного заказчика. В общем, тот еще квест.
Выбор технологий
Решение о выборе технологии для данного кейса обусловлено профилем задачи и набором навыков разработчика. Профиль задачи достаточно хорошо раскрыт в предыдущем абзаце. Требуется быстро создать приложение с развесистой моделью и множеством однотипных экранов с табличными представлениями данных пользоваться, которыми будут исключительно сотрудники компании. Кто разработчик? Или разработчики? Очевидно, что для данной задачи нецелесообразно собирать целую команду из бэкенд и фронтенд разработчика. Слишком дорого для приложений данного класса. В идеале приложение должен создать один разработчик, который хорошо разбирается в бизнес-логике и структурах хранимых данных с минимальными требованиями к UI. Желательно, чтобы UI вообще генерировался как-нибудь сам. Следовательно, рассматривать будем фреймворки и платформы, которые ориентированы на бэкенд разработчика с поддержкой генерации фронта.
Топ популярных языков бэкенд разработки возглавляют Python, C# и Java. Каждый язык разработки имеет собственную экосистему фреймворков и инструментов для конкретных задач. Как выбрать нужный? Как обычно, гуглим платформы для создания бизнес-приложений на каждом из языков, смотрим топы выдачи и формируем шорт-лист. Исключаем проприетарные решения зарубежных вендоров и получаем следующий список:
Django – Python на пике популярности, доступные кадры, большая экосистема готовых компонентов;
.NET – в корпоративном мире имеет широкую применимость, доступные кадры, современный веб-фреймворк;
Jmix (бывшая CUBA Platform) – open-source платформа быстрой разработки веб-приложений на Java, основана на Spring Boot, включает инструменты разработчика и готовые компоненты.
Определяем общий набор критериев для сравнения:
Model-driven генерация UI на основе модели данных или структуры хранимых данных;
Возможность не прикасаться к JavaScript для создания типовых CRUD экранов;
Возможность кастомизации после генерации проекта в части модели данных, UI и ролевой модели;
Наличие туториалов, ориентированных на описанный бизнес-кейс;
Адаптация к существующей схеме (мапинг, реверсная генерация) СУБД;
Возможность использования нативных запросов БД.
Django
Официальный сайт гласит, что фреймворк создан для опытных веб-разработчиков, чтобы во многом не изобретать велосипед и при этом быстро подстраиваться под изменение требований к приложению. В качестве готовых деталей велосипеда фреймворк предлагает:
Настроенный веб-сервер;
Механизмы для авторизации пользователей;
Механизм шаблонов для создания собственных веб-страниц;
Административный интерфейс для управления контентом сервиса — наполнения, изменения, обновления используемых данных;
Система кэширования для увеличения скорости загрузки и открытия страниц через браузеры, внешние клиенты или приложения;
Интерфейсы и адаптеры для подключения к различным типам баз данных.
В рамках нашей задачи особый интерес представляет административный интерфейс Django Admin, который разработчик получает абсолютно бесплатно и автоматически.
А что с возможностью кастомизации интерфейса админки по умолчанию? Она существует, но в этом случае бэкенд-разработчику потребуется познакомиться с механизмами шаблонов Django и разобраться с тем, как переопределить стандартные.
В качестве инструментов для быстрого старта разработчику достаточно вооружиться консолью и текстовым редактором (автор предпочел для этой роли vscode). Все шаги по генерации проекта, приложения и миграций выполняются с помощью набора инструкций командной строки. Когда структура проекта готова, остается набросать схему объектной модели на привычном Python:
Стоит обратить внимание на то, что в Django в абсолют возведен принцип DRY: кроме приведенного выше кода потребовалось несколько несложных «подключений» модели в проект и генерация миграций для БД. Что самое приятное – фреймворк не предполагает генерацию каких-либо файлов с исходным кодом, в которые может возникнуть соблазн внести изменения.
Для создания чего-то большего, чем CRUD, понадобится создавать кастомные View и верстать их с помощью шаблонов. Если необходимо стартовать на основе существующей БД, то и на этот случай есть готовый туториал.
Во время рассмотрения Django, тем не менее, не покидало ощущение, что мы используем менее 5% потенциала, для которого фреймворк задуман: примерно в таком соотношении админка находится с кастомными функциями реальных сайтов, где применяется Django.
Из неочевидных плюсов стоит заметить, что использование Python открывает доступ к безграничному множеству современных библиотек для работы с ИИ, что в определенных сценариях может оказаться важным фактором.
.NET
Начнем с хорошей новости: теперь можно установить окружение для разработки без всего огромного и ныне недоступного для россиян дистрибутива Visual Studio, обходясь только open-source инструментами: dotnet-sdk и vscode с плагинами. Правда, будет не очень комфортно, если разработчики привыкли к высоким уровням интеграционных решений: визардам, настройкам в интерфейсе, продвинутой и умной помощи от инструментов. В том, что они появятся, большой уверенности нет, т.к. корпорация продолжает делать ставку на Visual Studio и свои коммерческие инструменты, так или иначе завязанные на собственные решения и платформу.
На выбор у разработчика .NET оказывается несколько вариантов реализации UI: MVC, Razor Pages и Blazor.
Первые два напоминают классические веб-приложения для других языков и платформ и, конечно, знакомы .NET-разработчикам. Однако, их использование может потребовать дополнительного подключения на проект специалистов по фронтенд-технологиям и синхронизации их с бэкенд-кодом. Это противоречит изначальной постановке задачи.
Архитектура Blazor предполагает, что весь код компонента пишется в одном файле с расширением .blazor. Тут нет необходимости использовать фронтенд-технологии. Весь код пишется прямо на языке C# в отдельной секции @code и связывается с HTML прямо тут же (при помощи возможностей шаблонизатора Razor). Такой подход может показаться более простым, т.к. не надо искать по коду требуемый слой приложения, и понравится программисту, если тот еще не боится держать логику и разметку в одних и тех же файлах. Нравиться она будет лишь пока будет написано относительно немного и несложно, одним и тем же сфокусированным только на этом проекте разработчиком. Кажется, это как раз наш случай. Экраны не обещают быть сложными.
Если ваше наследие уже было написано на C#, то программные интерфейсы актуальных версий технологий и подходы могут показаться знакомыми. Кроме того, разработчики Blazor активно экспериментируют с режимами доставки контента пользователю, предлагая в дополнение к обычному сервингу WebSockets/SignalR, WebAssembly, Server-Side Rendering, и все это сразу в «автоматическом режиме». Так что, если ваш проект имеет какие-то специальные требования к отрисовке и обновлению информации в браузере, для вас тут будет с чем поиграться.
Использование сторонних для платформы технологий (тех, что не упоминаются в официальной документации) может потребовать достаточно высокой квалификации и сноровки от разработчиков, т.к. официальная и неофициальная документация в основном ориентируется на коммерческие решения Microsoft. Например, хотите вы начать использовать PostgreSQL, идете в документацию по Entity Framework, а там про SQL Server; нагугливаете документацию по драйверу Npgsql, а там все под Visual Studio. И никаких таких «поменять драйвер и строку соединения в конфиге». Вместо этого: поставь пакеты, создай класс контекста и уникальным именем конфигурирующего метода объяви коллекцию с моделью.
В составе есть инструменты генерации реверс-инжиниринга СУБД и генерации кода по схемам, но они могут генерировать несколько неподходящий проекту код или вендор-зависимый код.
Поначалу его модели нагенерились прямо в корень проекта, а когда я указал каталог с моделями, он засунул туда еще и новый контекст (который обычно размещается в Data). Код, который использовал ранее созданные модели, перестал собираться, а некоторые инструменты начали ругаться на наличие двух контекстов в одном проекте. К счастью, возможности EntityFramework позволяют адаптировать приложение для работы в неродной для него схемой базы данных за счет использования аннотаций, указывающих альтернативные имена таблиц, колонок и т.п.
В общем, надо быть готовым, что вполне неплохо реализованные фичи соседствуют с посредственными (с точки зрения архитектуры или реализации) и понимать, что все там выглядит будто корпорация жаждет, чтобы вы сдались и прикупили их коммерческих решений (которые потащат за собой все остальное от той же фирмы – от процессора до браузера). В идеальной картине мира отправили бы всех сотрудников к ним на переобучение или хотя бы сильно пожалели о желании сэкономить/приверженности открытым стандартам, известным другим участникам рынка.
Любой шаг в сторону от дефолтов все также будет заведомо провальным. Несмотря на это требуется делать довольно много низкоуровневой работы, и это довольно странно. Тем не менее, архитектурный уровень технологических решений вполне позволяет осуществлять миграцию с СУБД со схемами данных и особенностями реализации, отличающимися от целевых в полуавтоматическом режиме, особенно если ранее использовалась та же платформа разработки, например, старые версии .NET.
Jmix
Jmix — это RAD платформа для разработчиков на Java от команды Хоулмонт. Предыдущее поколение платформы до обновления в 2021 году называлось CUBA Platform. Исходя из описания, представленного на сайте, платформа Jmix отвечает изначально поставленной задаче, так как ориентирована на быстрое создание разнообразных бизнес-приложений. Для работы с платформой требуется использование Jmix Studio — плагина к IntelliJ IDEA Community Edition, который дает специализированные инструменты для работы с open-source фреймворком Jmix.
Фреймворк Jmix построен на Spring Boot, Vaadin, JPA и других мейнстримных Java-технологиях. На уровне архитектуры фреймворка связка Spring Boot и Vaadin дает возможность разрабатывать веб-приложение без необходимости проектирования слоя коммуникаций между бэком и фронтом. Спорно, но ок. Разработка всего проекта ведется с использованием только Java или, опционально, Kotlin. Созданное приложение можно упаковать как в Docker-контейнерное jar-приложение, так и развернуть в виде war’ки на сервере приложений. Но скорее не заслуга Jmix, а Spring Boot внутри.
Важной особенностью Jmix Studio является то, что инструменты помогают не только с проектированием модели данных, но и с экспозицией их в UI пользователя: если добавили поле, можно одной кнопкой добавить его во все представления. Библиотека UI компонентов покрывает основные бизнес-кейсы. Из коробки также получаем готовую систему безопасности с декларативной настройкой ролевой модели. Есть готовые коннекторы к сервисам аутентификации и авторизации, включая интеграцию с AD/LDAP или внешними CAS-системами. В процессе работы с платформой удивился, как много мелких вещей предусмотрели разработчики. Это радует.
За счет функционала Jmix Studio вместе с фулл-стек Jmix фреймворком создание целого приложения становится доступным разработчикам без знаний во фронтенд-разработке. Веб-приложение имеет адаптивную верстку и PWA-режим. Проектирование веб-интерфейса осуществляется декларативно в файле с XML-разметкой и писать JavaScript или TS действительно не нужно. За логику на форме отвечает по классике контроллер, где разработчик так же пишет на Java. Инструменты Jmix Studio на всех этапах помогают правильно выполнить типовые сценарии. Например, если вы добавили компонент на форму, обработчик к нему поможет сгенерировать среда разработки по двойному клику на нужный экшн.
Есть возможность прикрутить готовые адд-оны из маркетплейса. В списке есть готовые стартеры для генератора отчетов, сервиса аудита, экспорта дата гридов в XLS и много чего еще.
Вроде все, что нужно, включено. Сценарий генерации модели и экранов CRUD приложений неплохо раскрыт в видео-туториале. В рамках туториала показан сценарий генерации веб-приложения на основе данных в СУБД Postgres с помощью инструментов Jmix Studio.
Отмечу, что Jmix хорошо работает с собственными источниками данных, но поддержка внешних API слаба и почти все нужно делать руками. Но это уже другой сценарий.
Подводим итоги
Начну с того, что все три технологии имеют мощный набор инструментов и рассматриваемый нами сценарий, возможно, для них даже слишком незначителен. По всем критериям оценки каждая технология предлагает свое решение. Да, они отличаются спецификой конкретной технологии, но важно, что они присутствуют.
Пожалуй единственное, что хочу отметить, как отличие среди всех рассматриваемых технологий, это крутая поддержка разработки в IDE, которая реализована в Jmix Studio на уровне IntelliJ IDEA Community Edition. С помощью инструментов разработчик получает не только сгенерированный по схеме базы данных проект, но может его быстро кастомизировать на уровне модели данных, системы безопасности и самое важное — UI. Понятно, что в конкретных кейсах в выборе подхода определяющим будет соответствие технологии набору компетенций разработчика, и всё-таки если это Java, то Jmix хорош.
Если рассматриваемый кейс показался вам знакомым и в профиле компетенций есть Java, то рекомендую посмотреть бесплатный курс по Jmix на Stepik и составить свое впечатление.
В комментариях напишите, что бы вы порекомендовали для решения поставленной задачи? Возможно, есть отрицательный опыт использования описанных технологий — это даже интереснее.
