«Хорошая разработка внешнего интерфейса - это непросто. Еще сложнее масштабировать фронтенд-разработку, чтобы несколько команд могли одновременно работать над большим и сложным продуктом ». - Кэм Джексон
Это просто очередная причуда?
Текущей тенденцией в техническом сообществе является создание многофункциональных и мощных SPA, которые обычно основаны на архитектуре микросервисов. Мы видели, что со временем уровень внешнего интерфейса становится массивным, раздутым и дублированным. Часто разные функции поддерживаются разными командами.
Одна кодовая база, несколько команд, работающих над ней, требуют большой координации и могут парализовать команду блокировщиками, бюрократией и десятками встреч по общим стандартам технической команды.
Есть несколько преимуществ автономных команд, которые мы видели в разных отраслях, в нашей конкретной отрасли, мы видели, что автономия ведет к нестандартному мышлению, тривиальным решениям сложных проблем и повышению удовлетворенности работой - если все сделано правильно.
Подход с использованием микро-пользовательского интерфейса или микро-интерфейса направлен на то, чтобы вернуть командам автономию таким образом, чтобы они могли полностью контролировать свои функции или продукты без необходимости согласовывать конкретные детали, которые могут быть решены в каждой команде или отряде.
Основные идеи, лежащие в основе Micro-UI
Будьте независимы от технологий
Каждая команда должна иметь возможность выбирать и обновлять свой стек без необходимости согласовывать действия с другими командами. Это позволяет техническим командам быстрее масштабироваться с помощью технологически независимого подхода. Веб-компоненты - отличный способ предоставить другим пользователям нейтральный интерфейс.
Например
<notification-bell>{notificationCount}</notification-bell>
vs
<div class=”notification-bell”>{notificationCount}</div>
Изолировать код команды
Если все команды используют один и тот же стек технологий, стандарты и т. Д. Не используют одну и ту же среду выполнения. Создавайте независимые и самодостаточные приложения, не полагающиеся на конкретное общее состояние или глобальные переменные, однако есть исключения, о которых я упомяну позже.
Создайте устойчивый сайт
Не все браузеры одинаковы, каждый из них использует JavaScript по-разному, и многие функции поддерживаются не всеми браузерами. Старайтесь изо всех сил использовать API, которые есть во всех браузерах, в противном случае используйте polyfill для реализации этих API в браузерах, которые их не поддерживают.
Используйте универсальную технику рендеринга (SSR / SSG / Pre-рендеринг) и прогрессивное улучшение (выделение в первую очередь основного содержимого веб-страницы) для улучшения воспринимаемой производительности. Далее в статье я расскажу о нескольких стратегиях повышения производительности.
Как это выглядит?
С точки зрения разработки мы видим отдельные приложения, которые запускаются и строятся независимо, у них могут быть разные технологические стеки, но конечным результатом является веб-приложение или веб-сайт, который работает в вашем браузере и ведет себя так, как было определено.
С точки зрения пользователей, они видят одно веб-приложение, которое связывает различные микро-пользовательские интерфейсы или перемещается по ним, однако они не видят и не замечают этого (или не должны).
У каждого микро-пользовательского интерфейса есть собственный исходный код, содержащийся где-то в репо (в идеале). Каждый из этих проектов создается и тестируется в отдельном конвейере, и как только это делается, они развертываются где-нибудь в Интернете. Наконец, мы начинаем связывать все эти продукты или функции в одно приложение. Мы можем добиться этого, используя различные методы маршрутизации с помощью маршрута 53, nginx, ingress и т. Д.
Общий источник и логика
Чаще всего мы хотели бы поделиться с этими различными приложениями стилями и, возможно, несколькими вспомогательными функциями, которые обычно используются в ваших приложениях (например, синтаксическим анализом токенов-носителей).
Обычно используется метод создания отдельных библиотек NPM и втягивания их в каждый из ваших микро-пользовательских интерфейсов. Они должны быть спроектированы таким образом, чтобы их клиент (микро-пользовательский интерфейс) мог распространяться на эти общие компоненты, чтобы, если требуется различная тематика, отступы и т. Д., Это было легко сделать.
Во многих случаях микро-пользовательскому интерфейсу потребуется состояние аутентификации, простой способ сделать это - сохранить ваши токены аутентификации в LocalStorage, который работает во всем домене. Это используется, если вы собираетесь использовать предварительно отрисованный подход прогрессивного улучшения. У всех нас есть метод cookie, который вам понадобится, если вы собираетесь использовать подход с рендерингом на стороне сервера (SSR).
Совместное использование состояния аутентификации - это только один пример, вы можете поделиться несколькими битами состояния, но, пожалуйста, будьте осторожны, так как это потенциально может раскрыть конфиденциальную информацию.
Техники исполнения
Самая большая проблема, с которой вы можете столкнуться, - это загрузка больших пакетов скомпилированного кода. Есть несколько способов повысить производительность при загрузке нескольких пакетов, и я рассмотрю некоторые из них.
Используйте сеть доставки контента для статических объектов
Использование CDN позволит быстрее загружать все ваши ресурсы, так как большинство CDN будут знать, откуда пользователь запрашивает контент. Помимо производительности, это снизит вашу полосу пропускания и затраты на инфраструктуру.
«Предварительный просмотр»
Что, если ваш браузер предвидит запросы, которые понадобятся пользователю? Ну, вы определенно можете проинструктировать его об этом. Вкратце, предварительный просмотр сообщит браузеру, что нужно извлечь и кэшировать ресурс в браузере вашего пользователя во время просмотра. Существует несколько API предварительного просмотра, я расскажу о двух, которые наиболее актуальны для нашей проблемы.
- Предварительное подключение
Мы хотим, чтобы определенный контент загружался как можно раньше, прежде чем HTTP-запрос будет фактически отправлен на сервер. Preconnect разрешает DNS, а также устанавливает связь TCP, и, если требуется TLS, он также выполняет согласование. Preconnect может уменьшить задержку запроса на несколько сотен миллисекунд, а иногда даже на тысячи.<link rel="preconnect" href="(url)"> - Предварительная выборка
Мы знаем, что в будущем мы будем загружать определенные микро-пользовательские интерфейсы, поэтому мы можем попросить браузер получить этот ресурс тем временем и сохранить его в кеше для дальнейшего использования. Например, вы можете загрузить изображение с предварительной выборкой, вы можете загрузить любой ресурс, кэшируемый вашим браузером.<link rel="preconnect" href="(url)">
Миграционный подход
Если вы хотите начать перенос монолита внешнего интерфейса в более удобные в обслуживании и отдельные приложения с микро-пользовательским интерфейсом, вы можете начать немедленно. Для начала я рекомендую вам определить, какие части вашего приложения должны быть разделены, например, ваш модуль авторизации или входа в систему. Таким образом, вы можете начать перенос модулей изолированно, пока они все еще используются в монолите.
Для каждой новой функции, которую необходимо встроить в свое приложение, я предлагаю немедленно создавать для них микро-пользовательский интерфейс, примером может служить новый блог.
После того, как все модули будут перенесены с использованием этого подхода, в его основе, по сути, будет приложение маршрутизации.
TL; DR;
В заключение, используя архитектурный подход, основанный на микро-пользовательском интерфейсе, вы получите несколько преимуществ. К ним относятся настоящая автономия команды или отряда, меньшее количество точек отказа - если появится критическая ошибка, все ваше приложение может не упасть, что дает нам изолированную среду, аналогичную той, которую мы видели в архитектуре микросервисов. Это только верхушка айсберга, когда речь идет об архитектуре микро-пользовательского интерфейса или микро-интерфейса. Обязательно задавайте вопросы или оставляйте свои мысли в разделе комментариев!
