CSI, SSI, ESI в композиции микрофронтендов
2 года назад·1 мин. на чтение
Что такое Client Side Include, Server Side Include и Edge Side Include?
Client Side Include - CSI (Включение на стороне клиента)
Client Side Include (CSI) является довольно знакомой для фронтенд-разработчиков возможностью, в основном это вызов Ajax. Что выделяет его, так это контент, который возвращает запрос. Тип контента -html/text, похожий на обычный HTML, который мы используем. В этом контексте мы не запрашиваем фрагмент данных, вместо этого мы ожидаем фрагмент HTML.
Реализация CSI не нова, CSI используется еще с 2000 года. Проблема CSI заключается в том, что если вы используете этот подход слишком интенсивно, пользователь сайта может ждать контента во время загрузки сайта. Это означает, что поисковая система может быть не в состоянии проиндексировать нужный контент при первой загрузке. По этой причине рекомендуется использовать этот подход только для определенных элементов, таких как счетчик, футер или что-либо, что не привлекает основное внимание пользователя и не находится в верхней части экрана.<body> Hello World <footer> <h-include src="a server address"></h-include> </footer> </body>
Server Side Include - SSI (Включение на стороне сервера)
Как видно из названия, включение на стороне сервера (SSI) не происходит на компьютере клиента.Вместо этого, когда сервер анализирует HTML-файл, он проверяет определенные строки, помеченные<body> Hello World <!--#include virtual="/..." --> </body>
#include. Для любых найденных включений он извлечет содержимое и вставит его в это место, прежде чем вернуть окончательный документ.
Преимущество SSI заключается в том, что, как правило, серверы работают быстрее по сравнению с клиентским компьютером. Не говоря уже о том, что количество запросов между клиентами и серверами сокращается до 1. Таким образом, обычно мы можем получить время отклика около 1 мс по сравнению с временем отклика 50 мс при вызове API.
При этом не стоит злоупотреблять использованием большого количества включений на одной страницу. Для каждого включения серверу необходимо выполнить несколько вызовов и дождаться завершения всех вызовов, прежде чем он сможет агрегировать файл. Это может занять больше времени, чем вы ожидаете, не говоря уже о том, что один из вызовов может завершиться сбоем. Таким образом время отклика может вырасти до 500 мс и больше. Любое время, выходящее за рамки 1 сек, может стать критичным для продакшен сервера.
Поэтому разумно использовать SSI только для основного содержимого страницы, а не для каждого декоративного элемента (например счетчик или футер и т.д.). Также можно попробовать комбинировать CSI и SSI.
SSI также не новая технология. Во времена, когда существовали только бэкенд-разработчики, каждый фрагмент HTML-шаблона, собранный на сервере, можно было назвать SSI.
Edge Side Include - ESI
Идея включения на Edge Side (на стороне CDN), была предложена еще в 2001 году, но с тех пор она так и не стала общепринятой. Тем не менее, она может решить проблемы SSI. Имейте в виду, что ESI происходит и на сервере.С точки зрения использования, это не слишком отличается от включения SSI. Считается, что в некоторых реализациях ESI это улучшает время до первого байта (TTFB). Потому что он может сначала вернуть доступный документ, прежде чем все включения будут скачаны и возвращены. Это похоже на комбинацию CSI и SSI, за исключением того, что все обрабатывается на сервере.<body> Hello World <esi:include src="a server address" /> </body>
Итоги
Существует множество подходов для реализации микрофронтендов, в том числе CSI, SSI и ESI. Эти подходы могут казаться запутанными, отчасти потому, что разработчики использовали их, не зная терминологии.Подробное руководство по микрофронтенд архитектуре
2 года назад·2 мин. на чтение
Микрофронтенд становится популярной архитектурой, компании растут, появляется необходимость масштабировать команды.
Микрофронтенд - это архитектура, которая позволяет масштабироваться, делать команды независимыми и больше ориентироваться на бизнес потребности.
Мы начинаем большую и подробную серию видео о микрофронтенд архитектуре на Boosty с ранним доступом. Некоторые темы будут эксклюзивно доступны только на Boosty по подписке. Мы будем читать и обсуждать книгу “Building Micro-Frontends. Scaling Teams and Projects, Empowering Developers”. Книга не переведена на русский язык. В этих видео мы будем обсуждать самую суть книги, без воды. Также я буду давать свои комментарии, основываясь на своем опыте внедрения микрофронтендов в большом проекте.
В этих видео будет дано большое количество полезной информации по всем аспектам распиливания монолита на микрофронтенды. Мы рассмотрим большое количество вариантов внедрения микрофронтенд архитектуры, рассмотрим все достоинства и недостатки вариантов, сложности перехода на микрофронтенд архитектуру и что стоит учесть заранее. Также коснемся принципов Domain Driven Design (DDD) и как эти принципы связаны с микрофронтендами.
Рассмотрим следующие темы:
- Как распилить монолит на микрофронтенды
- Архитектуры фронтенд приложений - SPA, Изоморфные, Статичные, JAMstack
- Что такое микрофронтенд и каковы его принципы
- Что учитывать при переходе на микрофронтенд
- Краткий обзор видов разделения на микрофронтенды
- Вертикальное разделение на микрофронтенды
- Горизонтальное разделение на микрофронтенды
- Микрофронтенд на основе Module Federation
- Микрофронтенд на основе iframes
- Микрофронтенд на основе веб-компонентов
- Server Side микрофронтенды
- Edge Side микрофронтенды
- Проект с Webpack Module Federation
- Эволюция проекта с Webpack Module Federation
- Как деплоить микрофронтенды
- Как версионировать микрофронтенды
- CI/CD микрофронтендов
- Стратегии деплоя микрофронтендов
- Пример автоматизации пайплайна для микрофронтенда
- Общение микрофронтендов с бекендом
- Пример распиливания монолита на микрофронтенды. О приложении
- Пример распиливания монолита на микрофронтенды. Детали реализации
- Как презентовать микрофронтенд архитектуру команде
