Микрофронтенды в Capacitor: белый экран без сети и 4 схемы сборки

Микрофронтенды в Capacitor работают, но схема с сайта переносится не целиком: все модули делят один WebView, один нативный мост и одно хранилище, а сеть в приложении пропадает. Рабочий вариант для бизнеса: собирать модули независимо, но упаковывать в приложение, а загрузку с сервера оставлять только для редких экранов.

Почему схема с сайта ломается на складе, а не в браузере 🧩

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

В браузере на ноутбуке такой схеме ничто не мешает: сеть есть, модуль закэширован, кнопка «назад» принадлежит браузеру. Но Capacitor запускает приложение в WebView внутри нативной оболочки, и каждое из этих допущений перестаёт работать. Поэтому архитектура, которая хорошо показала себя на веб-портале, на устройстве даёт сбои, а тесты на ноутбуке их не ловят.

Ставка простая. Заказ откладывается на вечер, а повторный визит на точку оплачивает компания. Кладовщик, у которого не открылся экран приёмки, дублирует накладную на бумаге. Разработчики тратят дни на ошибку, которая воспроизводится только на одной связке версий оболочки и модуля, а исправление ждёт модерации в сторе.

Пять мест, где WebView меняет правила

Если вы читали предыдущие части цикла, оболочка вам знакома: это нативный проект Capacitor с подключёнными плагинами. Микрофронтенды работают внутри неё и наследуют все её ограничения.

• ✓Сервер модулей должен разрешить запросы из приложения. iOS открывает приложение с origin capacitor://localhost, Android с https://localhost (если вы не меняли androidScheme). Оба адреса нужно разрешить в CORS на сервере, где лежит remoteEntry.js, а в Content-Security-Policy приложения добавить этот сервер в script-src и connect-src.
• ✓Сети может не быть. Локальный бандл открывается в режиме полёта, удалённый модуль нет. Без кэша и запасного экрана пользователь видит белую страницу.
• ✓Мост и плагины общие. Камера, push, биометрия и файловая система подключены в нативной оболочке, а модуль с сервера не добавит плагин, которого в ней нет: для этого нужна пересборка и релиз приложения. Поэтому @capacitor/core и плагины в конфиге федерации объявляют как singleton, иначе два модуля зарегистрируют один плагин дважды, и Capacitor начнёт ругаться в консоль.
• ✓Кнопка «назад» и deep links принадлежат оболочке. На Android жест «назад» приходит событием backButton в плагине App. Если каждый модуль повесит свой обработчик, при одном жесте сработают сразу два: приложение уйдёт на два экрана назад или закроется. Обработчик и appUrlOpen для ссылок из писем и push держит оболочка, а модули получают от неё команды навигации.
• ✓Хранилище одно на всех. localStorage и плагин Preferences делят все модули на одном origin, поэтому ключ token из модуля заказов затрёт одноимённый ключ из модуля склада. Префиксы по имени модуля вводят в первый день, а не после первой потери данных.

Четыре схемы сборки: сравнение для Capacitor 📊

Схемы различаются тем, откуда приложение берёт код модулей и что происходит, когда сети нет.

Первая схема выглядит скучно, но подходит чаще остальных. Ленивая загрузка маршрутов даёт тот же результат, что и микрофронтенд, пока приложение ведёт одна команда: код каталога не тянется на старте, модули лежат в отдельных папках, а границы между ними держат правила импортов.

Вторая схема оправдана там, где сеть есть почти всегда: планшет на проходной, приложение менеджеров в офисе. Для склада, подвала и трассы она рискованна, это ровно сценарий с белым экраном.

Третья схема подходит, когда приложение делают несколько команд и связь нестабильна. Каждая команда собирает свой модуль отдельно, а при сборке приложения файлы модулей копируются в webDir оболочки. Пользователь получает офлайн-работу, команды сохраняют независимость, а платить приходится одним общим релизом в стор. Для обновлений без стора у Capacitor нет встроенного механизма, это делают сторонние плагины live update. Apple разрешает загружать интерпретируемый код, пока он не меняет назначение приложения, но правила площадки, где вы публикуетесь, включая RuStore, и политику MDM заказчика проверяйте до того, как строить на этом процесс.

Четвёртую схему оставляйте для экранов, которые дороже переписать, чем встроить. Сервер страницы должен разрешить встраивание для origin приложения (директива frame-ancestors), а вызовы сканера или камеры из iframe придётся пробрасывать через postMessage в оболочку.

Как собрать гибридную схему по шагам 🛠

Третья схема на практике проходит шесть шагов.

1. ✓Зафиксируйте, что принадлежит оболочке: плагины Capacitor, верхнеуровневый роутер, кнопка «назад», deep links, авторизация и клиент обмена с 1С.
2. ✓Опишите общие зависимости. @capacitor/core, плагины и фреймворк (React, Vue или Angular) объявите singleton с допустимым диапазоном версий, чтобы модули не тянули свои копии. Два фреймворка в одном WebView удваивают рантайм, а на бюджетных телефонах и терминалах сбора данных это видно по времени запуска.
3. ✓Дайте модулю простой контракт: функция mount получает от оболочки токен пользователя, шину событий навигации и обёртки над нативными функциями. Модуль не лезет за токеном в localStorage сам.
4. ✓Соберите модули отдельно и положите результат в webDir оболочки перед npx cap sync. Адреса remotes в конфиге делайте относительными, без http://.
5. ✓Добавьте проверку совместимости. При старте оболочка сверяет версию контракта каждого модуля и показывает понятное сообщение вместо белого экрана.
6. ✓Для модулей, которые должны обновляться без релиза, настройте загрузку с сервера с кэшем и откатом на встроенную версию.

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

Когда микрофронтенды не нужны

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

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

Что делаем мы и сколько это стоит 💼

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

Дальше собираем оболочку с плагинами, единым клиентом обмена с 1С и политикой офлайн-режима, а модули подключаем по контракту. Если у вас уже есть веб-портал, переносим его в Capacitor без переписывания на нативный код. Для торговых представителей, кладовщиков и клиентов, которым нужен доступ к данным 1С, делаем B2B-приложение с 1С.

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

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

Можно ли загружать микрофронтенды в Capacitor-приложение с сервера?

Да, WebView выполняет JavaScript, загруженный по сети, и Module Federation работает. Сервер модулей должен разрешить CORS для origin capacitor://localhost и https://localhost. Но без сети модуль не откроется, поэтому для офлайн-сценариев лучше упаковывать модули в приложение. Правила Apple и Google допускают интерпретируемый код, если он не меняет назначение приложения.

Нужны ли микрофронтенды, если приложение делает одна команда?

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

Как обновлять приложение на Capacitor без релиза в стор?

Встроенного механизма у Capacitor нет. Веб-слой обновляют сторонние плагины live update: приложение скачивает новый бандл и подменяет старый. Обновляться так может только веб-код, а изменения в нативных плагинах требуют нового релиза. Правила площадки, включая RuStore, и политику MDM заказчика проверьте до запуска.

Сколько стоит разработка мобильного приложения на Capacitor с интеграцией 1С?

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

Что выбрать для приложения на 1С: Capacitor или 1С:Мобильную платформу?

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