Что нам стоит на Bubble построить (+ мнение о возможности симбиоза кода и nocode)

Привет! В статье я расскажу про альтернативный способ создания веб-приложений с помощью nocode инструмента Bubble.io - опишу преимущества, недостатки этого подхода, а также постараюсь раскрыть возможности "симбиоза" Javascript и Bubble для реализации качественных проектов и увеличения размера оплаты за работу.

Немного воды

Сразу оговорюсь, я понимаю, что задачу перед собой поставил амбициозную, плюс охватил большую область знаний от создания приложения до бизнес-аналитики и поиска рациональности в выборе средств создания ПО. Статья предназначена для ознакомления с конкретным инструментом, подходом к разработке на nocode-решениях и преследует цель дать несколько советов nocode-разработчикам.

Для начала введу в курс дела. Про использование nocode, lowcode, нейросетей типа ChatGPT сейчас наслышаны все, я не буду пиарить конкретные инструменты или топить за nocode, убеждать, как это, мол, круто, а программисты скоро будут не нужны. Само собой, это не так, просто разные инструменты будут помогать разработчику создавать приложение быстрее (на радость крупным компаниям), качественнее (к счастью клиентов) и даже с большей маржинальностью. Для себя я поставил задачи: раскрыть некоторые нюансы разработки без кода, трезво описать плюсы/минусы и подружить ноукодеров с языками разработки фронтенда. Это будет лонгрид, разделенный на главы, а потому приготовьтесь)

1. Контекст - опишу ограничения и входные данные

2. Опишу приложение, на которое буду опираться по ходу статьи

3. Как можно использовать JS и Bubble в "симбиозе"

4. Заключение

Контекст статьи

Я постараюсь адекватно оценить возможности совместного использования кода и nocode платформ в конкретных случаях:

• MVP для стартапа в целях тестирования гипотезы

• Средних размеров-маленькая SaaS с ограниченным бюджетом и без наполеоновских планов

• Веб-приложение для региональной компании (+ мобильное приложение по запросу)

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

1. В качестве nocode-инструмента я подразумеваю Bubble.io, как на текущий момент один из самых функциональных, эффективных и популярных инструментов (а еще на нем можно делать как веб-приложения, так и мобильные — то есть охватить сразу два направления). Он выполняет функции хостинга (приложение хранится на AWS), git-репозитория (можно сохранять прогресс точечно и возвращаться не только к конкретному "коммиту", но и к состоянию приложения в выбранный промежуток времени!), фронтенд и бэкэнд-платформ и позволяет дебажить приложение (функционал dev tools упакован в красивый интерфейс и позволяет пошагово отследить выполнение функций). Можно пробросить DNS-сервера к домену, а SSL стоит по умолчанию, как и базовая защита сайта от простейших атак. В общем, мы разрабатываем SaaS со всеми вытекающими плюсами и минусами, вопрос доверия - открытый)

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

Про приложение

За проект я взялся в ноябре 2022 года. Заказчик — предприниматель из России, занимающийся сдачей в аренду люксовых авто в Дубае. На тот момент уже был сайт на Тильде, через который потенциальные клиенты отправляли заявки на аренду машин. Моей задачей было создать мультиязычное (en-ru) мобильное приложение с расширенным (по сравнению с сайтом) функционалом, настроить двухфакторную авторизацию через Telegram и WhatsApp, а еще сделать интеграцию с amoCRM.

Над проектом трудились 3 человека:

В каждом проекте, за который берусь, я всегда требую: ТЗ (пусть не слишком формализованное, хотя бы в общих чертах должны быть описаны ключевые бизнес-процессы. Схема в Miro - вообще шик!), макет в Figma (навыков проектирования дизайна, тем более с глубоким понимание UI-китов Apple и Google у меня нет), несколько установочных звонков с заказчиком/его представителем для обсуждения проблемных вопросов, уточнения функциональности, других нюансов.

Разработчик на Bubble - это фуллстек в классическом понимании: ты должен отвечать и за БД, и за взаимодействие с сервисами через API, и за верстку со стилями, и функционал компонентов, и настройку процессов на бэке по расписанию, и тестирование... Именно этим я и занялся.

На старте проекта был составлен документ в гугл доке, в котором расписан процесс разработки по шагам с предварительной оценкой времени на каждую задачу — получился план на 120 часов работы. По нему было удобно отслеживать, какие появляются сложности, какой шаг занял сколько времени, когда нужно связаться с клиентом или подключить дизайнера. Там же мы вели список багов и отмечали, что и когда исправлено. Конечно, все это можно было запушить в любой Kanban, формализовать задачи для бэклога, используя, например ClickUp или другой сервис, но тут решили обойтись обычной табличкой.

Процесс создания веб-приложения

Разработку я разбил на шаги:

1. Создание БД.

2. Верстка и стили.

3. Внедрение мультиязычности.

4. Настройка workflow (это и есть связующее звено между бэком и фронтом, в котором происходят запросы к БД, отправляются данные по API, настраиваются обработчики событий, вроде onClick в JS - см. картинку ниже).

