Как стать автором
Обновить

Сгенерировать web интерфейс из БД или объектной модели не стало проще даже 10 лет спустя

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров8.8K

Помню, как более 10 лет назад, я бился с тем, как быстро создать интерфейс для ввода данных в базу данных и отображения их через браузер. На то время, еще был популярен Google Web Toolkit и было несколько открытых библиотек виджетов к нему, по функционалу догоняющие и иногда превосходящие десктопные Swing компоненты. Сейчас на меня юные фронтэндеры посмотрят как на динозавра, как можно писать фронтэнд на Java и тем более как до такого тогда докатился Google, который перевел позже Android разработчиков на Kotlin, а GWT отдала сообществу на поддержку. Всему виной были тяжбы с Oracle за Java API на мобилках и из-за копипасты с Apache Harmony.

На тот момент казалось что еще чуть-чуть и приблизится сингулярность для веб фронтэнда "кровавого энтерпрайза"

Могу выделить проект SmartGWT (фактически это GWT обертка для smartclient javascript библиотеки) и Sencha GXT, полностью написанный на GWT. Тогда обе библиотеки были доступны без оплаты(за исключением их более навороченных корпоративных версий). Были же времена, ээх! Археология она такая...

Про сериализацию и передачу данных между фронтом и бэком можно было не думать, GWT делал магию, как и с биндингом моделей на компоненты.

На рабочем проекте мы с коллегами сделали админку на SmartGWT, а на работе в издательстве "За Рулем" и позже в авиакомпании я использовал GXT. Достаточно сложные интерфейсы разрабатывались и тестировались на одном языке. К слову первые версии IDE Eclipse Che тоже были на основе GWT, а это почти как IntelliJ Idea в браузере!

По возвращении к этой задаче, я ожидал обнаружить революцию в сфере создания веб-интерфейсов. Ведь с появлением low code и no code платформ, а также активным развитием open source сообществ, популярностью JavaScript на github, казалось, что задача генерации интерфейса из БД или объектной модели станет гораздо проще. Однако, реальность оказалась несколько иной. На бэкэнде, базах данных и в big data ситуация гораздо лучше с возможностями бесплатных и открытых проектов, когда не надо покупать лицензии или платить за дополнительные компоненты, можно без СМС и платных подписок запустить хоть Ingenuity на Марс.

Наиболее примечательным оказалось отсутствие open source решений, которое бы предоставляло мне всю необходимую гибкость и контроль. Большинство существующих инструментов предоставляли готовые шаблоны и компоненты для создания интерфейса, но в случае отступления от Hello World сценария, виден недостаток возможностей для расширения или функционала который был из коробки в GXT.

Когда просто проверяешь свою идею, то самое важное - это скорость изменений и простота реализации функционала. Не надо следовать лучшим практикам разработки, не стоит думать как интефейс будет выглядеть на старых айфонах и будет ли работать в IE с используемым polyfill'ом.

В плане прототипирования идеи, мне импонирует подход Naked objects, когда весь интерфейс - это просто отображение доменной модели. Реализовать просто, выглядит убого но зато быстро и дешево! Apache Causeway, вышел из апачевского инкубатора в Isis, его ребрендировали и он дожил до наших дней, обновляется и появляются новые фичи. Но, я честно, не готов возвращаться в эпоху Java Server Faces с их фреймворком Apache Wicket!

На какие проекты я смотрел:

https://github.com/ToolJet/ToolJet

https://github.com/directus/directus

https://github.com/marmelab/react-admin

https://github.com/jmix-framework/jmix

ToolJet - подкупил «зведностью» и тем что я когда-то на него смотрел с интересом. В итоге на моей небольшой базе данных PostgreSQL в сотню мегабайт все тормозило до перезагрузки контейнера. Поигравшись понял что надо что-то менять и залазить "под капот" после чтения документации, к тому же не завелись мои hstore и массивы из БД.

Directus создал в моейсхеме пару десятков своих таблиц directus_* и работал получше ToolJet, но при ошибке с таблицей без ключей, с помощью него я ее нечаянно дропнул через интерфейс. Та же история с не поддерживаемыми типами данных и неявные ошибки.

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

Jmix это ребрендированная Cuba платформа, мне понравилось как они переписали виджеты на React, что достаточно функциональный UI. И для прототипов энтерпрайз приложений на проекте когда-нибудь работодатель купит лицензию или я успею разобраться в 28 триальных дня лицензии на Jmix Studio IDE, но не в этот раз!

Остались на проверку:

https://github.com/Budibase/budibase

https://github.com/appsmithorg/appsmith

https://github.com/openblocks-dev/openblocks

Еще мысли вслух про JSON Forms. Видел этот подход раньше с XSD Schema и каждая компания переизобретала свой генератор форм. Казалось бы теперь все отлично. А вот я не совсем уверен...

Впечатления, что "Nо trials, nо fees, nо taxes Nо card needed fоr the premium access" это не про разработку фронтэнда и я начал подозревать почему пьют смузи фронтэндеры.

Пока что оказывается наоборот...
Пока что оказывается наоборот...

В итоге, не выдержал и начал %овнокодить на чистом JavaScript. Признаться, я все забыл что даже умел раньше, но все равно иду к своей цели быстрее, чем пытаясь разобраться в очередной платформе и понять что нужно там подшаманить, чтобы появилась нужная мне форма, табличка, график и т. п. И дело пошло! У меня нет проблем с REST API к моей базе благодаря PostgREST(кому-то удобнее Hasura), то время что я трачу на JavaScript и то чтобы разобраться с виджетами, просто рассматриваю как инвестицию в будущее, хотя возможно Copilot будет удовлетворительно CRUDошлепить гораздо раньше этого!

Теги:
Хабы:
Всего голосов 14: ↑13 и ↓1+16
Комментарии61

Публикации

Ближайшие события