Как управлять состоянием и связью между микрофронтендами

Чтобы фронтенд работал как единый пользовательский интерфейс, нужно настроить коммуникацию между микрофронтендами.

Допустим, пользователь зашёл на домашнюю страницу онлайн-магазина «Шайба». Он листает каталог и добавляет товар в корзину. На это событие должны отреагировать разные части приложения.

Каталог должен сообщить корзине, что в неё добавили товар. Корзина должна посчитать стоимость покупки и отобразить её. Для этого ей нужно сходить в личный кабинет и проверить авторизацию пользователя. Если пользователь авторизован — узнать, есть ли у него бонусы, которые можно списать при оплате.

Если корзина не получит нужные данные, пользователь не сможет оформить заказ и компания потеряет прибыль.

В этом уроке поговорим, как избежать такой ситуации. Разберём разные стратегии управления состоянием и покажем примеры их реализации.

Стратегии управления состоянием

Чтобы управлять состоянием и коммуникациями между микрофронтендами, можно использовать три стратегии:

взаимодействие на основе API,
паттерн Pub/Sub,
библиотека глобального состояния.

Рассмотрим все стратегии по порядку.

Взаимодействие на основе API

Иногда проще позволить микрофронтендам общаться через внутренние API, а не напрямую друг с другом. В этом случае тоже можно сохранить независимость компонентов.

Коммуникация на основе API подразумевает, что бэкенд и микрофронтенды взаимодействуют через HTTP-запросы. Для обмена данными используют RESTful или GraphQL API.

Когда использовать взаимодействие на основе API

Эта стратегия подойдёт, если в проекте:

Микрофронтенды должны взаимодействовать с бэкендом, а не напрямую друг с другом. В таких случаях микрофронтенды в основном занимаются получением или обновлением данных из централизованного бэкенда.
Простой обмен данными. Если у приложения простые коммуникационные потребности, лучше реализовать API. Это будет и проще, и эффективнее. Например, вы передаёте данные, только чтобы отобразить их в компоненте или отправить форму. В этом случае настроить RESTful API и GraphQL будет проще, чем настроить глобальное состояние или систему Pub/Sub.
Высокие требования к производительности и масштабируемости. Вам нужно обеспечить независимое масштабирование и оптимальную производительность каждого микрофронтенда. Взаимодействие на основе API позволит каждому фронтенду самостоятельно получать данные и обновлять своё состояние.

🔹 Примеры использования

Системы управления контентом (CMS). Разные разделы сайта — например, статьи, комментарии пользователей и медиагалереи — независимо получают и обновляют контент через RESTful API или GraphQL.
Одностраничные приложения (SPA). Микрофронтенды получают данные о конкретном пользователе из бэкенд-сервисов — например, информацию о профиле, настройках или истории транзакций.

Сергей

Пример кода

Итак, в приложении три микрофронтенда и три микросервиса. Микрофронтенды общаются только с бэкенд-сервисами, между ними нет прямой коммуникации.

Схема взаимодействия выглядит так:

Посмотрим, как это можно реализовать в коде.

Вот файл списка товаров:

JSX
// Получаем список товаров непосредственно из бэкенда
export const fetchProducts = async () => {
  const response = await fetch('/api/products');
  return response.json();
};

// Список товаров (React)
import React, { useEffect, useState } from 'react';
import { fetchProducts } from './ProductService';

const ProductList = () => {
  const [products, setProducts] = useState([]);

  useEffect(() => {
    fetchProducts().then(setProducts);
  }, []);

  return (
    <div>
      {products.map(product => (
        <div key={product.id}>{product.name}</div>
      ))}
    </div>
  );
};

export default ProductList;
 

Корзина:

JSX
// Сервис корзины. Получаем данные непосредственно из бэкенда
export const fetchCartItems = async () => {
  const response = await fetch('/api/cart');
  return response.json();
};

// Корзина (Vue)
<template>
  <div>
    <div v-for="item in cartItems" :key="item.id">{{ item.name }}</div>
  </div>
</template>

<script>
import { fetchCartItems } from './CartService';

export default {
  data() {
    return {
      cartItems: []
    };
  },
  created() {
    fetchCartItems().then(data => {
      this.cartItems = data;
    });
  }
};
</script> 

Профиль пользователя:

JSX
// UserService.ts
import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class UserService {
  constructor(private http: HttpClient) {}

  getUserProfile() {
    return this.http.get('/api/user/profile');
  }
}

