Технологии, лежащие в основе решений без кода и с малым кодом, и способы создания собственных

Платформы No/Low-code в последнее время стали модной темой. Но почти нет информации о том, что нужно для создания собственного решения такого рода. Поэтому мы сосредоточимся на подходах к разработке, архитектуре low-code и no-code платформ и декомпозиции. Давайте узнаем, как создаются платформы без кода.

Для начала мы определим разработку с низким/отсутствием кода. Этот термин обозначает платформу, на которой пользователь может создавать любой ИТ-продукт для внешнего использования через интерфейс пользовательского интерфейса. Это могут быть отдельные веб-страницы, полноценные веб-сайты, мобильное приложение, PWA или конструктор чата. По данным Statista, прогнозируется, что мировой рынок платформ с низким кодом достигнет 65 миллиардов долларов. долларов США в 2027 году. Таким образом, все вышеперечисленные ИТ-продукты имеют перспективы развития.

Высокий спрос на бизнес-приложения вызывает потребность в разработке новых платформ с минимальным кодом и без него. В большинстве случаев любая платформа без кода состоит из:

• Часть пользовательского интерфейса — визуальный интерфейс с компонентами, объектами перетаскивания и формами. Это позволяет пользователям создавать интерфейсы для своих продуктов. Пользовательский интерфейс должен быть интуитивно понятным и простым в использовании широким кругом людей без технического образования. UI/UX-дизайнеры часто прикладывают много усилий на этом этапе.

• Пользовательский интерфейс в преобразователь кода — эта часть часто выглядит как какая-то магия, поскольку код приложения генерируется из визуального интерфейса и его компонентов.

• Бизнес-логика — реализация компонентов, поддерживающих функциональность интерфейса на серверной части (регистрация, выставление счетов и т. д.).

• Автоматические компоновщики кода — необязательная часть, которая позволяет автоматизировать упаковку кода в приложение или веб-сайт и развертывание его в рабочей среде.

Приведенные выше наблюдения позволяют предположить, что основная трудность может возникнуть во второй части системы (UI в преобразователе кода), однако на каждом этапе необходимо исследовать тонкости. Разработку всех компонентов мы будем рассматривать исходя из кейса создания сайтов, отмечая специфические моменты для конструкторов чатов и конструкторов мобильных приложений как наиболее распространенные кейсы.

Что в первую очередь видит конечный пользователь, приступая к разработке продукта? Это интерфейс пользовательского интерфейса, связанный с конструктором. Поэтому здесь важен профессиональный подход и анализ интерфейса — многие не понимают, почему этот этап занимает много времени. Это связано просто с улучшением интерфейса редактора, который влияет на простоту использования. Простота использования означает, что на создание программного продукта будет затрачено меньше усилий, что упростит процесс для конечного пользователя.

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

Технологии, лежащие в основе платформ без кода и с малым кодом

Подходы к построению архитектуры внутреннего редактора могут различаться, влияя на функциональность платформы.

В настоящее время существует три основных подхода к построению внутренней архитектуры:

1. Редактор -> код + метаинформация -> код

1. Редактор -> JSON -> код

1. Редактор -> промежуточные компоненты -> код

Давайте подробнее рассмотрим каждый из этих подходов и выясним соответствующие варианты использования.

Редактор -> Код + Метаинформация -> Код

Этот подход генерирует результирующий код на ходу и позволяет пользователям выбирать и настраивать определенные элементы с помощью визуального редактора. По мере выполнения настройки определенного элемента он автоматически изменяет кодовую базу, чтобы поддерживать ее в актуальном состоянии с учетом изменений. В подавляющем большинстве случаев этот подход используется именно как основа для редактирования веб-страниц: код становится HTML-страницей с ее визуализацией. Поскольку все редактирование выполняется на стороне браузера, окончательный код легко экспортировать как продукт, скопировав структуру DOM через браузер.

К тонкостям первого подхода можно отнести следующие моменты:

• Необходимость работы не со всей HTML-разметкой, а только с компонентами. Любой, кто когда-либо видел HTML-разметку сложной страницы, может понять, что она может создавать проблемы. Если разрешить пользователю редактировать каждый тег, то интерфейс превратится в кашу и станет непригодным. Было бы проще построить страницу с нуля, чем применять такой конструктор. Поэтому возникает необходимость в дополнительной разметке, так называемых метаданных. Информация для редактора добавляется в виде настраиваемых атрибутов HTML-тегов. Данные указывают на то, что внутренний блок может быть отредактирован или перенесен, а параметры и атрибуты легко изменены.

