Бэкенд на Dart для Flutter-приложения с 1С: что даёт Fletch, а что нет

Бэкенд на Dart, например на Fletch, оправдан для Flutter-приложения, когда клиент и сервер делят модели данных и бизнес-правила: их пишут один раз в общем пакете. Экономия кончается там, где начинаются база, авторизация, деплой и интеграция с 1С: эти задачи от языка не зависят. Для малого бизнеса выигрыш в одной команде и меньшем числе багов на стыке.

📦 что делят Flutter и сервер на Dart

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

что идёт в общий пакет

• ✓модели заказа, контрагента и номенклатуры вместе с сериализацией в JSON: переименовали поле один раз, и компилятор показывает все места, где оно используется, и в приложении, и на сервере;
• ✓правила расчёта: скидки по соглашению, округление, минимальная партия, НДС в строке заказа;
• ✓валидация: ИНН из 10 или 12 цифр, формат телефона, обязательные поля;
• ✓коды ошибок API, чтобы приложение показывало понятный текст, а не «ошибка 500».

Общими бывают и тесты. Набор проверок расчёта скидок один, он прогоняется и для приложения, и для сервера. Классический баг без него: сумма заказа на телефоне расходится с суммой в 1С на копейки из-за разного округления, и менеджер полдня ищет, куда делась копейка. С общим пакетом расхождение всплывает красным тестом на сборке.

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

что в общий пакет не попадёт

Всё, что тянет за собой Flutter SDK или dart:ui: виджеты, управление состоянием, плагины камеры и push-уведомлений. Сервер такой код не соберёт. Поэтому общий пакет делают отдельным модулем, а приложение, сервер и этот модуль держат в одном монорепозитории: Dart поддерживает pub workspaces, и изменение модели приходит в обе части одним коммитом.

🔥 пятница, 18:40: сервер упал, а чинить его некому

Типичная история. Оптовая компания заказывает Flutter-приложение для торговых представителей. Разработчик хорошо знает Dart и берёт серверную часть на себя: язык тот же, значит, справится. Первые недели всё работает: заказы уходят, остатки подтягиваются.

Но в пятницу в 18:40 процесс сервера падает. Логов нет: на тестовом стенде они шли в консоль, и никто не настроил запись в файл. Резервные копии базы никто не проверял. Перезапустить сервис по SSH умеет только сам разработчик, а он в отпуске. Поэтому представители оформляют заказы на бумаге и в мессенджере, а в понедельник менеджеры вбивают их в 1С руками.

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

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

⚖️ Fletch, Node.js или прямые вызовы 1С: сравнение

Для приложения, которое работает с 1С, мы сравниваем три реальных варианта.

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

Третий вариант кажется самым дешёвым, но за него платит база 1С. Запросы с телефонов падают на неё напрямую, без кеша и очереди, а в день закрытия месяца бухгалтерия нагружает ту же базу сама. Поэтому для рабочего приложения мы ставим между телефоном и 1С отдельный сервер. На каком языке его писать, решаем по команде и по задаче.

Четвёртого варианта, зарубежного облачного сервиса с готовым бэкендом, в таблице нет сознательно. Если приложение собирает персональные данные граждан РФ, 152-ФЗ (часть 5 статьи 18) требует хранить их в базах на территории России. Вопрос закрывается сервером в российском дата-центре.

🔍 пять проверок Fletch до продакшена

Фреймворк, на котором будет жить продакшен, мы проверяем до первой строки кода, как любую зависимость. Список подходит для любого серверного пакета на Dart.

1. ✓Дата последнего релиза и активность репозитория: свежие коммиты, ответы на issue. Если релиз вышел давно, а Dart SDK с тех пор ушёл вперёд, это повод для вопросов.
2. ✓Совместимость с текущей версией Dart SDK и с нужными пакетами: драйвер PostgreSQL, JWT, клиент для S3-совместимого хранилища.
3. ✓Лицензия: она должна разрешать коммерческое использование без требования открывать код заказчика.
4. ✓Нагрузочный прогон на ваших сценариях: загрузка каталога, всплеск заказов после обеда. Демо из README ничего не доказывает.
5. ✓Запасной выход. Модели и бизнес-логика лежат в общем пакете и ничего не знают о фреймворке. Тогда замена Fletch на Shelf (каркас от команды Dart) или Dart Frog означает переписывание маршрутов, а не всего сервера.

Если проверки пройдены, у Dart остаётся плюс на деплое: сервер собирается в один исполняемый файл командой dart compile exe, и Dart SDK на боевой машине не нужен.