// UserProfileComponent.ts
import { Component, OnInit } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-user-profile',
  template: `<div *ngIf="user">{{ user.name }}</div>`
})
export class UserProfileComponent implements OnInit {
  user: any;

  constructor(private userService: UserService) {}

  ngOnInit() {
    this.userService.getUserProfile().subscribe(data => {
      this.user = data;
    });
  }
} 

Взаимодействие через API просто реализовать. Но эта стратегия не подойдёт, если вам нужно реактивно обновлять компоненты одного микрофронтенда в ответ на изменение данных в другом. Для этого придётся либо делать регулярные запросы к бэкенду или использовать технологии вроде Websocket. А это уже ближе к паттерну Pub/Sub.

Задание 1

Какое из утверждений правильно описывает использование API для управления состоянием?

API обеспечивает синхронное взаимодействие между компонентами и сервером

API позволяет компонентам изменять состояние других компонентов напрямую

API используется для обмена данными и синхронизации состояния между клиентом и сервером

Всё так! API позволяет поддерживать согласованное состояние приложения.

API автоматически управляет всеми зависимостями и версиями библиотек

Паттерн Pub/Sub

✏️ Паттерн Pub/Sub — это паттерн проектирования, при котором компоненты системы выступают в роли издателей (publisher) или подписчиков (subscriber).

При таком подходе компоненты не знают о существовании друг друга. Они взаимодействуют только с событиями — публикуют их или подписываются на них.

Паттерн Pub/Sub можно реализовать с помощью разных технологий. Одна из них — это шина событий.

Event Bus (шина событий) — это система обмена сообщениями, которая основана на паттерне Pub/Sub. События публикуют в шине событий. Компоненты-подписчики регистрируются в шине и указывают список событий, которые они хотят получать.

Шина событий разделяет микрофронтенды, убирает взаимозависимость и обеспечивает гибкость.

Когда использовать паттерн Pub/Sub

Эта стратегия подойдёт, если в проекте:

Предпочтительно несвязанное соединение. Используйте системы Pub/Sub, когда вам нужно несвязанное взаимодействие между микрофронтендами. Такой подход позволяет компонентам взаимодействовать без прямых зависимостей. Это упрощает добавление, удаление или обновление микрофронтендов.
Архитектура, управляемая событиями (event-driven architecture, EDA). При такой архитектуре действия или обновления в одной части приложения вызывают реакции в других частях. Паттерн Pub/Sub идеально подходит таким приложениям. Он эффективен для обновлений в реальном времени и асинхронных коммуникаций.
Независимое развёртывание. Ваши микрофронтенды должны разворачиваться независимо друг от друга. Паттерн Pub/Sub помогает отделить логику взаимодействия от фактической реализации.

🔹 Примеры использования

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

Сергей

Пример кода

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

Чтобы обеспечить коммуникацию между виджетами, можно реализовать простую шину событий. Из технологий хорошо подойдут встроенные возможности JavaScript по обработке событий или библиотека EventEmitter от Node.js.

Так выглядит файл с шиной событий — EventBus.js:

JSX
// EventBus.js
class EventBus {
  constructor() {
    this.events = {};
  }

  subscribe(eventName, callback) {
    if (!this.events[eventName]) {
      this.events[eventName] = [];
    }
    this.events[eventName].push(callback);
  }

  publish(eventName, data) {
    if (this.events[eventName]) {
      this.events[eventName].forEach(callback => callback(data));
    }
  }
}

const eventBus = new EventBus();
export default eventBus;
 

Это файл списка товаров:

JSX
// Список товаров (React)
import React, { useEffect, useState } from 'react';
import { fetchProducts } from './ProductService';
import eventBus from './EventBus';

const ProductList = () => {
  const [products, setProducts] = useState([]);

  useEffect(() => {
    fetchProducts().then(setProducts);
  }, []);

  const addToCart = (product) => {
    eventBus.publish('addToCart', product);
  };

  return (
    <div>
      {products.map(product => (
        <div key={product.id}>
          {product.name}
          <button onClick={() => addToCart(product)}>Add to Cart</button>
        </div>
      ))}
    </div>
  );
};

export default ProductList;
 

Корзина:

JSX
// Корзина (Vue)
<template>
  <div>
    <div v-for="item in cartItems" :key="item.id">{{ item.name }}</div>
  </div>
</template>

<script>
import eventBus from './EventBus';

export default {
  data() {
    return {
      cartItems: []
    };
  },
  created() {
    eventBus.subscribe('addToCart', (item) => {
      this.cartItems.push(item);
    });
  }
};
</script>
 

