Enterprise-команды с серьёзными инвестициями в legacy-фронтенд стек сталкиваются с повторяющимся выбором при добавлении AI-фич: переписать, прикрутить сбоку или интегрировать. Два из этих ответов стоят года и бюджета. Третий — тот, что реально доставляется — и паттерны, делающие его рабочим без наследования бардака.
Корпоративным командам, добавляющим AI в legacy-софт, обычно предлагают бинарный выбор — переписать или прикрутить. Оба проигрывают. Переписывания застревают на восемнадцати месяцах, пока legacy-продукт продолжает эволюционировать; Надстройки накапливают свою legacy ко второму году. Третий вариант — стратегическая интеграция через осознанную типизированную границу между legacy host и современными модулями — то, что реально выбирают команды, надёжно выпускающие продукт.
Почти никогда. Переписывания enterprise-продуктов требуют пересборки поведения, годами формировавшегося под запросы клиентов и часто не задокументированного, пока изначальный продукт продолжает эволюционировать. Два таймлайна расходятся, и переписывание редко догоняет. Стратегическая интеграция — сохранить существующую оболочку и подключать современные модули через типизированную границу — реализуется быстрее и служит дольше.
Нет. Транспортный механизм значит меньше, чем интеграционная граница. Module federation — один вариант из нескольких. Паттерн, который стабильно работает — маленький, осознанно спроектированный контракт между host и модулями, независимо от того, federation, single-spa или самописный loader его несёт.
Относитесь к интеграционной границе как к архитектурному решению с назначенным ответственным, а не как к импровизации для каждой функции. Каждый новый модуль интегрируется одинаково. Bundle-гигиена, версионирование и graceful degradation — заботы платформенного уровня, а не отдельных команд. Большинство команд, оказавшихся с bolt-on legacy, попали туда, не назначив ответственного за границу.