• Положение элементов или блоков — абсолютное, относительное, статичное, фиксированное и липкое — может быть сложным. В чем причина этого? С этим пунктом все сложнее и не лежит на поверхности, так как положение каждого элемента напрямую влияет на положение других UI-блоков на всей странице. Это сравнимо со стаканом, в который насыпаны разные шарики. Если вы попытаетесь поставить деревянный брусок в середину стекла, все шарики изменят свое положение, поскольку они будут выдавлены из своего положения. Можно провести аналогию между описанной ситуацией и расположением элементов на странице. А вот с параметрами, связанными с расположением блоков, ситуация немного сложнее. От указанного параметра зависит выравнивание блоков и законы «сжимания».

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

• Стили в CSS (каскадные таблицы стилей) не будут работать так, как ожидал пользователь. Причина кроется в наследовании: стили, установленные для родительских компонентов, будут напрямую влиять на дочерние, это будет сбивать с толку конечного пользователя и будет выглядеть как явный недостаток или баг UI. И, в свою очередь, уменьшится UX платформы и ее использование. К счастью, это можно решить с помощью уникальных классов CSS или встроенных стилей, хотя конечный пользователь все равно столкнется с проблемой побочных эффектов.

• Невозможно импортировать код. Помимо прямой HTML-разметки (как пример в нашем случае), редактор требует добавления в разметку пользовательских атрибутов в качестве шаблона, отвечающего за функциональность редактора.

В силу отмеченных моментов подход по схеме Редактор -> код + метаинформация -> код часто используется не в no-code, а в low-code платформах, конечные пользователи которых понимают технические характеристики и сторонние последствия модификаций. Целевая аудитория платформ с низким кодом сужается до разработчиков, которые знают о подобных или более эффективных инструментах.

Редактор -> JSON -> Код

Для устранения недостатков первого подхода и расширения списка поддерживаемых платформ, не ограничиваясь HTML или кодом, который может отображаться как компоненты UI, можно рассмотреть архитектуру редактора на основе промежуточной модели данных (Editor -> JSON -> код).

В качестве промежуточного формата данных JSON может быть заменен любым другим форматом. Хотя и дает некоторые преимущества, о которых подробнее будет сказано ниже.

Редактор использует промежуточную модель данных, поэтому у него не будет ограничений на UI-часть, и может быть реализован полноценный функционал перетаскивания различных UI-компонентов. Основная задача UI-части редактора — максимально точно преобразовать UI в промежуточную модель данных.

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

Тем не менее, вот некоторые пункты, которые следует отметить:

• Этот подход применяется к интерфейсу пользовательского интерфейса и вариантам использования, в которых должна быть описана логика. В этих случаях использования создается поток редактора, который позже формирует основу приложения. Таким образом, мы можем составить логику не только приложений с пользовательским интерфейсом, но и конструкторов чат-ботов или платформ автоматизации.

• https://youtu.be/F8S6mFFirmA

• Существует три подхода к компиляции:

1. Если нужно построить логический поток. Например, в качестве построителей чатов разрабатывается протокол обмена между логическими узлами. А при выполнении логики по структуре потока из JSON логические узлы запускаются в порядке по умолчанию. Логические узлы изолированы и выполнение логики в них не вызывает сторонних эффектов в виде состояния этих узлов, поэтому данная система достаточно просто устроена и надежно работает. Поточное программирование отличается от других парадигм и концепций, включая объектно-ориентированное программирование.

1. При таком подходе к UI части применяются шаблоны конкретных блоков с возможностью вставки дочерних компонентов из аналогичных шаблонов.

1. Третий редко используемый подход похож на синтаксические анализаторы SAX (Simple API for XML). Он сравним с предыдущим, но проще учитывать контекст генерации кода. Он сложный, но гибкий.

• Этот подход ближе к водопаду в разработке, так как перед началом разработки необходимо заранее проанализировать и описать все возможные атрибуты тех UI-блоков, которые будут использоваться. Это ограничение можно обойти, если использовать аналогичный подход с метаинформацией, в которой хранятся нестандартные данные или атрибуты.

Как мы уже упоминали, JSON не требуется, хотя JSON и XML удобны тем, что могут выполнять сериализацию или десериализацию UI-кода вне зависимости от технологии, для которой генерируется окончательный код. Более того, есть возможность динамически создавать интерфейсы на лету и, возможно, экономить трафик, так как, например, JSON гораздо экономичнее той же HTML-верстки со стилями.