🔗 серверный слой между приложением и 1С

1С остаётся источником правды: номенклатура, цены, остатки, взаиморасчёты. Приложение напрямую туда не ходит. Между ними стоит сервер, и на Dart он решает те же задачи, что и на любом другом языке:

• ✓хранит кеш каталога и остатков, поэтому открытие каталога не дёргает базу 1С при каждом свайпе;
• ✓принимает заказ в очередь и передаёт в 1С, когда она доступна: если база занята закрытием месяца или обновлением, заказ не пропадает;
• ✓проверяет права: торговый представитель видит только своих контрагентов;
• ✓собирает данные под экран, так что один запрос заменяет пять обращений к HTTP-сервисам 1С;
• ✓отдаёт изменения с момента последней синхронизации, чтобы приложение работало на складе без связи и догоняло данные, когда сеть вернулась.

Как устроена такая связка, собрано на странице про интеграцию мобильного приложения с 1С. Если приложением пользуются клиенты и представители, а склад и бухгалтерия остаются в 1С, смотрите разбор B2B-приложения с 1С.

🚫 когда Dart на сервере брать не стоит

Есть три случая, когда мы советуем другой путь.

• ✓В приложении почти нет общей логики, зато много внешних интеграций: платёжные шлюзы, СМС, облачные хранилища. Для Node.js или Python готовых проверенных библиотек больше, и подключение идёт быстрее.
• ✓Сервер потом будет поддерживать команда заказчика, у которой уже есть разработчики на другом языке. Редкий стек повышает риск остаться без поддержки, когда уйдёт единственный человек, знающий Dart.
• ✓Задача узкая и внутренняя: склад, инвентаризация, выездной сервис. Тогда отдельный бэкенд не нужен, хватает приложения на 1С:Мобильной платформе.

🛠 как мы ведём такой проект и что он стоит

Разработка мобильных приложений у нас начинается от 500 000 ₽. Итог зависит от числа экранов, ролей пользователей и объёма обмена с 1С, поэтому смету мы считаем после разбора процессов, а не по шаблону. Общие ориентиры по ценам есть на странице цены и тарифы. Приложение, серверный слой и интеграцию с 1С делает одна команда: за стык между ними отвечает один подрядчик, а не три.

1. ✓Разбираем процесс: кто что делает в приложении, какие данные берутся из 1С, что должно работать без связи.
2. ✓Описываем контракт API и общий пакет моделей раньше, чем рисуем экраны.
3. ✓Поднимаем сервер и тестовый контур с 1С. Логи, резервные копии и мониторинг настраиваем на первом этапе, а не перед релизом.
4. ✓Выбираем фреймворк по пяти проверкам выше: Fletch проходит, берём его; не проходит, берём Shelf или Dart Frog, а архитектура остаётся прежней.

В любом договоре на такую разработку, у нас или у другого подрядчика, прописывайте передачу исходников, инструкции по развёртыванию и доступов к серверу. Это страховка от пятницы 18:40.

❓ Частые вопросы

Можно ли написать бэкенд для Flutter-приложения на Dart?

Да. Dart работает на сервере: код собирается в один исполняемый файл командой dart compile exe, а маршруты берут на себя каркасы вроде Shelf, Dart Frog или Fletch. Главная выгода в общем пакете моделей и правил для приложения и сервера. Минус: библиотек и разработчиков меньше, чем у Node.js или Go.

Сколько стоит разработка мобильного приложения на Flutter с серверной частью?

Разработка мобильных приложений у нас начинается от 500 000 ₽. Итог зависит от числа экранов, ролей пользователей и объёма обмена данными с 1С. Серверную часть и интеграцию считаем в той же смете. Точную сумму называем после разбора процессов: без описания задач любая цифра будет угадыванием.

Зачем нужен серверный слой между мобильным приложением и 1С?

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

Можно ли хранить данные пользователей приложения в зарубежном облаке?

Если приложение собирает персональные данные граждан РФ, 152-ФЗ требует записывать и хранить их в базах на территории России. Поэтому сервер и базу размещают в российском дата-центре. Зарубежный облачный сервис допустим для данных без персональных сведений. Детали для вашего случая лучше уточнить у юриста.

Что делать, если Fletch перестанет развиваться?

Заранее держите модели и бизнес-логику в общем Dart-пакете, который не зависит от фреймворка. Тогда замена Fletch на Shelf или Dart Frog означает переписывание маршрутов, а не всего сервера. Сам сервер при этом продолжает работать. До выбора проверьте дату последнего релиза, совместимость с текущим Dart SDK и лицензию.