Comments 5
Микрофронтенды — однозначное добро...
Сколько я не читал про микросервисы - всё же это для большого бизнеса с тучей серверов и тучей людей? В мелких проектах избыточно?
Да и не всегда понятно, как делить то? Пусть есть Пользователи с правами доступа, и есть Список задач. Не все пользователи должны видеть все задачи. В случае с классического подходом монолита мы в одном месте проверили Авторизацию пользователя, проверили Права и сделали выборку Задач, сгенерировали и отдали страницу.
Как правильно поступить в микросервисном мире? На странице уже 2 компонента. Один должен дождаться другого? А если компонентов 10?
В мелких проектах избыточно?
По моему мнению и опыту - да. Изначально легче и разумнее (опять же - по моему мнению) начать с монолита, чтобы потом при росте его распиливать и реализовывать компонентность. Почему проще? Потому что таким образом мы решаем основные вопросы связанные с общим роутингом, общими стилями всего проекта и т.п. В общем и целом это банально дает нам понять что именно мы хотим отпилить и каким образом это сделать было бы предпочтительнее. Мне кажется, что без монолита сама первопричина изобретения микрофронтендов теряет смысл.
Как правильно поступить в микросервисном мире?
В проектах, где я видел успешное внедрение микрофронтендов все компоненты общались с бекендом через экшены, поведение которых менялось в зависимости от роли пользователя.
Тривиальное решение в лоб - мы получаем куку с id пользователя, проверяем его роль и отдаем ему на фронт только те задачи, которые ему положено видеть. Собственно, Вы практически это же и предложили, только в моем подходе мы данные возвращаем не странице, а компоненту, вот и все
Про "Один должен дождаться другого? А если компонентов 10?" я немного не понял, извините) Компоненты связаны с бекендом или друг с другом, это да, но зачем ради получения информации им дожидаться друг друга, ведь HTTP2 и webpack module federation решает вопросы ленивой загрузки модулей.
Надеюсь, ответил на все Ваши вопросы)
Спасибо за пояснение. А если перейти от микрофронта к микросервисам (маштабирование, все дела). И есть 2 физических сервера Пользователи (с авторизацией, набором прав и пр.) и Задачи (тоже с какими-то параметрами).
Вот при такой ситуации мы загружаем 2 компонента. Задачи ждут инициализации Пользователя, показывая скелет. И только получив данные от Пользователя Задачи достают нужные данные с сервера? Так?
По идее у Вас же уже есть на бекенде вся информация о пользователе, его роли и задачах, которые ему доступны, если я правильно понял) Так пусть и одни и другие идут в бекенд за данными, получают их оттуда и никого не ждут.
Хотя и вариант который Вы предложили реализовать несложно: у нас на страницу загружается компонент с пользователями. Когда он загрузился (fetch успешен), мы в .then() делаем dispatch() события, которое сигнализирует об успешной инициализации компонента и начинаем загрузку компонента с задачами) В целом, да, тоже ок, до этого просто скелет показываем.. но это вроде плохо вяжется с seo
Я чей-то комментарий случайно отклонил, про то, что iframe -это далеко не однозначное добро.. пожалуйста, напиши его снова, я одобрю)
Микрофронтеды: достоинства, недостатки и нюансы