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