Привет! В статье я расскажу про альтернативный способ создания веб-приложений с помощью nocode инструмента Bubble.io - опишу преимущества, недостатки этого подхода, а также постараюсь раскрыть возможности "симбиоза" Javascript и Bubble для реализации качественных проектов и увеличения размера оплаты за работу.
Немного воды
Сразу оговорюсь, я понимаю, что задачу перед собой поставил амбициозную, плюс охватил большую область знаний от создания приложения до бизнес-аналитики и поиска рациональности в выборе средств создания ПО. Статья предназначена для ознакомления с конкретным инструментом, подходом к разработке на nocode-решениях и преследует цель дать несколько советов nocode-разработчикам.
Для начала введу в курс дела. Про использование nocode, lowcode, нейросетей типа ChatGPT сейчас наслышаны все, я не буду пиарить конкретные инструменты или топить за nocode, убеждать, как это, мол, круто, а программисты скоро будут не нужны. Само собой, это не так, просто разные инструменты будут помогать разработчику создавать приложение быстрее (на радость крупным компаниям), качественнее (к счастью клиентов) и даже с большей маржинальностью. Для себя я поставил задачи: раскрыть некоторые нюансы разработки без кода, трезво описать плюсы/минусы и подружить ноукодеров с языками разработки фронтенда. Это будет лонгрид, разделенный на главы, а потому приготовьтесь)
Контекст - опишу ограничения и входные данные
Опишу приложение, на которое буду опираться по ходу статьи
Как можно использовать JS и Bubble в "симбиозе"
Заключение
Контекст статьи
Я постараюсь адекватно оценить возможности совместного использования кода и nocode платформ в конкретных случаях:
MVP для стартапа в целях тестирования гипотезы
Средних размеров-маленькая SaaS с ограниченным бюджетом и без наполеоновских планов
Веб-приложение для региональной компании (+ мобильное приложение по запросу)
Я считаю, что эти случаи наиболее релевантны на текущий момент в связи с особенностями позиционирования nocode-инструментов в целом (маркетинг работает на лозунге "Создай MVP быстро и дешево без кода у себя на кухне", реакции и восприятия их бизнесом и средним уровнем разрабов на рынке (он, чего уж греха таить, не очень высокий). Опишу ограничения, чтобы не вызывать недопонимание по тексту:
В качестве nocode-инструмента я подразумеваю Bubble.io, как на текущий момент один из самых функциональных, эффективных и популярных инструментов (а еще на нем можно делать как веб-приложения, так и мобильные — то есть охватить сразу два направления). Он выполняет функции хостинга (приложение хранится на AWS), git-репозитория (можно сохранять прогресс точечно и возвращаться не только к конкретному "коммиту", но и к состоянию приложения в выбранный промежуток времени!), фронтенд и бэкэнд-платформ и позволяет дебажить приложение (функционал dev tools упакован в красивый интерфейс и позволяет пошагово отследить выполнение функций). Можно пробросить DNS-сервера к домену, а SSL стоит по умолчанию, как и базовая защита сайта от простейших атак. В общем, мы разрабатываем SaaS со всеми вытекающими плюсами и минусами, вопрос доверия - открытый)
Многие нюансы я поясняю на основе создания мной мобильного приложения для компании, занимающейся сдачей в аренду автомобилей премиум-класса.
Про приложение
За проект я взялся в ноябре 2022 года. Заказчик — предприниматель из России, занимающийся сдачей в аренду люксовых авто в Дубае. На тот момент уже был сайт на Тильде, через который потенциальные клиенты отправляли заявки на аренду машин. Моей задачей было создать мультиязычное (en-ru) мобильное приложение с расширенным (по сравнению с сайтом) функционалом, настроить двухфакторную авторизацию через Telegram и WhatsApp, а еще сделать интеграцию с amoCRM.
Над проектом трудились 3 человека:
Проджект-менеджер | Дизайнер | Разработчик | |
Задачи | Общение с заказчиком и создание ТЗ (совместно), проблемные вопросы | Подготовка дизайн-макета в Figma (сначала грубый, потом подробный с кликабельными элементами и подобием дизайн системы) | Создание БД, разработка приложения, настройка интеграции с amoCRM, выкладывание в сторы |
В каждом проекте, за который берусь, я всегда требую: ТЗ (пусть не слишком формализованное, хотя бы в общих чертах должны быть описаны ключевые бизнес-процессы. Схема в Miro - вообще шик!), макет в Figma (навыков проектирования дизайна, тем более с глубоким понимание UI-китов Apple и Google у меня нет), несколько установочных звонков с заказчиком/его представителем для обсуждения проблемных вопросов, уточнения функциональности, других нюансов.
Разработчик на Bubble - это фуллстек в классическом понимании: ты должен отвечать и за БД, и за взаимодействие с сервисами через API, и за верстку со стилями, и функционал компонентов, и настройку процессов на бэке по расписанию, и тестирование... Именно этим я и занялся.
Проблема
Отсюда в том числе и берет начало хейт и недоверие к ноукод-разработчикам: мало кто разбирается в архитектуре БД и знает, как приводить её хотя бы к 3НФ, знает про принципы REST API, но зато разработчик с радостью берется пилить кнопочки в приложении. С другой стороны, часто в таком случае, задача со стороны заказчика звучит как "создайте мне Авито за 50к".
На старте проекта был составлен документ в гугл доке, в котором расписан процесс разработки по шагам с предварительной оценкой времени на каждую задачу — получился план на 120 часов работы. По нему было удобно отслеживать, какие появляются сложности, какой шаг занял сколько времени, когда нужно связаться с клиентом или подключить дизайнера. Там же мы вели список багов и отмечали, что и когда исправлено. Конечно, все это можно было запушить в любой Kanban, формализовать задачи для бэклога, используя, например ClickUp или другой сервис, но тут решили обойтись обычной табличкой.
![Документ с задачами в проекте Документ с задачами в проекте](https://habrastorage.org/getpro/habr/upload_files/c46/4cc/1d2/c464cc1d2cbf971d5b21b008d4ec1c5d.jpeg)
Процесс создания веб-приложения
Разработку я разбил на шаги:
Создание БД.
Верстка и стили.
Внедрение мультиязычности.
Настройка workflow (это и есть связующее звено между бэком и фронтом, в котором происходят запросы к БД, отправляются данные по API, настраиваются обработчики событий, вроде onClick в JS - см. картинку ниже).
Работа с API Telegram, WhatsApp и amoCRM.
Настройка cron-событий для синхронизации данных приложения и amoCRM.
Автоматизированный импорт данных в БД (внесено более 300 автомобилей со всеми характеристиками в формате .csv).
Тестирование.
Доработки.
![Workflow в приложении Workflow в приложении](https://habrastorage.org/getpro/habr/upload_files/5fc/531/607/5fc531607cbf66024cc1cd88f11b2bb4.png)
Полноценного ТЗ на приложение не было, только на интеграцию с amoCRM. Но зато я использовал подробный макет в Figma с дизайн-системой и уже существующий сайт для ориентира.
![Макет в Figma для приложения Макет в Figma для приложения](https://habrastorage.org/getpro/habr/upload_files/a94/560/917/a94560917b4f50b677ce170ffd5b0399.jpeg)
База данных крайне простая. Классические связи один ко одному и несколько технических табличек. В приложении важно настроить Privacy rules - чтобы защитить пользователей от раскрытия данных. ИБ приложений в Bubble - больная тема для сообщества, мало кто заботится об этом на этапе MVP (и так каждая копейка на счету), а иногда у разработчиков просто нет достаточной экспертизы. Платформа позволяет неплохо обезопасить данные встроенными средствами, надо просто изучить мануалы и реализовать базовую защиту.
![База данных в приложении База данных в приложении](https://habrastorage.org/getpro/habr/upload_files/c9a/8d7/08a/c9a8d708a9e6e37e42ff018105773a4b.png)
Про функционал
Приложение состоит из четырех разделов:
Главная — список всех автомобилей с фото, характеристиками, ценами. В карточке каждой машины — кнопка «Заказать», чтобы отправить заявку на аренду.
Избранное — автомобили, которые пользователь лайкнул .
Уведомления — заявки на аренду, отображается ход заказа по воронке продаж.
ЛК — профиль пользователя с реферальным кодом, количеством набранных баллов и историей заказов.
Чтобы отправить заявку на аренду, нужно зарегистрироваться. Для этого необходимо ввести в приложении свой номер телефона и выбрать мессенджер, куда придет код для авторизации: Telegramили WhatsApp. Каждый раз человеку приходит новый код, с помощью которого можно зайти в приложение — украсть данные без стандартной комбинации логин+пароль гораздо сложнее. Для этого использовалась интеграция с Wazzup24 (чтобы не заморачиваться с WABA) и через Telegram Bot Api.
После регистрации можно забронировать автомобиль для себя или другого человека: заявка на аренду отразится в уведомлениях пользователя.
![Экраны приложения для входа Экраны приложения для входа](https://habrastorage.org/getpro/habr/upload_files/da4/4cf/433/da44cf433d974b5f0ff7ba07071af539.jpeg)
Из приложения заявка автоматически попадает в воронку продаж в amoCRM. Менеджер видит у себя в системе имя и контакты лида, откуда пришло бронирование. Дальше ответственный сотрудник связывается с клиентом, уточняет наличие автомобиля в выбранные даты, подтверждает цену и рассказывает, как и где забрать машину.
![Некоторые разделы меню Некоторые разделы меню](https://habrastorage.org/getpro/habr/upload_files/664/cf3/260/664cf326027dd938f4bc288e162a0aab.jpeg)
Еще в приложении есть специальные условия для постоянных клиентов — программа лояльности и реферальная программа. Вот как они работают:
Программа лояльности: за каждую поездку пользователю начисляются баллы, которыми потом можно оплатить новую аренду или вывести деньги по ставке 1 балл = 0,5 долларов. Заявки на вывод денег также отправляются в CRM, где их обрабатывает менеджер.
Реферальная программа: у каждого пользователя есть личный код, который можно отправить друзьям. Этот код нужно ввести при регистрации в приложении — тогда и владельцу кода, и его другу начисляются дополнительные баллы. Более того: владелец реферального кода будет получать баллы за каждую поездку друга.
![Условия для постоянных клиентов Условия для постоянных клиентов](https://habrastorage.org/getpro/habr/upload_files/63b/0e7/8f3/63b0e78f325128a8909d2f9674e4deea.jpeg)
Для проводки клиента через воронку, создания сделки, лида, настройки процесса по начислению баллов и синхронизации этих данных использовалось API amoCRM - неплохая документация и Postman способствовали быстрому прогрессу в изучении сервиса.
![Создание запросов к API amoCRM Создание запросов к API amoCRM](https://habrastorage.org/getpro/habr/upload_files/c4f/0a4/91d/c4f0a491d340a4337ac47d731b347c74.jpeg)
Благодаря кронам менеджер работает только в CRM, ему не нужно заходить в приложение и проверять, сколько на самом деле баллов на счету у пользователя и имеет ли вообще он право на обмен баллов на денежные средства.
![Кроны на бэке для синхронизации данных с CRM Кроны на бэке для синхронизации данных с CRM](https://habrastorage.org/getpro/habr/upload_files/6fc/183/ee5/6fc183ee5f15a3ebc0a4a4c4d67c2fd9.jpeg)
Загрузка приложения в сторы
Отдельная сложность — выложить готовое приложение в сторы. Это на самом деле долгий, затратный и не очень интересный процесс: нужно создать аккаунты разработчика под клиента, купить дополнительные плагины (мобильное приложение по сути своей является оберткой веба - этаким, сам процесс "конвертации" стоит 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)](https://habrastorage.org/getpro/habr/upload_files/f9b/d7e/498/f9bd7e49844665ffab5da339364ae9de.png)
Вот тут я и хотел бы перейти к преимуществам совместного использования программирования в JS в Bubble. Конечно, ноукод-разработчику неплохо бы понимать JSON, принципы двухфакторной авторизации, знать основы оптимизации запросов к БД и почему первичные ключи должны быть уникальными и желательно иметь тип Number. Но как я сказал выше, одним из серьезных бичей в Bubble является переиспользование компонентов. Это касается как кастомных UI-элементов (например, календарей), так и банальных настроек полей в форме, API-запросов к сервисам (я не могу просто скопировать файл api-amocrm.js - мне приходится заново заполнять заголовки, ключи аутентификации, тело запроса, тестировать доступ) и многого другого.
![Составление одного запроса к API иногда может занять длительное время Составление одного запроса к API иногда может занять длительное время](https://habrastorage.org/getpro/habr/upload_files/8a8/97e/daa/8a897edaacb4268eb26b39c02a66012e.jpg)
Решить эту проблему можно просто, зная банальную связку 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. Мы не можем опереться на готовые библиотеки, поэтому придется изучать работу с карманами, негативным и позитивным просмотром и иметь под рукой шпаргалку с готовыми часто используемыми комбинациями.
![Если забыл основы регулярок Если забыл основы регулярок](https://habrastorage.org/getpro/habr/upload_files/ad3/fa9/182/ad3fa918282a32ea1a4f12892b39d28b.jpg)
А что с инпутами/чекбоксами форм, календарями, другими 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 или руководящие позиции.