Что нам стоит на Bubble построить (кейс - мобильное приложение для аренды спорткаров в Дубае)
Привет! Меня зовут Женя. В статье я расскажу про альтернативный способ создания веб-приложений с помощью nocode инструмента Bubble. io — опишу преимущества, недостатки этого подхода, а также постараюсь раскрыть возможности «симбиоза» Javascript и Bubble для реализации качественных проектов и увеличения размера оплаты за работу.
Предисловие
Для начала введу в курс дела. Про использование nocode, lowcode, нейросетей типа ChatGPT сейчас наслышаны все, я не буду пиарить конкретные инструменты или топить за nocode, убеждать, как это, мол, круто, а программисты скоро будут не нужны. Само собой, это не так, просто разные инструменты будут помогать разработчику создавать приложение быстрее (на радость крупным компаниям) , качественнее (к счастью клиентов) и даже с большей маржинальностью. Для себя я поставил задачи: раскрыть некоторые нюансы разработки без кода, трезво описать плюсы/минусы и подружить ноукодеров с языками разработки фронтенда. Это будет лонгрид, а потому приготовьтесь)
- Контекст — опишу ограничения и входные данные
- Опишу приложение, на которое буду опираться по ходу статьи
- Как можно использовать языки программирования и Bubble в «симбиозе»
- Заключение
Контекст статьи
Я постараюсь адекватно оценить возможности совместного использования кода и nocode платформ в конкретных случаях:
- MVP для стартапа в целях тестирования гипотезы
- Средних размеров-маленькая SaaS с ограниченным бюджетом и без наполеоновских планов
- Веб-приложение для региональной компании (+ мобильное приложение по запросу)
Я считаю, что эти случаи наиболее релевантны на текущий момент в связи с особенностями позиционирования nocode-инструментов в целом (маркетинг работает на лозунге «Создай MVP быстро и дешево без кода у себя на кухне», реакции и восприятия их бизнесом и средним уровнем разрабов на рынке (он, чего уж греха таить, не очень высокий) . Опишу ограничения, чтобы не вызывать недопонимание по тексту:
- В качестве nocode-инструмента я подразумеваю Bubble. io, как на текущий момент один из самых функциональных, эффективных и популярных инструментов (а еще на нем можно делать как веб-приложения, так и мобильные — то есть охватить сразу два направления) . Он выполняет функции хостинга (приложение хранится на AWS) , git-репозитория (можно сохранять прогресс точечно и возвращаться не только к конкретному «коммиту», но и к состоянию приложения в выбранный промежуток времени) , фронтенд и бэкэнд-платформ и позволяет дебажить приложение. Можно пробросить DNS-сервера к домену, а SSL стоит по умолчанию, как и базовая защита сайта от простейших атак. В общем, мы разрабатываем SaaS со всеми вытекающими плюсами и минусами, вопрос доверия — открытый)
- Многие нюансы я поясняю на основе созданного мной мобильного приложения для компании, занимающейся сдачей в аренду автомобилей премиум-класса в Дубае
- В статье будет немного технической информации, но больш
Про приложение
За проект я взялся в ноябре 2022 года (он попал ко мне через веб-студию, в которой я работал на тот момент) . Заказчик — предприниматель из России, занимающийся сдачей в аренду люксовых авто в Дубае.
На тот момент уже был сайт на Тильде, через который потенциальные клиенты отправляли заявки на аренду машин. Моей задачей было создать мультиязычное (en-ru) мобильное приложение с расширенным (по сравнению с сайтом) функционалом, настроить двухфакторную авторизацию через Telegram и WhatsApp, а еще сделать интеграцию с amoCRM. Инструмент разработки — Bubble — клиенты выбрали сами. Мне кажется, из-за самых подходящих тарифов (на тот момент) .
Над проектом трудились 3 человека: 1) проджект-менеджер (общение с заказчиком и создание ТЗ (совместно) , проблемные вопросы) , 2) дизайнер (подготовка дизайн-макета в Figma — сначала грубый, потом подробный с кликабельными элементами и подобием дизайн системы) , 3) разработчик — это собственно я (занимался собственно созданием БД, разработкой приложения, настройкой интеграции с amoCRM, выкладыванием в сторы) .
В каждом проекте, за который берусь, я всегда требую: ТЗ (пусть не слишком формализованное, хотя бы в общих чертах должны быть описаны ключевые бизнес-процессы. Схема в Miro — вообще шик!) , макет в Figma (навыков проектирования дизайна, тем более с глубоким понимание UI-китов Apple и Google у меня нет) , несколько установочных звонков с заказчиком/его представителем для обсуждения проблемных вопросов, уточнения функциональности, других нюансов.
Разработчик на Bubble — это фуллстек в классическом понимании: ты должен отвечать и за БД, и за взаимодействие с сервисами через API, и за верстку со стилями, и функционал компонентов, и настройку процессов на бэке по расписанию, и тестирование… Именно этим я и занялся.
Проблема
На старте проекта был составлен документ в гугл доке, в котором расписан процесс разработки по шагам с предварительной оценкой времени на каждую задачу — получился план на 120 часов работы. По нему было удобно отслеживать, какие появляются сложности, какой шаг занял сколько времени, когда нужно связаться с клиентом или подключить дизайнера. Там же мы вели список багов и отмечали, что и когда исправлено. Конечно, все это можно было запушить в любой Kanban, формализовать задачи для бэклога, используя, например ClickUp или другой сервис, но тут решили обойтись обычной табличкой.
Процесс создания веб-приложения
Разработку я разбил на шаги:
- Создание БД
- Верстка и стили
- Внедрение мультиязычности
- Настройка workflow (это и есть связующее звено между бэком и фронтом, в котором происходят запросы к БД, отправляются данные по API, настраиваются обработчики событий, вроде onClick в JS — см. картинку ниже)
- Работа с API Telegram, WhatsApp и amoCRM
- Настройка cron-событий для синхронизации данных приложения и amoCRM
- Автоматизированный импорт данных в БД (внесено более 300 автомобилей со всеми характеристиками в формате. csv)
- Тестирование
- Доработки
Полноценного ТЗ на приложение не было, только на интеграцию с 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 тысяч рублей. Сжатых сроков не было, поэтому я мог себе позволить работать неспеша, параллельно с другими проектами. В целом, считаю, что это достойный результат для бизнеса в соотношении цена/время/качество. Конечно, есть свои минусы, но об этом подробнее расскажу ниже.
Использование языков программирования и Bubble в симбиозе
С начала 2022 я стал заниматься изучением фронтенда (JS + React) , а сейчас углубленно изучаю Node.js. Изначально я стал изучать языки, чтобы стать более универсальным разработчиком и увеличить размер оплаты. В моменте я заметил, что после Bubble изучать код значительно легче — новые знания попадают на уже удобренную почву, а некоторые концепции в голове раскрываются по аналогии.
Опираясь на свой опыт в обеих сферах (хотя пока опыт в классической разработке еще не слишком обширный), я хотел бы описать конкретные плюсы и минусы идеи создания приложения на Bubble.io:
Достоинства:
- Меньше затраченного времени на разработку
- Маленькая команда, которую легко контролировать заказчику
- Сокращение расходов на оплату труда
- Универсальность решения (на выходе получаем веб + мобильные приложения)
- Отсутствие необходимости разворачивания окружения, какого-то ПО, серверных мощностей, возни с хостингом
- Удобство проведения стадий ЖЦ проекта — от разработки до сдачи клиенту
- Просто дебажить, функционал отслеживания нагрузки на сервер, весь проект можно посмотреть с разных сторон в одном месте
Недостатки:
- Сложность внедрения нестандартного функционала
- Bubble позволяет разрабатывать только SaaS — отсюда вытекают минусы с доверием, безопасностью, ограниченной функциональностью в условиях отсутствия подключения к сети
- Непросто найти хорошего разраба, который знаком с фундаментальным пониманием основ построения качественного веб-приложения (чтобы и БД была не кривая, и адаптивная flex-верстка не сыпалась, и оплата через API Stripe работала, и форма с валидацией отправлялась нормально)
- Меньшее качество проекта в связи с тем, что разработчик является «швейцарским ножом» — отсутствие возможности внедрить UNIT-тесты, автоматизировать отлов багов, ограниченный размер команды неизменно ведут к появлению оных на проде
- Отсутствие возможности переиспользовать компоненты одного проекта в другом (внутри одного проекта это не вызывает проблем) . Это прям большой недостаток, который после изучения БЭМ и принципов SOLID применительно к JS и React подтолкнул меня к переходу в «классическую разработку»
- С точки зрения эксплуатации в России: необходимость лепки костылей для соответствия 159-ФЗ, слабо развитая стартап-культура, безумные запросы заказчиков (хочу Битрикс24 за 100к)
Опциональный минус — сейчас Bubble. io вводит (нуу, пытается по крайней мере) новые тарифы на оплату и использование среды. Не вдаваясь в технические подробности, смысл от нововведений такой — создавать приложение фрилансеру в одиночку на минимальных тарифах будет невыгодно. Стартапам запуск будет обходиться дороже. Возможно ничего особо не изменится для крупных студий разработки вроде Zeroqode, Airdev и других, но это покажет только время. А теперь, почему «пытается»? Ранее в Bubble. io уже пытались поменять схему тарифных планов, сообщество восприняло это в штыки и создатели благоразумно закинули эту идею в ящик. Что произойдет на этот раз — будем посмотреть.
В целом, я думаю, что будущее за синергией nocode-решений и кода. 90% приложений не содержат в себе каких-то необыкновенных фичей, с которыми nocode не справится. Просто нужно знать, когда и какой инструмент использовать, а когда нужно перестать костылить и реализовать все на ванильном JS или Node (фронтенд-фреймворки вроде React в Bubble пока не поддерживаются) .
Вот тут я и хотел бы перейти к преимуществам совместного использования программирования в JS в Bubble. Конечно, ноукод-разработчику неплохо бы понимать JSON, принципы двухфакторной авторизации, знать основы оптимизации запросов к БД и почему первичные ключи должны быть уникальными. Но как я сказал выше, одним из серьезных бичей в Bubble является переиспользование компонентов. Это касается как кастомных UI-элементов (например, календарей), так и банальных настроек полей в форме, API-запросов к сервисам и многого другого.
Решить эту проблему можно просто, зная банальную связку HTML+CSS+JS и создав свой собственный плагин, который можно потом внедрять в любой свой проект и даже продавать на маркетплейсе другим разработчикам.
Приведу еще несколько примеров возникающих проблем:
- Реализация нативных пушей (с помощью API OneSignal) на телефонах в PWA-приложении из-за конфликта Service Worker-ов двух систем. Решалось все работой напильником по готовому плагину, позволяющему реализовать PWA и написанием маленькой асинхронной функции для OneSignal.
- Валидация вводимых данных тоже не сладкая задача в проектах на Bubble. И тут конечно никуда без нативной поддержки Regex. Мы не можем опереться на готовые библиотеки, поэтому придется изучать работу с карманами, негативным и позитивным просмотром и иметь под рукой шпаргалку с готовыми часто используемыми комбинациями регулярных выражений.
- А что с инпутами/чекбоксами форм, календарями, другими html-элементами? Я предпочитаю делать шаблоны для себя и сохранять CSS, а потом использовать в следующих своих проектах. Это позволяет не нагружать проект лишними плагинами, гибко менять UI и экономить деньги заказчиков.
- Если нужно завести цикл в цикле на бэке или провести, например, бинарный поиск по огромной базе лекций в LMS — придется изучить логические операции и основы алгоритмов, иначе твое колёсико ожидания запроса будет крутиться овер-долго. А студент напишет, что приложение медленное из-за того, что оно написано на «каком-то конструкторе».
Надеюсь, эти примеры помогут убедить ноукодеров использовать в своих проектах щепотку инженерных знаний, кода и CSS. Это позволит более эффективно решать задачи (экономим время, увеличиваем производительность) , глубоко понимать функционал элементов, происходящую в Bubble магию и самое главное (а чего тут юлить) — увеличить свой чек за разработку приложения.
Заключение
Зачем нужна эта статья? Недавно меня пригласили показать описанное в статье приложение на региональной выставке программистов в городе, где я живу. Многие знакомые кодеры были удивлены, какой продукт можно сделать на ноукоде быстро, недорого и силами одного разработчика, а не команды. Здесь я хотел показать некоторые возможности nocode-решений сообществу, рассказать про преимущества знания ЯП ноукодерам и постараться подружить эти два направления в голове. Надеюсь, данная статья этому поспособствует.
PS. Я считаю, что у хорошего ноукодера есть большое преимущество перед фронтенд или бэкенд-разработчиком — он глубже понимает бизнес-процессы, несет ответственность за работоспособность приложения и напрямую влияет на успех проекта. А ведь сейчас нормальный бизнес старается искать не кодописателей — им нужны разработчики, глубоко погруженные в процессы, понимающие взаимосвязи в функционале. Но многие пока заточены под покраску кнопок) . Сейчас я полностью ухожу в классическую разработку (на то есть экономические причины, готов обсудить их в комментариях) , этапа с кнопками мне не миновать, я это прекрасно осознаю. Но уверен, что в дальнейшем, с карьерным ростом, опыт в Bubble даст конкурентное преимущество при трудоустройстве на middle, senior или руководящие позиции.
а почему забанили в гугле? дыры в бабале?
Честно говоря, даже не знаю. В начале приняли, а через 2 недели приложение отозвали. Дальше этой проблемой PM занимался, я к приложению уже не имел отношения после фикса багов. Хотя вообще, мне кажется что яблочные ребята построже приложения проверяют на безопасность и обмен данных с устройством пользователя)
flutter не проще и дешевле в конечном счете?
через пол года наверно флаттер уже выгоднее будет чем бабблу платить абонентку продолжать.
Вполне возможно, ведь мобильные приложения это не основной профиль Bubble. Насколько я знаю, Flutter Flow вообще поинтереснее с точки зрения разработки аппок для сторов, но я на нем не разрабатывал. Bubble сам клиент выбрал, согласно каких критериев - надо у него уточнять)
Купил специализированный шаблон для проката автомобилей за 50 долларов для вордпресс. Весь учет заявок идет прямо на сайте, можно интегрироватьс с salesforce. Дизайн универсальный, подходит и для настолок и для мобилок. Затраты по времени - 3 дня на набивку базы инвентаря и пару дней на все остальные настройки. Что я делаю не так?
Вы говорите про сайт с адаптивной под мобилки вёрсткой, а в статье речь про мобильное приложение. А вообще, пожалуйста, ваш выбор) Смотрите, что вам нужно по функционалу - если хватает того, что предлагает вордпресс+плагины и устраивает дизайн шаблона, то зачем платить больше и заморачиваться?
Надо ли дальше оплачивать тариф на bubble, после публикации приложения?