Comments 13
Самое смешное что веб начинался (да и сейчас из-за СЕО вынуждены) именно как server driven ui, когда весь UI генерируется сервером в xml-подобный структурированный формат, но затем пришли те кому нужны рюшечки, потом пришли 100500 несовместимых друг с другом браузеров и все стало сложно.
p.s. кстати десятилетия назад видел UI полностью на базе oracle (это их собственная разработка), все описание в базе данных, все генерируется на лету на клиенте и в вебе, и все тормозит адски/
Самое грустное, что именно сейчас, когда рынок браузеров захвачен буквально одной компанией (а конкурент куплен и 'контролируется до смерти'), реально создать действительно удобный стандарт для UI в вебе (а заним и десктопы через electron подтянутся)... но нет мы лучше сделает 1500 (не шучу, есть такие примеры с примитивным интерфейсом) пакетов суммарным объемом в сотни мегабайт кода на js и на столько сложными кросзависимостями версий, что поддерживать это уже никто не может.
А это не очень тяжело поддерживаемая система?
SDUI можно представить как НАДСТРОЙКУ над нативным кодом или вашей обычной реализацией.
Со тороны бэка:
появляется некий 'переводчик' Со стороны фронта на примере реализации UI-компонента:
условно сначала пишеться нативный код компонента
далее эта реализация дорабатывается до соответствия технологии SDUI(условно - следование некому протоколу)
Из этого пояснения кажеться, что мы видим наоборот удорожание разработки :) Но нет.
С технологией SDUI разрабатывается общий механизм конструирования экранной формы.
То есть уменьшаем время на разработку и сводим на нет возможность ошибок.
С формированной на 100% компонентной базой нужно только писать json инструкции.
А кто может писать эти json инструкции? Правильно - не какой то очень специализированный специалист, а условно любой.
То есть снижаем потребность в большом количестве высококвалифицированных специалистов(условно нам достаточно иметь junior+, middle разработчиков).
Для чего это нужно ?
Ответ 'банальный' - удешевить и сделать более качественной разработку.
Мне кажется эту систему со временем будет очень тяжело поддерживать и что то оттуда выпиливать.
Поддерживать любую мало мальски большую кодовую базу на любом языке программирования с таким уклоном .. тяжело :)
Но .. повторю тезис из статьи про релизы мобильных приложений.
Выпустить новую фичу или срочное исправление бага ооочень долго по времени через стандартные механизмы магазинов распространения. Гораздо проще и быстрее написать одну инструкцию и получить ежесекундное обновление в приложении.
А с учётом того что SDUI инструкции(логика) принимаются на любой платформе и она 'одна' мы получим появления обновления сразу на всех фронтах вашего проекта
То есть c технологией SDUI пишем логику в единственном экземпляре, а она применяется для всех фронт приложений проекта.
Спасибо за статью, было интересно узнать как именно формируются и делаются эти отстойные перегруженные всратые интерфейсы современных банковских приложений.
В Авито вроде бы также делали.
Фактически переизобретаете браузер
'К сожалению' то что разрабатывают отдельные организации является их интелектуальной собственностью и они вправе решать что сней делать - делать ли своё решение открытым или нет.
Есть к примеру хорошее решение от Яндекса: https://divkit.tech/ru/
Кстати если кому-то интересно можете его использовать.
Мы его рассматривали, но для нас оно слишком громоздкое, неподходящий стек и 'сложность' внесения правок под наши 'пожелания'.
Никакого простора для разработчика
Почему?
В комментарии выше писал, что SDUI это нативное(!) кроссплатформенное решение, простыми словами Надстройка над нативной реализацией.
То есть разработчик делает ровно то что и делал раньше, но .. с применением SDUI он теперь проявляет командный подход, помогает заказчику удешевить разработку, сделать доставку изменений до клиентов максимально быстрой, ..
Используем похожую архитектуру, где на бэкэнде в реалиционной базе хранится список контролов, которые можно размещать на странице.
Для каждого контрола заведена таблица со списком колонок как пропертя для контрола.
Но и в итоге получается, что каждая страница это иерархический набор контролов из базы со своими пропертями.
Соответственно, каждая страница выглядит как древовидная структура, которая может быть разбита на горизонтальные и вертикальные сегменты, и в каждом сегменте, как иерархическое вложение, размещаются UI-контролы.
При хранении страниц в базе данных, хранение сотен страниц и быстрая выборка страницы с его UI-контролами и пропертиями для каждого контрола выполняется шустро за счет использования реалиционной базы.
Также за счет ссылочной целостности исключаются ситуации битых страниц, когда при добавлении свойств на UI Control или при добавлении контролов на страницу, в теории страница может сломаться. Нет, такое не происходит как раз из-за применения Referential Integrity и Constraints.
В нашем случае на FrontEnd отсылается XML с конфигурацией страницы и данные для компонентов страницы.
Например, если простой Grid и форма, то первым формируется конфигурация, в которой Grid с вложенными колонками и форма с вложенными полями. Второй отсылается данные для Grid, согласно настроек Grid, из какого Data Source и с какими параметрами данные должны подгружаться. И третье, после загрузки Grid выбирается запись и по выбранной записи подгружаются данные для формы.
Из приятностей, как отмечено выше, сотни страниц в репозитории не проблема. Переиспользование страниц также не проблема, так как каждая страница самодостаточна и автономна.
И последнее: уровень сложности страниц также не проблема, так как каждый контролл отвечает за себя и дочерние вложенные компоненты контролла.
Как например, Grid отвечает за собственно, Grid, колонки, фильтр для колонок, футеры колонок, источник подгрузки данных, источник сохранения состояния и т.д.
В 2019 Крис Маккорд анонсировал на ElixirConfEU LiveView. На рельсах с тех пор сделали HotWire. В PHP — тоже что-то похожее повторили (лень искать).
Шесть лет назад (!) появилась технология эффективного рендера на бэкенде. Но вы предлагаете гонять туда-сюда вместо дельт — джейсон. Чем это лучше генератора каких-нибудь реактивных виджетов?
LiveView - это для web-разработки(получение HTML-страницы). Упор же этой статьи делается на разработку мобильных приложений. Ну а когда у вас условно 2(ios+android) мобильных приложения работают на единой логике с бэком возникает логичный вопрос - почему бы и web не перевести на единые 'рельсы'?
Ну ок, вот есть flutter и rfw — они чем не угодили?
Для новых, небольших(и средних) проектов можно рассматривать эти технологии(flutter и rfw), но для крупных (новых и уже реализованном на 'нативном' стеке) проектов, для крупных компаний, где не нужно экономить я бы не рекомендовал их использовать.
Минусы, которые не позволяют нам использовать их(flutter и rfw):
1.
Фреймворк Flutter достаточно молодой.
4 декабря 2018 года на конференции Flutter в Лондоне была выпущена версия кроссплатформенного фреймворка Flutter 1.0
Что накладывает риски в найме специалистов со знаниями Flutter(Dart) и в наличие достаточной документации по нему.
2.
Open-source проект Google, риск запрета на использование или ввода неких ограничений
Flutter — open-source проект (лицензия BSD), что формально делает его независимым от политики Google.
Dart (язык Flutter) — также open-source, разработку можно продолжать даже без поддержки Google.
Прямого запрета на использование Flutter пока нет, но риски есть, особенно если учесть сложную геополитическую ситуацию.
Также ничто не мешает компании Google сделать из open-source проектов Flutter и Dart коммерческие проекты.
Flutter - это глубоко интегрированное решение, если будет запрет на его использование, то это приведёт к необходимости переписывания 'с нуля'.
Основной риск - обновления Flutter SDK, если GitHub/Dart-репозитории станут недоступны.
3.
Объёмы наших текущих проектов мобильных приложений 200 000 - 300 000 строчек кода.
Нет автоматизированных средств конвертации кода из нативного(iOS/Kotlin) представления во Flutter проект.
Нельзя напрямую конвертировать существующие iOS/Android-проекты в Flutter.
Что бы просто переписать текущие проекты на Flutter требуются значительные трудозатраты.
4.
Server Driven UI (SDUI) - это нативное(!) кроссплатформенное решение.
Нативное решение - это sdk от 'производителя'(н.р. Apple/Google) предназначенное для разработки приложений под конкретную платформу.
Flutter - не нативный UX(н.р. для iOS), ограниченный доступ к некоторым специфичным АПИ, больший размер приложения по сравнению с нативными, производительность ниже, если нужна поддержка новой фичи iOS/Android придётся ждать пока Google не добавит её во Flutter.
Чем полезен Server Driven UI