Comments 61
Vaadin? Не то чтобы no-code, но концепцию "щас повесим на on-click бизнес-логику" позволяет реализовать замечательно. А так да... для того, чтобы это вот всё завелось, нужна рядышком ролевая модель и метаданные, какие поля в какой таблице что означают на бизнес-языке, и куда по какой связи ходить можно ... и при каких условиях... и кому... и где и как создавать новые записи. Была такая SugarCRM, которая этот концепт неплохо так развила
Vaadin мне больше нравится чем Wicket, но все же раньше уже делал выбор в сторону других GWT фреймворков, которые не навязывали свою модель. Задача то у меня проще чем ту что пытаются решать на Vaadin и Jmix... И REST API у меня уже автомагически есть из базы данных! Получается все серверные заморочки с фреймворками для этого прототипа лишние.
Vaadin давно уже не GWT фреймворк, он построен вполне себе на фронтэндовских технологиях. Пусть и не самых популярных - W3C Web Components, но это сильно проще и ближе к web чем GWT. Достаточно просто оборачивать сторонние UI компоненты и давать к ним API в Java.
Для MVP, если человек знает java/kotlin, я бы брал именно Vaadin. Ну и если нет фронтендеров, если есть, то лучше им делегировать.
А так я с вами согласен, время потраченное на решение недокументированной функциональности в различных low-code платформах сопастоваимо со временем разработки на нативной технолигии. Иногда в low-code вообще нельзя сделать то что надо, просто нет решения.
А почему решили на чистом JavaScript? Почему не связка React + UI Kit, например Ant Design или MUI?
Спасибо, за совет, но первый же нужный мне CRUD компонент из Vaadin сразу платный.
А так я с вами согласен, время потраченное на решение
недокументированной функциональности в различных low-code платформах
сопастоваимо со временем разработки на нативной технолигии. Иногда в
low-code вообще нельзя сделать то что надо, просто нет решения.
Согласен! Шаг влево, шаг вправо и иногда проще переписать самостоятельно заново, чем ждать фикса, фичи или выяснить что архитектура платформы принципиально не предназначена для этой задачи.
А почему решили на чистом JavaScript? Почему не связка React + UI Kit, например Ant Design или MUI?
Вы переоцениваете мой опыт во фронтэнде. Я же рассказывал о нем) Что может быть проще чистого JavaScript для быстрого старта, без настроек и изучения фреймворков. Я же не планирую тратить на это достаточно много времени, задача разовая. В следующий подход скорее всего будет LLama Code 1000.100 работающая в каждом телефоне и "выгнавшая на мороз" фулстеков.
Про сериализацию и передачу данных между фронтом и бэком можно было не думать, GWT делал магию, как и с биндингом моделей на компоненты.
Самое смешное, что Flex позволял примерно тоже самое. Ну то есть, можно было создать объектную модель на Java, и сгенерировать из нее модель на ActionScript. И нарисовать на MXML некий несложный (или сложный) UI, который мог из коробки практически работать с сервисами, экспортируемыми в виде EJB. И я правда нынче далек от фронтенда, но когда приходится к нему приближаться, то что я вижу, меня не вдохновляет. Потому что по ряду параметров не дотягивает до Flex.
Можно поинтересоваться, а почему вообще задача стоит именно так: сначала накидываем БД (надо полагать, SQL), потом — генерируем интерфейс? Почему нельзя наоборот — взять low-code/no-code платформу (например, SharePoint), создать БД в ней (автоматически получая интерфейс), а уже потом подключать к ней свой бэк через OM и делать всё необходимое?
Выбор, правда, невелик — кроме SharePoint на ум ничего и не приходит.
Данные обычно переживают приложение, фронт меняется а бэк матереет. В моем случае когда объемы данных от сотни мегабайт в прототипе до терабайт в целевом решении, то лучше сразу идти от модели данных.
В случае же с проприетарным SharePoint пространства для развития и возможностей не так много.
Как хранилище данных шарик ужасен. Поверьте, я работал с ним в этом режиме...
А я работая рядом с людьми, которые на нем почти сделали проект и из-за ошибки для которой не нашли обходного пути не могли завершить проект. Причем компания была золотым партнером MS и имела приоритеты в заявках
А какая ошибка? Расскажите
Это был 2007 год. Технических подробностей не помню, я не SharePoint разработчик. Но отлично запомнил вопли команды, нескончаемые митинги, эскалации рядом с моим рабочим местом меня сильно отвлекали от моей бессмысленной работы по мэпингу хранимок MSSQL в Hibernate ORM и это была воля заказчика...
Там всё заминировано, и наступить на мину не просто, а очень просто. Например, есть (был?) таймер 30 секунд, по окончании которого плагину (аналогу хранимки) настаёт секир-башка. Но, в отличие от хранимки, нет никакой транзакционности. Разумеется, всё это не документировано, и выяснять приходилось опытным путём. Выше изложена причина, по которой проект пришлось отменить у нас: выяснилось, что транзакционность изменений обеспечить не получается, а без неё — данные клиентов превращаются в страшное месиво.
(Как можно не уложиться в 30 секунд — если в API не предусмотрены пакетные изменения для какого-то сценария (UPDATE… WHERE), приходится гонять данные запись за записью, открывая каждый раз соединение, на железе недорогого хостера хватает десятков тысяч записей).
Мой вопрос был не конкретно про ШП, а про low-code/no-code в целом. Да и сам ШП мог улучшиться, десять лет прошло, как-никак.
Мда. Этот таймер — особенность даже не шарика, а раннего ASP.NET, и как его отменять давно известно. Решение когда-то гуглилось по запросу "ASP.NET long running request" и заключалось в вызове одного метода который отодвигает срабатывание таймера; сейчас его найти сложнее (исключительно из-за того что под ASP.NET сейчас понимается Core-версия без этой особенности).
Вот с пакетными операциями и транзакционностью всё и правда "весело".
Да и сам ШП мог улучшиться, десять лет прошло, как-никак.
Ну-ну :-)
Я, возможно, неудачно выразился. Дело было не в том, что мы не побороли какой-то таймер, а в том, что к этому моменту настало осознание, куда мы забрели. И было принято мужественное решение переписать всё на SQLCLR, работая непосредственно с таблицей AllUserData в SQL Server, оставив от SharePoint формы, типы, представления и т.п.
Что касается форм, типов и представлений (интерфейса и идеологии), они мне и сейчас нравятся. Сама идея универсальной мультиклиентной СУБД с GUI нравится больше, чем генерация GUI из SQL БД. Отсюда и взялся мой вопрос.
Вряд ли там дело было именно в ошибке, в конце концов ошибки либо исправляются, либо обходятся. Даже если это NRE в глубинах Шарика, всё равно можно понять условия его возникновения по трассировке стека и декомпилированному коду, в этом нет ничего сложного. Хотя если вместо программирования там пытались получить помощь от MS — ничего удивительного что ничего не получалось.
Хуже то, что EAV тормозит. Поначалу незаметно и к его лагам привыкаешь, но, по мере усложнения запросов, неустранимых тормозов становится всё больше и больше. Смотря на страницу, которая открывается 10 секунд, чувствуешь себя тем самым серийным программистом.
Ещё хуже если напарываешься на фундаментальные ограничения. Если нужно скомбинировать полнотекстовый поиск и обычную фильтрацию — ты проклят. Они делаются в двух разных базах, и единственный способ их скомбинировать — это сделать поиск по одной базе и передать список идентификаторов в другую. Скорее всего ещё и транзитом через фронт, потому что к беку в шарике хочется притрагиваться как можно меньше.
Помню тот день, когда впервые на проекте сумели вынести часть данных в отдельную БД. Это выглядело таким чудом: целых два гигабайта данных, а поиск по ним не тормозит!
Даже если это NRE в глубинах Шарика, всё равно можно понять условия его возникновения по трассировке стека и декомпилированному коду, в этом нет ничего сложного.
Вот я тоже так думал, когда мне понадобился калькулятор выражений (функции и операторы, поддерживаемые для вычисляемых полей), идентичный натуральному. (Надо было именно получать абсолютно такой же результат, что и ШП, имея формулу и список значений — чтобы напрямую можно было работать с БД, иначе ну никак не получалось обеспечить функционал, не говоря про такие мелочи, как скорость). Я залез внутрь, чтобы посмотреть, что можно вызвать, и оказалось, что эта функциональность вообще написана не на дотнете, вызовы на каком-то этапе уходили в классическую dll, а с ней разобраться уже не так просто.
Пришлось кропотливо, шаг за шагом, воспроизводить все эти функции (а их там немало), и каждую сопоставлять и покрывать тестами.
С остальным горячо согласен.
Верю, сам работал.
Vaadin...
Бесплатной версии хватает за уши
Плюс есть маркет виджетов
Я делаю админку на ней, чтоб не тратить время фронтов
Во! Ты мне бро! Держи в курсе! Давно об этом мечтал, чтобы у меня все было, а мне за это ничего не было!
я ожидал обнаружить революцию в сфере создания веб-интерфейсов
Так она и случилась. Только не в Java.
Если нужен веб-интерфейс к базе данных, то есть phpMyAdmin/phpPgAdmin и аналоги.
Если нужен API или веб-интерфейс для редактирования, в Yii есть кодогенерация CRUD по таблице из базы. В Symfony и Laravel тоже, хотя там есть свои особенности.
Практического применения для штук типа PostgREST я если честно не вижу, если только для своих проектов. Тут вся бизнес-логика будет на клиенте. Но мне кажется, аналог для собственного использования можно написать на любом языке за пару дней.
PostgREST написан на Хаскеле и работает так отлично, что мне не пришлось изучать Хаскель и править код проекта. В случае же с Yii, Symfony и Laravel мне прийдется изучать PHP.
phpMyAdmin/phpPgAdmin
Отличный вариант для внутренних технических пользователей, тех кто боится psql. И встречал такие советы на Reddit/Stackoverflow. В моем случае phpPgAdmin не дает преимуществ перед ручными INSERT из-за типов данных.
В случае же с Yii, Symfony и Laravel мне прийдется изучать PHP.
Конечно, только статья у вас в хабе "Программирование", а в тексте вы подразумеваете только Java. Я просто сказал, что в других языках с этим получше, и там сгенерировать веб-интерфейс из БД не представляет сложности.
Если превращать прототип в реальное приложение, то в любом случае придется делать нормальное API и править код проекта.
JavaScript/TypeScript мне было было бы достаточно и только на фронте(без NodeJS). Все серверные заморочки на данном этапе пока не интересуют, как и Java. Java тут лишь поскольку похожий опыт был на ней больше 10 лет назад.
А вот с PHP по опыту работ на масштабах начинаются свои сложности, так что вариант с Yii, Symfony и Laravel "на вырост" не предлагайте пожалуйста!
Вы не поняли, я не предлагаю это вам, я говорю, что ваше утверждение "Революции в сфере создания веб-интерфейсов не случилось, сгенерировать веб-интерфейс из БД сложно" неверно. Случилось и несложно.
Судя по описанию, у вас вообще какой-то крайне специфичный кейс, когда нужен веб-интерфейс, но не нужен сервер. У большинства другие цели, для которых прямой доступ к базе данных с клиента не подходит. Они пользуются инструментами, которые это обеспечивают, они есть для всех распространенных языков.
Есть такой проект Retool. Это конструктор приложений, позволяет подключаться к БД или Rest API и создавать UI. Есть много UI-компонентов. Подходит например для случаев когда менеджеры хотят сделать себе какой-то интерфейс, но не хотят отвлекать программистов от основных задач. Конечно платный.
У Оракла был/есть неплохой проект ADF. Это самой близкое приближение к почти автогенерации типичного круд интерфейса к БД. Изысков там нет, но типовые штуки неплохо получаются.
Майкрософтовский windows forms для .net и соответствующая поддержка этих классов (DataSet и Bindings) для asp.net, и все это работает из WYSIWYG редактора даже не стоит упоминания? Появилось как раз 10 лет назад, потом как я понимаю развитие в wpf, ну а сейчас немного сломано майкрософтом, но все еще поддерживается, в т.ч. в веб.
Ведь с появлением low code и no code платформ, а также активным развитием open source сообществ
Как вариант, предположу, что близко к такой функциональности по тематике статьи может быть в рассмотрении проект HiAsm — Конструктор программ по сумме идей и возможностей в нём реализованных?
Визуальные элементы интерфейса — это зачастую адаптированные компоненты из Delphi|FreePascal на одном рабочем поле с "бизнес" компонентами составляющих логику
работы схемы при взаимодействии с пользователем.
P.S. Правда сам автор проекта, возможно к нему охладел как неокупаемый свои
трудозатраты на него, но форум и сообщество ещё живо, но нет активно как ранее.
Так это же про схемы? Я успешно работал с drawio, который развивается и поддерживает разные виды диаграм, море интеграций итп. Но моя задача, что описал в статье - иная
Там не только основная своя концепция визуального программирования, но и возможность программно, в разных вариантах при поддержке в пакетах требуемого языка программирования расширять функционал возможных решений.
К, примеру, С# уже отдельным разработчиком поддержан в рамках следования общим
идеям заложенных в авторский проект.
P.S. "Сложно" даже представить как на Бейсике делались самопальные системы заводского бухгалтерского учёта на переломе 80-х годов на 386-х DOS компьютерах в основных аспектах понимания реляционных баз c разбивкой их данных на таблицы и визуального отображения и ввода данных в табличные формы при их контроле. :)
Структура взаимосвязи таблиц и полей в них описывалась отдельно и при выводе
данных система автоматически их форматировала по размерам ячейки.
Спасибо, необычный проект! Судя по репозитарию он не развивается с 2016 года. А web IDE c 2017. Концептуально напомнило мне Delphi.
Да, интересный, но по нему даже сообщество не сделало публичных статей например на Хабр, что тоже, думаю, не добавило популярности, востребованности и узнаваемости этого проекта при достаточности документации и снятых видео роликов по нему.
P.S. Репозитрий на Github это авторский заход на переписываниe HiAsm на Си также
как и на JavaScript для компонентов Web. т.к. базовые Паскаль исходники он публично не размещал начиная с какой то версии ~20 лет давности.
… Сам сайт и форум проекта, по озвученной информации сделан на самом же HiAsm.
Посмотрите в сторону BPM систем. Они в основном за деньги, но есть и опен сорс
Там правда паровозом идет и построение решения на их принципах, но это иногла неплохо и даже хорошо
Почитайте "Все что вы хотели узнать о BPM, но боялись спросить", я разделяю мнение с @sshikov Как здорово что все мы здесь сегодня собрались!
Попробую вкратце. Из моего опыта почти все проекты были не слишком удачными. Т.е. задача решена, но дороговато и требует поддержки большого и редкого скиллсета в команде
Причины:
Часто начинают не с оптимизации процессов, а с давайте автоматизируем то, что сейчас (doing shit faster). Уже тут можно лавочку закрывать, но на другой технологии бвло бы тоже самое
Часто заказчик просит добавить очень важные фичи которые требуют кастомного кода в большом количестве, хотя фича больше похожа на изобретение своего велосипеда с многоугольными колесами
Часто команда внедрения не ищет путь через штатный функционал, а вот мы ща тут накодим ....
В целом, добавляя или нет BPM в стек,я принимаю решение на основании того, могу ли я собрать паззлик так, чтобы остаться в штатном функционале системы. Если не выходит, не беру либо аккуратно саботирую
НО это просто инструмент, я ж не агитирую
Прочитав статью я не понял суть проблемы, стоявшей перед автором. Поэтому мой комментарий может быть нерелевантным.
В общем случае, объектная модель, реализованная на back-end не может быть без изменений перенесена на front-end. Для последнего всегда создаются какие-нибудь views. Исключение - это всякие специфичные CRUD-интерфейсы, вероятно у автора что-то такое?
Писать на GWT и ему подобном может казаться быстрым, пока не случится какая-нибудь непонятная проблема (например баг в реализации, баг в браузере, недокументированное поведение компонента и пр.). На поиск проблемы может уйти всё сэкономленное время, а решение и вовсе может не найтись. Всё же лучше использовать отдельные инструменты для back- и front-end.
Задача - создать несколько CRUD для существующей БД. В основном это гриды с сортировкой, страничками и формы для создания новых записей в эти таблички. Есть пара нетипичных моментов связанных с виджетом для выбора значений(уже набросал работающий черновик в стиле дельфишко-кода).
В общем случае, объектная модель, реализованная на back-end не может быть без изменений перенесена на front-end.
В общем случае да, но тут как и в Naked Objects я контролирую БД и могу немного подрихтовать схему чтобы просто проверить идеи прототипа.
Мне некогда городить слой DTO/VO на сервере, делать все идеологически правильно на Redux со стейтом. Не та история, несколько экспериментов, большая часть просто проверить идею и выбросить код после для неудачных.
GWT я и не собираюсь воскрешать, я его привел в пример уровня сложности виджетов и возможностей для энтерпрайз систем. Как "протекают" абстракции я много раз в своем опыте видел, в том числе и в google web toolkit.
Так что пока чистый JavaScript оказался быстрее... Хотя казалось бы столько людей сталкиваются с похожими задачами создания CRUD по схеме базы данных и уже столько времени прошло с эпохи GWT.
Так есть же генераторы DTO классов. Все ими и генерируют.
Есть и мэперы между доменными объектами и DTO... Был у меня был опыт работы в проекте, где большая часть кода была по перекладывания из/в protobuf, а не бизнес логика. Рядом был их собственный аналог gRPC. Знаю эту лишнюю сложность и не хочу ее на этом этапе. Код ради кода в моем случае не нужен, напомню про PostgREST. Максимум вьюшку или хранимку создать.
Вот такой еще велосипед есть https://platformerp.ru
правда для MySQL, а не PostgreSQL .
CRUD, фильтрация, сортировка, добавление, удаление, простые формочки из коробки.
После похожих терзаний написал свою платформу data driven среды разработки.
Начал в 2017, спустя 6 лет платформа вышла на плато надежной среды с необходимым функционалом backend и набором контролов frontend.
Сейчас создаю ндежные веб-приложения, допольно сложные с т.з. архитектуры.
Вывод - иногда легких путей нет.
Начинал подобное еще в эпоху GWT для ускорения своей работы и успешно забросил, уйдя в бэкэнд/бигдату.
Расскажите про свой опыт, интересно. Может публикацию сделаете и сравните с альтернативами из Open Source?
Думаю, часть решений может быть интересны.
Все собираюсь поделиться, но не знаю с чего начать. За 30 лет в IT никогда не писал. :)
Может посоветуете, с чего начать?
Вы же автор, не мне вам советовать)
Я бы составил такой примерный план:
Какие задачи может решать ваш фреймворк. Как упрощает разработку. Какие ограничения и область применимости к моделям данных, объемам, типам данных.
Сравнения с подобными OpenSource/low code решениями. Как лучше всего "продать" программисту, какие его проблемы легко решает, а где может создать новую проблему(абстракция же где-то "протекает")
Что является входными данными и как описывать метаданные для кастомизации процесса генерацию списков/форм. Есть ли подгрузка сущностей связанных по ключу, поиск из больших объемов данных, динамические визуальные фильтры.
Какие компоненты доступны в UI и их биндинг с серверной частью (протоколы, сериализация, возможность подключать endpoint).
Как вызывается бизнес логика фреймворком?
Возможности визуализации и отчетности.
Диаграмма развертывания, аудит доступа, технические логи, репортинг ошибок фреймворка(что отлавливается во время компиляции/загрузки, а что во время исполнения), отладка и тестирование решения
Планы развития фреймворка, поддержки новых форматов данных, технологий и т.п.
Ну и демо, в духе SmartClient здорово бы систематизовало все ваши наработки
Есть еще такое...
https://odajs.org/
Спасибо! Судя по коммитам, вы один из соавторов вместе с Ильей. Глянул пару видео, посмотрел что проект не обновляется с прошлой осени.
Можете рассказать в двух словах как его применить на существующую схему в PostgreSQL или REST сервис.
Из статьи так и не понял, а чем же не устроил для описанной задачи Jmix? В версии 2.0 и крайнюю версию 24 Vaadin прикрутили.
Платностью Dev Studio, без которой он превращается "в тыкву".
Сгенерировать web интерфейс из БД или объектной модели не стало проще даже 10 лет спустя