5. Работа с API Telegram, WhatsApp и amoCRM.

6. Настройка cron-событий для синхронизации данных приложения и amoCRM.

7. Автоматизированный импорт данных в БД (внесено более 300 автомобилей со всеми характеристиками в формате .csv).

8. Тестирование.

9. Доработки.

Полноценного ТЗ на приложение не было, только на интеграцию с amoCRM. Но зато я использовал подробный макет в Figma с дизайн-системой и уже существующий сайт для ориентира.

База данных крайне простая. Классические связи один ко одному и несколько технических табличек. В приложении важно настроить Privacy rules - чтобы защитить пользователей от раскрытия данных. ИБ приложений в Bubble - больная тема для сообщества, мало кто заботится об этом на этапе MVP (и так каждая копейка на счету), а иногда у разработчиков просто нет достаточной экспертизы. Платформа позволяет неплохо обезопасить данные встроенными средствами, надо просто изучить мануалы и реализовать базовую защиту.

Про функционал

Приложение состоит из четырех разделов:

• Главная — список всех автомобилей с фото, характеристиками, ценами. В карточке каждой машины — кнопка «Заказать», чтобы отправить заявку на аренду.

• Избранное — автомобили, которые пользователь лайкнул .

• Уведомления — заявки на аренду, отображается ход заказа по воронке продаж.

• ЛК — профиль пользователя с реферальным кодом, количеством набранных баллов и историей заказов.

Чтобы отправить заявку на аренду, нужно зарегистрироваться. Для этого необходимо ввести в приложении свой номер телефона и выбрать мессенджер, куда придет код для авторизации: Telegramили WhatsApp. Каждый раз человеку приходит новый код, с помощью которого можно зайти в приложение — украсть данные без стандартной комбинации логин+пароль гораздо сложнее. Для этого использовалась интеграция с Wazzup24 (чтобы не заморачиваться с WABA) и через Telegram Bot Api.

После регистрации можно забронировать автомобиль для себя или другого человека: заявка на аренду отразится в уведомлениях пользователя.

Из приложения заявка автоматически попадает в воронку продаж в amoCRM. Менеджер видит у себя в системе имя и контакты лида, откуда пришло бронирование. Дальше ответственный сотрудник связывается с клиентом, уточняет наличие автомобиля в выбранные даты, подтверждает цену и рассказывает, как и где забрать машину.

Еще в приложении есть специальные условия для постоянных клиентов — программа лояльности и реферальная программа. Вот как они работают:

• Программа лояльности: за каждую поездку пользователю начисляются баллы, которыми потом можно оплатить новую аренду или вывести деньги по ставке 1 балл = 0,5 долларов. Заявки на вывод денег также отправляются в CRM, где их обрабатывает менеджер.

• Реферальная программа: у каждого пользователя есть личный код, который можно отправить друзьям. Этот код нужно ввести при регистрации в приложении — тогда и владельцу кода, и его другу начисляются дополнительные баллы. Более того: владелец реферального кода будет получать баллы за каждую поездку друга.

Для проводки клиента через воронку, создания сделки, лида, настройки процесса по начислению баллов и синхронизации этих данных использовалось API amoCRM - неплохая документация и Postman способствовали быстрому прогрессу в изучении сервиса.

Благодаря кронам менеджер работает только в CRM, ему не нужно заходить в приложение и проверять, сколько на самом деле баллов на счету у пользователя и имеет ли вообще он право на обмен баллов на денежные средства.

Загрузка приложения в сторы

Отдельная сложность — выложить готовое приложение в сторы. Это на самом деле долгий, затратный и не очень интересный процесс: нужно создать аккаунты разработчика под клиента, купить дополнительные плагины (мобильное приложение по сути своей является оберткой веба - этаким, сам процесс "конвертации" стоит 365$), заполнить кучу документации и конечно решить вопрос с оплатой, потому что из России это сделать нельзя.

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

В январе приложение было опубликовано в App Store, и сейчас в нем уже больше 100 зарегистрированных пользователей. Из Google Play приложение недавно отозвали, этой проблемой сейчас занимается проджект-менеджер.

Итог разработки

Заказчик получил полностью готовое приложение через 2 месяца. Еще 2 недели ушло на бюрократию с выкладыванием в сторы. Мобильное приложение в обоих магазинах + веб-приложение (Mobile First) обошлось заказчику в ~240 тысяч рублей. Сжатых сроков не было, поэтому я мог себе позволить работать неспеша, параллельно с другими проектами. В целом, считаю, что это достойный результат для бизнеса в соотношении цена/время/качество. Конечно, есть свои минусы, но об этом подробнее расскажу ниже.

Использование JS и Bubble в симбиозе

С начала 2022 я стал заниматься изучением фронтенда (JS + React), а сейчас углубленно изучаю Node.js. Изначально я стал изучать языки, чтобы стать более универсальным разработчиком и увеличить размер оплаты. В моменте я заметил, что после Bubble изучать код значительно легче — новые знания попадают на уже удобренную почву, а некоторые концепции в голове раскрываются по аналогии.

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