В этом случае также возможен импорт внешнего кода, но для этого требуется введение дополнительного формата экспорта. Такая уникальность каждой платформы не так удобна, но расширяет аудиторию и способствует популярности платформ.

Этот подход является наиболее оптимальным для реализации логического потока на стороне сервера, поскольку уже был описан в подходах к компиляции. Правильно спроектированная серверная часть всегда должна быть без состояния, и именно это облегчает нам реализацию бизнес-логики в виде последовательности независимых узлов. И это не что-то уникальное, потому что, как и в парадигме разработки Flow, концептуально схожие подходы используются в RX и бэкэнд-фреймворках, таких как express/koa и так далее.

Редактор -> Промежуточные компоненты -> Код

Третий подход к реализации архитектуры (Редактор -> промежуточные компоненты -> код), на первый взгляд, мало чем отличается от предыдущего. Также есть UI-блоки или компоненты, а также есть код, отвечающий за их расположение на экране. Однако существенное отличие состоит в том, что код, отвечающий за эти компоненты, не генерируется, а является частью библиотеки, которая подключается к приложению и работает как внешний подключаемый ресурс программы.

Конструктор собирает UI продукта из заранее подготовленных компонентов собственной библиотеки (библиотеки данного сервиса). Поэтому эта часть сложнейшей логики, а именно компиляция в код, практически игнорируется. Такое решение намного проще — нужно просто создать библиотеку компонентов, которые можно использовать для указанной целевой технологии, и создать редактор, работающий с примитивами (компонентами). Тем не менее, это приводит к огромному количеству дополнительных тонкостей, и выбор того, какой из подходов будет лучше, должен опираться на требования бизнеса.

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

Можно отметить следующие особенности этого подхода:

• Сложнее всего будет импортировать внешний код , поскольку вам необходимо указать общий формат компонента, который охватывает максимальную функциональность.

• Более новые (более расширенные) версии библиотек компонентов реального времени могут не поддерживать старые, что может привести к проблемам с поддержкой.

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

• Более высокая надежность

• Небольшое/большое снижение производительности (зависит от целевой платформы и качества кода библиотеки компонентов в реальном времени). Компоненты не компилируются, а работают в реальном времени, как библиотека-обертка для нативных, с помощью подключаемых библиотек.

Например, FlutterFlow использует этот подход.

Мы исследовали три основных подхода к реализации основной части большинства платформ без кода и с низким кодом. Это поможет вам в выборе правильного направления развития.

Что нужно для создания собственной платформы без кода / с малым кодом

Также стоит учесть пару дополнительных моментов, которые могут сыграть решающую роль в развитии именно вашего продукта.

Во-первых, импорт внешнего кода, шаблонов или фрагментов может сыграть решающую роль в вашем бизнесе, связанном с платформами без кода или с низким кодом. Все довольно просто: такие платформы используются в основном на этапах POC или MVP, чтобы протестировать бизнес-идею или максимально быстро выйти на рынок. насколько это возможно. Он также используется для создания нишевых решений, если вариант использования прост и нет необходимости в дополнительных функциях.

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

Огромные затраты на поддержку внутренней логики также важны, хотя они могут быть сведены к минимуму в случае правильного проектирования. Для решения задачи с ограниченным набором функционала можно импортировать внешний код — примером служит модель npm с закрытыми и открытыми компонентами. Такая low-code платформа будет поддерживаться сообществом, внося позитивные изменения в бизнес.

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

Наконец, небольшая идея в качестве бонуса к статье: вы можете использовать текстовое описание для создания каркаса вашего приложения. Например, Обработка естественного языка (NLP) для анализа текста на объективные и субъективные сущности, формирования структуры вашего приложения, а затем сгенерируйте код. Это не будет идеальным решением, и с нынешним состоянием технологий еще слишком рано говорить об этом подходе для платформ без кода, но как ключевая особенность вашей новой платформы с низким кодом, он может быть вполне применим в ближайшее будущее.

Автор Юрий Лучанинов, руководитель группы JavaScript в MobiDev.

Полная версия статьи была первоначально опубликована [здесь] (https://mobidev.biz/blog/how-to-build-an-ai-powered-financial-assistant-app) и основана на исследованиях технологии MobiDev.