Задание 2

Какие преимущества у модели Pub/Sub? Выберите все правильные ответы.

Она обеспечивает слабую связанность между компонентами

Модель pub/sub обеспечивает слабую связанность между компонентами, что улучшает модульность и гибкость системы.

Она позволяет всем компонентам напрямую изменять состояние

Она упрощает масштабирование и добавление новых компонентов

Модель Pub/Sub упрощает масштабирование и добавление новых компонентов за счёт асинхронного взаимодействия через события.

Она позволяет легко отслеживать изменения состояния

Модель Pub/Sub позволяет легко отслеживать изменения состояния, так как все изменения происходят через события, на которые можно подписаться.

Она требует синхронного взаимодействия между компонентами

Библиотека глобального состояния

Библиотеки глобального состояния (global state, shared state) ещё называют библиотеками общего состояния. С ними разные микрофронтенды могут получить доступ к общему состоянию и изменять его. Библиотека сама ходит в базу данных через API и обновляет данные на фронтенде. К библиотекам глобального состояния относятся Redux, MobX и Context API в React.

Такой подход гарантирует, что все части приложения синхронизируются и последовательно взаимодействуют с пользователем.

Библиотеки глобального состояния — очень мощный инструмент. Их возможности не заканчиваются созданием общего хранилища. Например, с помощью Redux можно реализовать паттерн Observable state (наблюдаемое состояние). Это вариация паттерна Observer (наблюдатель), которую применяют к состоянию. Концептуально паттерн Observable state очень похож на Pub/Sub: компонент может подписаться на состояние и обновляться каждый раз, когда получает новое состояние.

Когда использовать библиотеку глобального состояния

Эта стратегия подойдёт, если в проекте:

Тесная связь между разными частями приложения. Нужно, чтобы разные части приложения совместно использовали глобальное состояние, а информация там всегда была актуальной. Библиотеки глобального состояния хорошо сочетаются с архитектурой микрофронтендов: несколько микрофронтендов читают из одного состояния и записывают в него обновления.
Важно поддерживать последовательный пользовательский опыт. Например, несколько компонентов вашего интерфейса отражают состояние аутентификации пользователя. Это состояние должно быть везде одинаковым. Библиотека с глобальным состоянием поможет вам поддерживать единообразие и согласованность в разных частях приложения.
Сложные требования к управлению состояниями. Например, вы используете вложенное или иерархическое состояние. Библиотека типа Redux обеспечит структурированный подход к управлению таким состоянием.

🔹 Примеры использования

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

Сергей

Пример кода

В приложении онлайн-магазина состояние корзины разделено между тремя микрофронтендами:

профиль пользователя на Angular,
список товаров на React,
корзина на Vue.

Для глобального состояния выбрали библиотеку Redux. C её помощью создают Redux Store — это хранилище для глобального состояния. Каждый микрофронтенд может подключаться к этому хранилищу — обновлять общее состояние или реагировать на изменения.

Рассмотрим простой сценарий: пользователь авторизовался и добавил товар в корзину. Так будет выглядеть взаимодействие между микрофронтендами и хранилищем:

Вот пример кода хранилища:

JSX
// store.js
import { createStore } from 'redux';

const initialState = {
  cart: [],
  user: null
};

function rootReducer(state = initialState, action) {
  switch (action.type) {
    case 'ADD_TO_CART':
      return { ...state, cart: [...state.cart, action.payload] };
    case 'SET_USER':
      return { ...state, user: action.payload };
    default:
      return state;
  }
}

const store = createStore(rootReducer);
export default store;
 

Так выглядит компонент микрофронтенда списка товаров:

JSX
// Список товаров (React)
import React, { useEffect, useState } from 'react';
import { fetchProducts } from './ProductService';
import { useDispatch } from 'react-redux';

const ProductList = () => {
  const [products, setProducts] = useState([]);
  const dispatch = useDispatch();

  useEffect(() => {
    fetchProducts().then(setProducts);
  }, []);

  const addToCart = (product) => {
    dispatch({ type: 'ADD_TO_CART', payload: product });
  };

  return (
    <div>
      {products.map(product => (
        <div key={product.id}>
          {product.name}
          <button onClick={() => addToCart(product)}>Add to Cart</button>
        </div>
      ))}
    </div>
  );
};

export default ProductList; 

Профиль пользователя:

JSX
// Профиль пользователя (Angular)
import { Component, OnInit } from '@angular/core';
import { UserService } from './user.service';
import { useDispatch, useSelector } from 'react-redux';

