Проблемы приложений, созданных на Bubble.io

В связи с хайпом NoCode инструментов в русскоязычным пространстве, количество так называемых “опытных Bubble специалистов” растет не по дням, а по часам. Я думаю, многие видели рекламу, которая обещает, что всего за неделю интенсива/курса/марафона (нужное подчеркнуть) вы научитесь разрабатывать приложения без кода и будете зарабатывать от $5000 в месяц.

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

Итак, с какими вопросами обычно обращаются ко мне на консультациях и что с завидной регулярностью приходится исправлять после других Bubble разработчиков?

Плохая структура данных

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

Варианты бывают разные. Например, минимум таблиц в приложении, но 50-100 полей в каждой из них, что плохо для производительности и поиска данных. Или наоборот. Десятки таблиц и еще больше полей в каждой.

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

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

Те, кто в теме Bubble, знают, что не всегда создатель записи может быть ее владельцем, поэтому я часто использую в таблицах отдельное поле с типом данных User.

А вот тут пример неправильной записи данных: вместо 2-х текстовых полей для ID и email пользователя лучше использовать одно поле с типом данных User.

Пример взят из приложения, которое пришло на аудит и доработку после "опытных" специалистов

Ужасная верстка

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

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

То, как выглядит верстка в самом редакторе, показывать не буду, поймут не все, но зачастую проекты на доработке – то еще испытание.

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

Неправильное использование типов данных

Ситуация из жизни.

Разработчик вместо типа данных yes/no (аналог классического true/false) использует текстовое значение. Или еще пример, вместо прямой ссылки на запись в другой таблице – поиск по текстовому ID.

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

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

Неиспользование опций

Или использование, но неправильное.

Опции – это крутая штука, которая помогает хранить небольшие статические данные, не требующие редактирования или добавления на постоянной основе.

Например:

  • Роли пользователей – “Админ”, “Клиент”
  • Статусы – “Новый”, “В работе”, “Выполнен”
  • Валюта – доллары, евро, фунты и т.д.
Так выглядят "Опции" в редакторе Bubble

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

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

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

Защита данных и правила доступа

Нужно знать, как правильно настроить доступ к самому редактору приложения (Settings -> General -> Application rights всегда должно быть Private для запущенного приложения). Доступ на редактирование приложения можно представлять через приглашение разработчика.

Что касается защиты данных, то для этого есть настройки приватности БД. Правда здесь лучше не зевать! При неверной настройке пользователь может не увидеть свои же данные или, что еще хуже, они будут общедоступными. Простейшая ошибка, невнимательность, недостающая галочка, а доверие клиента к вашему сервису уже не вернешь.

Пример настройки приватности для одной из таблиц

Помимо настроек приватности, можно использовать условия для переходов, показа блоков/страниц определенным ролям или предусмотреть переадресацию в случае ошибки. Кроме того, нужно следить за доступом к API и Data API приложения.

Одностраничники

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

Пример структуры одностраничного приложения (и это еще не самый плохой вариант)

Логика в приложении

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

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

Как не надо делать
Как надо делать

Разница в том, что в первом случае Bubble сначала найдет весь список пользователей и только потом начнет его фильтровать. А теперь представьте, если их тысячи! Во втором же, он сразу будет искать только подходящих пользователей.

Также лучше заменить длинные цепочки действий, особенно со множеством условий, на действия через backend workflow.

Много мусора

При создании приложения, особенно крупного, разработчики делают тестовые страницы и устанавливают различные плагины, чтобы расширить функционал. И, зачастую, при запуске или передаче продукта заказчику, “инвентаризацию” никто не проводит. Не стоит оставлять неиспользуемые плагины, стили и страницы, так как это утяжеляет проект в целом. Код неиспользуемого плагина может подгружаться при загрузке страницы. Это приводит к тому, что страница открывается в 2-3 раза дольше, чем могла бы.

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

Какой вывод можно из этого сделать?

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

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

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

0
2 комментария
Анатолий Сырьянов

Это как интернет-магазин на wordpress ))
Адекватные заказчики никогда на такое не согласятся... Поэтому нет ноукода. Есть говнокод конструкторный, на котором ваяются типовые элементарные приложения.

Ответить
Развернуть ветку
Егор Левин

Ага ага)

Сейчас большинство магазинов на платформах, а не на чистом коде

Битрикс, opencart. За no code будущее.

Сайты уже делают на wordpress и Tilda. Это и есть no code.

Ответить
Развернуть ветку
Читать все 2 комментария
null