Избыточный код отправляется по трубке с микро-интерфейсами

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

Здесь ключевой проблемой, которая решается, является способность нескольких команд работать независимо и при этом иметь возможность создавать большой композит. Проблема НЕ в том, чтобы иметь конечный пользовательский пакет . Это понимание правильно?

Правда ли, что если у нас есть несколько небольших приложений, используемых для создания большого веб-приложения, мы могли бы потенциально иметь несколько небольших приложений, отправляющих одну и ту же библиотеку Javascript ( например, Lodash ) в браузеры конечных пользователей как часть их отдельные пакеты поставщиков, приводящие к некоторому количеству дублирующего / избыточного кода, отправляемого пользователю?

Разве это не проблема, о которой нам следует беспокоиться при разработке интерфейсного приложения?

Вы абсолютно правы в том, что здесь есть компромисс: вы торгуете некоторыми аспектами пользовательского опыта, чтобы получить лучший опыт разработчика (что, в свою очередь, может улучшить пользовательский опыт различными способами). Это того стоит? По-разному.

Например, я думаю, что Spotify использует этот подход, чтобы разделить их пользовательский интерфейс на изолированные компоненты ( источник ). Каждый виджет живет в iframe и поэтому может иметь свой собственный набор библиотек и т. Д. У них есть уникальное организационное ограничение, что работа выполняется автономными отрядами (межфункциональная группа). Это усложняет согласование стандартов для всей компании и последующее изменение этих стандартов. Поэтому для них микро-интерфейс помогает сохранить некоторую гибкость. Но без этого подхода, возможно, их настольное приложение было бы не слишком сложным занятием памяти.

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

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

• Вы очень большая организация с высоко автономными командами, которые все работают над пользовательским интерфейсом и должны делать очень частые выпуски (например, ежедневно) и
• в вашем бюджете производительности UX есть место для этого дублирования, или ваш продукт настолько хорош, что UX не имеет значения. Обратите внимание, что производительность следует тестировать на младших устройствах, а не на компьютере разработчика.

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

Микро-интерфейсы кажутся одной из тех вещей, которые действительно круты, но вам они не нужны, пока вы не работаете в масштабе.