@Component({
  selector: 'app-user-profile',
  template: `<div *ngIf="user">{{ user.name }}</div>`
})
export class UserProfileComponent implements OnInit {
  user: any;
  dispatch = useDispatch();

  constructor(private userService: UserService) {}

  ngOnInit() {
    this.userService.getUserProfile().subscribe(data => {
      this.dispatch({ type: 'SET_USER', payload: data });
    });

    this.user = useSelector(state => state.user);
  }
 

Корзина:

JSX
// Корзина (Vue)
<template>
  <div>
    <div v-for="item in cartItems" :key="item.id">{{ item.name }}</div>
  </div>
</template>

<script>
import { useSelector } from 'react-redux';

export default {
  computed: {
    cartItems() {
      return useSelector(state => state.cart);
    }
  }
};
</script> 

Задание 3

Какие утверждения верно характеризуют библиотеки глобального состояния? Выберите все правильные ответы.

Они позволяют нескольким микрофронтендам читать из одного состояния и записывать в него обновления

Верно. Глобальное состояние позволяет нескольким микрофронтендам синхронизировать данные между собой.

Они упрощают управление состоянием в приложениях, где состояние каждого компонента должно быть независимым

Они помогают поддерживать последовательный пользовательский опыт

Глобальное состояние помогает синхронизировать состояние приложения, обеспечивая единообразие пользовательского опыта.

Они применимы только в приложениях с простыми требованиями к состоянию

Они полезны для управления сложными иерархическими состояниями

Глобальное состояние позволяет структурировать и управлять сложными состояниями в приложении.

Мы разобрали все три стратегии коммуникации. Закрепим, какую стратегию когда использовать.

Как выбрать стратегию коммуникации

Реализация стратегии взаимодействия микрофронтендов — это последний этап перехода.

🔍 Сохраните схему целиком. Она поможет организовать переход с монолита на микрофронтенды.

Как разбить монолитный фронтенд на микрофронтенды.pdf

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

Приложение растёт или требования к нему усложняются. Наступает момент, когда нужно наладить взаимодействие между компонентами.

Если достаточно обновлять в компонентах только одно конкретное значение, команды подключают общую шину событий. Она реализует паттерн Pub/Sub.

Если нужны состояния более сложные, подключают библиотеку глобального состояния типа Redux, MobX или NGRX. Библиотеки глобального состояния решают проблему межмодульной коммуникации. В сложных системах трудно реализовать реактивность. Зачастую получается настолько большой каскад обновлений, что он сводит на нет всю идею реактивности. Для этого в библиотеках тоже есть решение: можно реализовать паттерн Observable state. Он работает почти так же, как Pub/Sub.

Задание 4

Сопоставьте каждую ситуацию с подходящим методом управления состоянием.

Pub/Sub

Дашборд аналитики, где различные виджеты должны обновлять данные в реальном времени без прямых зависимостей друг от друга

Обмен сообщениями между виджетами дашборда для обновления данных в реальном времени

Глобальное состояние

Централизованное управление состоянием корзины и пользовательской сессии в онлайн-магазине

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

API

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

Взаимодействие с бэкендом для получения и обновления данных о пользователях

Задание 5

Сопоставьте название и описание этапа.

Определение подходящего метода компоновки микрофронтендов включает выбор между методами build time и run time, а также различными типами компоновки.

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

Выбор подходящих инструментов — это важный этап. Продуманный выбор поможет упростить процесс разработки и интеграции микрофронтендов.

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

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

API в архитектуре микрофронтендов можно реализовать по-разному. Один из возможных подходов — паттерн Backend for Frontend. В следующем уроке разберём, как он работает и какие проблемы решает.

Итоги

Чтобы микрофронтенды работали как единый пользовательский интерфейс, нужно настроить коммуникацию между ними. Это обязательный этап перехода на архитектуру микрофронтенда.

Для управления состоянием есть три стратегии — это взаимодействие на основе API, библиотеки глобального состояния и паттерн Pub/Sub.

Используйте коммуникации через API, если:

Вам нужна независимая связь с бэкендом.
У приложения простые потребности в общении, они сводятся к получению данных или отправке форм.
Вам критически важны производительность и независимая масштабируемость.

Используйте паттерн Pub/Sub, если:

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

Используйте библиотеки глобального состояния, если:

Вам нужно тесное взаимодействие и согласованное состояние микрофронтендов.
У вашего приложения сложные потребности в управлении состоянием.