Достоинства:

• Меньше затраченного времени на разработку

• Маленькая команда, которую легко контролировать заказчику

• Сокращение расходов на оплату труда

• Универсальность решения (на выходе получаем веб + мобильные приложения)

• Отсутствие необходимости разворачивания окружения, какого-то ПО, серверных мощностей, возни с хостингом

• Удобство проведения стадий ЖЦ проекта - от разработки до сдачи клиенту

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

Недостатки:

• Сложность внедрения нестандартного функционала

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

• Непросто найти хорошего разраба, который знаком с фундаментальным пониманием основ построения качественного веб-приложения (чтобы и БД была не кривая, и адаптивная flex-верстка не сыпалась, и оплата через API Stripe работала, и форма с валидацией отправлялась нормально)

• Меньшее качество проекта в связи с тем, что разработчик является "швейцарским ножом" - отсутствие возможности внедрить UNIT-тесты, автоматизировать отлов багов, ограниченный размер команды неизменно ведут к появлению оных на проде

• Отсутствие возможности переиспользовать компоненты одного проекта в другом (внутри одного проекта это не вызывает проблем). Это прям большой недостаток, который после изучения БЭМ и принципов SOLID применительно к JS и React подтолкнул меня к переходу в "классическую разработку"

• С точки зрения эксплуатации в России: необходимость лепки костылей для соответствия 159-ФЗ, слабо развитая стартап-культура, безумные запросы заказчиков (хочу Битрикс24 за 100к)

В целом, я думаю, что будущее за синергией nocode-решений и кода. 90% приложений не содержат в себе каких-то необыкновенных фичей, с которыми nocode не справится. Просто нужно знать, когда и какой инструмент использовать, а когда нужно перестать костылить и реализовать все на ванильном JS или Node (фронтенд-фреймворки вроде React в Bubble пока не поддерживаются).

Вот тут я и хотел бы перейти к преимуществам совместного использования программирования в JS в Bubble. Конечно, ноукод-разработчику неплохо бы понимать JSON, принципы двухфакторной авторизации, знать основы оптимизации запросов к БД и почему первичные ключи должны быть уникальными и желательно иметь тип Number. Но как я сказал выше, одним из серьезных бичей в Bubble является переиспользование компонентов. Это касается как кастомных UI-элементов (например, календарей), так и банальных настроек полей в форме, API-запросов к сервисам (я не могу просто скопировать файл api-amocrm.js - мне приходится заново заполнять заголовки, ключи аутентификации, тело запроса, тестировать доступ) и многого другого.

Решить эту проблему можно просто, зная банальную связку HTML+CSS+JS и создав свой собственный плагин, который можно потом внедрять в любой свой проект и даже продавать на маркетплейсе другим разработчикам.

Также я сталкивался с проблемой реализации нативных пушей (с помощью API OneSignal) на телефонах в PWA-приложении из-за конфликта Service Worker-ов двух систем. Решалось все работой напильником по готовому плагину, позволяющему реализовать PWA и написанием маленькой асинхронной функции для OneSignal.

<script>
function getPlayerID() {
  const prom = new Promise(resolve => {
    OneSignal.push(async function () {
      await OneSignal.getUserId(function(userId) {
        resolve(userId)
      });
    });
  })
  prom.then( res => { 
    bubble_fn_playerID(res)
  });
}
getPlayerID();
</script>

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

А что с инпутами/чекбоксами форм, календарями, другими html-элементами? Я предпочитаю делать шаблоны для себя и сохранять CSS, а потом использовать в следующих своих проектах. Это позволяет не нагружать проект лишними плагинами, гибко менять UI и экономить деньги заказчиков. Например, код для реализации своего (нормально выглядящего, а не противного дефолтного) чекбокса в Баббле может выглядеть так.

<style>
label:after {
  display: block;
  height: 23px;
  width: 23px;
  position: absolute;
  top: 0;
  left: 0;
}
input[type=checkbox]:checked + label:after {
  width: 23px;
  height: 23px;
  background-color: #41AD4C;
  color: #fff;
  content: '\2713';
  text-align: center;
  left: 4px;
  top: 3px;
}
input[type=checkbox]{
  width: 23px;
  height: 23px;
}
</style>

Если хочешь завести цикл в цикле на бэке или провести, например, бинарный поиск по огромной базе лекций в LMS - придется изучить логические операции и основы алгоритмов, иначе твое колёсико ожидания запроса будет крутиться овер-долго. А студент напишет, что приложение медленное из-за того, что оно написано на "каком-то конструкторе".

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

Заключение

Зачем нужна эта статья? Недавно меня пригласили показать описанное в статье приложение на региональной выставке программистов в городе, где я живу. Многие знакомые кодеры были удивлены, какой продукт можно сделать на ноукоде быстро, недорого и силами одного разработчика, а не команды. Здесь я хотел показать некоторые возможности nocode-решений сообществу, рассказать про преимущества знания ЯП ноукодерам и постараться подружить эти два направления в голове. Надеюсь, данная статья этому поспособствует.

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