FlutterFlow: обзор low-code платформы, возможности, плюсы и ограничения

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

На этом фоне no-code и low-code платформы выглядели как спасение: быстро, дёшево и «почти без кода». FlutterFlow стал одним из самых заметных представителей этого тренда, особенно среди стартапов и не технических команд.

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

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

Помимо стандартных кнопок и карточек, система позволяет легко внедрять графику и анимации (например, Rive и Lottie), что вместе с множеством других заготовок позволяет быстро собрать практически любую популярную функцию приложения без необходимости глубокого погружения в технические детали.

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

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

Работа с данными и API

Для работы с данными FlutterFlow предлагает как встроенные, так и внешние решения. Платформа поддерживает прямую интеграцию с Firebase Firestore и Supabase в качестве BaaS (Backend as a Service) — готового облачного бэкенда, который берёт на себя хранение данных, аутентификацию пользователей, работу с базой данных и серверную логику без необходимости писать и поддерживать собственный сервер. 

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

Готовые интеграции и сторонние сервисы

Экосистема платформы расширяется за счёт готовых подключений к популярным внешним сервисам. Это включает интеграции для платежей и монетизации (Stripe, RevenueCat и др.), сервисы аналитики, а также возможность встраивать любую стороннюю логику через написание собственных действий (actions) на Dart.

Функциональность приложения

FlutterFlow позволяет настраивать ключевую функциональность приложения без кода. Это включает в себя проектирование навигации с маршрутами, переходами и обработкой deeplink-схем, визуальное построение бизнес-логики через систему действий и блок-схем, а также настройку push-уведомлений через интеграцию с Firebase Cloud Messaging.

Платформенные фичи

Платформа использует возможности фреймворка Flutter, который изначально ориентирован на кроссплатформенную разработку и позволяет собирать приложения для iOS, Android и Web из одного кодового проекта. FlutterFlow, по сути, не нарушает эту модель, а лишь предоставляет визуальный интерфейс для работы с ней.

Также доступно тестирование в реальном времени прямо в браузере или на подключённом мобильном устройстве. На момент написания статьи поддержка десктопных платформ (Windows, macOS, Linux) находится в альфа-статусе и может быть нестабильна.

Контроль версий и исходники

Для командной работы и контроля качества FlutterFlow предоставляет инструменты для совместной разработки: систему комментариев, встроенный контроль версий и возможность просмотра истории изменений. Ключевой особенностью является возможность экспорта всего проекта в чистый, читаемый код на Flutter (Dart), что открывает путь для дальнейшей ручной разработки в любой IDE.

Деплой и публикация

Платформа значительно упрощает процесс развертывания и публикации приложения. Прямо из веб-интерфейса можно генерировать production-билды для всех платформ, автоматически размещать web-версию на Firebase Hosting, а также готовить пакеты для публикации в App Store и Google Play через встроенные пайплайны. Для продвинутых сценариев доступен экспорт исходного кода для интеграции в собственные процессы CI/CD и автоматизация доставки через подключение к GitHub.

Архитектура приложений на FlutterFlow

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

Создание приложения с помощью low-code решения может быть уместно в случае POC (Proof Of Concept) или простенького MVP, но как только дело доходит до чего-то большего и комплексного, шанс упереться в проблемы и ограничения довольно высок. 

Стоит отметить, что после выхода за рамки платформы поддержка может вызывать немалые затруднения, так как проект сам по себе сильно завязан на low-code подходе и многим разработчикам может быть трудно ориентироваться в подобном коде и проводить отладку.

Подход организации компонентов FlutterFlow приложения можно описать как компонентно-ориентированную архитектуру с элементами MVVM (Model-View-ViewModel), однако в упрощенном виде. 

Структура виджетов и Action Flow

Разделения на слои Data, Domain, Presentation/UI как такового нет, а каждый виджет строится в связке из двух классов – класс модели (логика и локальное состояние) и класс самого виджета (интерфейс). 

Основной единицей здесь является именно визуальный компонент и его действия, а не фича или модуль. Для описания логики виджета применяется цепочка действий (Action Flow) с императивным подходом, которая создает последовательность выполнения блоков кода.

С одной стороны, выстраивать ее просто, но отладка и расширение или изменение логики может даться тяжело:

• Цепочка действий позволяет содержать в себе навигацию, обновление состояния, вызовов API и логику отображения UI, что уже усложняет отладку отдельного участка логики.
   
• Изменение существующих или добавление новых блоков логики может потребовать изменения и адаптации всей цепочки действий, а при сложной бизнес-логике с множеством ветвлений все превращается в сложно читаемый код.
   
• При необходимости переиспользовать код придется либо копипастить, либо выносить логику в отдельные блоки, но и они не такие гибкие, чтобы избавить от лишних изменений в будущем.
   
• Местами нет единого источника данных, так как данные запрашиваются в нескольких виджетах, а бизнес-логика раскидана по разным кнопкам и триггерам

Стейт менеджмент

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

Эта реализация имеет ряд минусов:

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

Связь с данными и сервисами

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

• Данные из API (например, Firebase или Supabase) запрашиваются напрямую из виджетов, создавая запросы к базе данных, например, в инициализации виджета. В некоторых случаях проекты могут потребовать Domain слой или репозитории, которые FlutterFlow опускает.

• FlutterFlow создает кастомные классы-обертки, которые используются как в UI, так и в логике.
• Сервисы зачастую существуют в проекте как синглтоны, что убивает возможность свободного тестирования бизнес-логики.
• Вызов сервисов напрямую приводит к отсутствию инверсии зависимостей, добавляя сложность к расширению проекта и уменьшая его гибкость

Чем ограничена архитектура приложений на FlutterFlow?

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

No-code и low-code решения показывают неплохие показатели на этапе MVP, но при развитии продукта и переходе к долгосрочной эксплуатации важно заранее планировать не только эволюцию архитектуры, но и возможную миграцию с самой платформы FlutterFlow на более гибкий и контролируемый стек. Без этого ограничения инструмента могут со временем стать критичными.

Опыт LighTech

В истории нашей компании примером такого  «смешанного» проекта является приложение Spirit Up, которое изначально создавалось с помощью FlutterFlow, но позже перешло на этап разработки на Dart и работу непосредственно с кодовой базой. 

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

Переписывать уже выстроенную структуру не маленького проекта — затратное по времени, трудное и дорогое занятие, которое явно никому не нужно в контексте уже опубликованного приложения. Хоть это и не делает проект невозможным для развития, оно превращает разработку в процесс постоянного преодоления препятствий.