Pull to refresh

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

Level of difficultyEasy
Reading time11 min
Views7.4K

Привет! В статье я расскажу про альтернативный способ создания веб-приложений с помощью 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 человека:

Проджект-менеджер

Дизайнер

Разработчик

Задачи

Общение с заказчиком и создание ТЗ (совместно), проблемные вопросы

Подготовка дизайн-макета в Figma (сначала грубый, потом подробный с кликабельными элементами и подобием дизайн системы)

Создание БД, разработка приложения, настройка интеграции с amoCRM, выкладывание в сторы

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

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

Проблема

Отсюда в том числе и берет начало хейт и недоверие к ноукод-разработчикам: мало кто разбирается в архитектуре БД и знает, как приводить её хотя бы к 3НФ, знает про принципы REST API, но зато разработчик с радостью берется пилить кнопочки в приложении. С другой стороны, часто в таком случае, задача со стороны заказчика звучит как "создайте мне Авито за 50к".

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

Документ с задачами в проекте
Документ с задачами в проекте

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

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

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

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

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

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

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

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

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

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

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

Workflow в приложении
Workflow в приложении

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

Макет в Figma для приложения
Макет в Figma для приложения

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

База данных в приложении
База данных в приложении

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

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

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

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

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

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

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

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

Экраны приложения для входа
Экраны приложения для входа

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

Некоторые разделы меню
Некоторые разделы меню

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

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

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

Условия для постоянных клиентов
Условия для постоянных клиентов

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

Создание запросов к API amoCRM
Создание запросов к API amoCRM

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

Кроны на бэке для синхронизации данных с CRM
Кроны на бэке для синхронизации данных с 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 пока не поддерживаются).

Маркетплейс плагинов (собственно все и реализованы на связке HTML+CSS+JS)
Маркетплейс плагинов (собственно все и реализованы на связке HTML+CSS+JS)

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

Составление одного запроса к API иногда может занять длительное время
Составление одного запроса к API иногда может занять длительное время

Решить эту проблему можно просто, зная банальную связку 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 или руководящие позиции.

Tags:
Hubs:
Total votes 4: ↑3 and ↓1+3
Comments6

Articles