Ограничения no-code и как с ними работать: опыт обхода ограничений Bubble.io

Пост о том, с какими ограничениями мы столкнулись при разработке наших приложений в Bubble.io (low-code платформа), и как мы их обходили. Перечислю несколько конкретных кейсов и возможных решений.

Обычно об ограничениях no-code платформ пишут слишком общо, и часто в подобных статьях вижу немного устаревшее понимание технологии. Поэтому захотелось на максимально конкретных кейсах показать эти ограничения и пути обхода.

Спойлер: ограничения no-code обычно обходятся с помощью кода (directed by Robert b. Weide).

Итак. Вот описание нескольких кейсов:

Задача: Проектируем боковое меню в приложении, внизу бокового меню снизу должна быть кнопка “Log out”. Но чтобы кнопка всегда была внизу, высота бокового меню должна адаптироваться под размер экрана пользователя. Такая адаптация делается максимально просто - высота окна должна быть 100vh (100 viewheight, то есть 100% от высоты видимой области браузера).
Проблема: Удивительное ограничение в дизайне. У Bubble нет опции VH для обозначения высоты экранов.
Решение: кастомный CSS.

Задача: Добавляем в приложение поле ввода (multiline input), чтобы пользователь формулировал запрос текстом в несколько строк. Берем готовый элемент “multiline input” и вставляем в приложение.
Проблема: ограничение самого элемента - нельзя отправить сообщение по нажатию кнопки enter. Enter = перенос на следующую строку. Плохо, что не предусмотрена возможность перенастроить горячие кнопки в настройках элемента.
Решение: кастомный JavaScript

Задача: Интегрируем OpenAI GPT в приложение через API. Обработка запроса требует времени, пользователю приходится долго ждать, пока ответ сформируется. Решение проблемы - “стриминг” ответа. То есть, чтобы пользователь не ждал формирования ответа целиком, а ответ генерировался в живом времени, символ за символом, слово за словом, как в ChatGPT. Для этого нужна база данных, обновляемая в живом времени.
Проблема: В Bubble нет базы данных, обновляемой в живом времени.
Решение: Использование плагина Bubble (с WebSocket) или стороннего сервиса, такого как Firebase или Supabase.

Задача: Интегрируем парсинг данных в приложение через API. Приложение должно спарсить сторонний сайт. Языковая модель затем делает выводы из собранных данных.
Проблема: Парсинг занимает время, у Bubble ограничение времени ожидания API запроса 2,5 минуты (session timeout). Приложение не работает.
Решение: Ускоряем парсинг или используем стороннее решение, как в предыдущем пункте.

Важно: весь код для обхода ограничений Bubble.io написан чатом GPT.

Для решения проблемы в первую очередь важно техническое понимание этой проблемы и готовность погружаться и решать. Ну и желательно доступ к Chat GPT.
У no-code конечно же есть ограничения - фундаментальные, обойти которые невозможно. Из приведенных примеров: нельзя увеличить время ожидания ответа на API запрос. Мы пока не столкнулись с ограничениями, где нельзя было бы накреативить решение.
No-code прекрасно подходит для решения бизнес-кейсов. Создавать deep tech стартап на no-code платформе конечно же никто не будет.
Бывают ситуации, когда изначально главная фича ожидаемого продукта находится вне поля возможностей no-code. В таких случаях, стоит это принять на старте и искать другое решение.

В своем телеграм-канале пишу про no-code, ИИ и другие технологии, которые делают нашу жизнь проще :)

Ограничения no-code и как с ними работать: опыт обхода ограничений Bubble.io

1. Исправление UI

2. Отправка сообщений по нажатию на Enter

3. Интеграция LLM

4. Парсинг данных и проблема ожидания

Общие наблюдения и выводы: