Микрофронтенды

Микрофронты — это подход, при котором большое фронтенд-приложение разбивается на независимые части, каждая из которых:
🚧 разрабатывается отдельно
🚀 может деплоиться независимо
👥 имеет свою команду и ответственность

По сути, это микросервисы, но для фронтенда 🧩

🤔 Зачем это делают?

Тут похоже как с микросервисами:
желание поделить монолит на независимые куски,
чтобы не зависеть от других команд / функционала.

👨‍💻 Как это выглядит в коде

SPA composition (через роутинг)

Shell-приложение решает, какое SPA показывать по URL:

// shell/App.tsx
import { BrowserRouter, Routes, Route } from "react-router-dom";

export function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/profile/*" element={<ProfileApp />} />
        <Route path="/billing/*" element={<BillingApp />} />
      </Routes>
    </BrowserRouter>
  );
}

✅ Плюсы очевидны:
- независимые релизы
- масштабирование команд
- изоляцию ошибок
- можно использовать React, Vue, Angular одновременно

❌ Минусы тоже есть:
- сложнее инфраструктура
- сложнее дебаг
- выше требования к архитектуре

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

Микрофронты оправданы, если вы работаете на большом проекте 🏗️

В моей практике я использовал микрофронты на очень больших проектах:
🏦 2 больших банка и 🛒 маркетплейс.

Есть несколько вариантов реализации: Module Federation, iframe, SPA composition

// profile/webpack.config.js
new ModuleFederationPlugin({
  name: "profile",
  exposes: {
    "./ProfileWidget": "./src/ProfileWidget",
  },
});

<iframe
  src="https://billing.example.com"
  style="width:100%; height:100%; border:0"
/>

Самая дорогая фронтенд-архитектура

Есть фронтенд-навыки, которые просто закрывают задачи.
А есть те, которые повышают ценность разработчика на рынке.

💫 Микрофронты из второй категории.

их сильно ценят крупные компании — и готовы за это платить.

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

В этот момент фронтенд перестаёт быть приложением
и становится сложной системой.

В которой вопросы без простых ответов:
— какие зависимости shared?
— кто владеет роутингом?
— где границы ответственности?

shared: {
  react: { singleton: true },
  'react-dom': { singleton: true }
}

Одна строка здесь уже архитектурное решение.
Поэтому микрофронты — одна из самых сложных
и самых дорогих архитектур во фронтенде.

На этом и построен мой интенсив по микрофронтам:
архитектура, реальные кейсы и мышление сильного инженера .

Если хочешь прокачать навык, который реально ценят работодатели смотри пробный урок.

👉 ПРОБНЫЙ УРОК

❗️Узнать детальнее в личке

👉 ПОЛУЧИТЬ ДОСТУП

Новые стандарты разработки

Из всех углов слышно:

Нейронки заменят айтишников.

👻Страшно. Выключай.

Но честно говоря переживать стоит не только разработчикам.

🙎‍♂️Менеджерам тоже скоро придется напрягаться.
Без современных инструментов и базовой технической подкованности такие менеджеры скоро будут не нужны.
🦜Эпоха «менеджеров-дятлов» заканчивается.

Теперь:
— спецификация обязательна
— бизнес-контекст обязателен
— нормальное описание задач обязательно

🔽Тикеты формата «ну там кнопочку сделать» — в бан.

С программистами чуть по другому.
Больше не прокатит:

«Ну мужик, я сделал как мог, у меня вроде работает, дальше сам».

💻Теперь разработчику придётся:
— вникать в продукт, а не просто закрывать таски
— думать об архитектуре, последствиях решений и масштабировании
— пользоваться современными инструментами: AI, автотесты, линтеры, анализаторы, нормальные пайплайны

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

🔥 Архитектура до кода: как я сэкономил миллионы

Самая важная стадия разработки == архитектура.

Как я проектировал прилоежние сотни тысяч клиентов 🚀

1️⃣Сбор требований
Главная ошибка всех программистов сразу начать писать код ❌
Супер важно определить бизнес-цели, технические риски и будущие интеграции.

Я созвонился с 5 командами 📞, чтобы понять всю сложность. Множество деталей, которые нужно было держать в голове 🧠

Оказалось все не так просто, как описывал ПМ. Куча ограничений по безопасности, хранению данных пользователей 🔐 и непростые интеграции.

2️⃣ Проработка и визуализация

После сбора всех требований начал прорабатывать архитектуру.

Собрал клиент
👉 React + canvas + websockets + zustand

API Gateway

Обрисовал все взаимодействия с бэком и на какие сервисы будет делиться система:

User Service
Data Service
Anonymizer Service

Написал все интеграции и что нужно для взаимодействия с ними

Авторизация
Внешние LLM
Внутренние LLM
Хранение файлов S3
Email API

Определил зоны ответственности сервисов.
После этого апрув ✅.


3️⃣ Технический бэклог
После апрува архитектуры я разложил её на конкретные технические блоки:

Инфраструктура 🛠
- настройка CI/CD (линт, тесты, сборки, деплой)
- окружения (dev / stage / prod)
- управление секретами и конфигами

Безопасность и доступ
- модуль авторизации и ролей
- сервис анонимизации (чистки) данных

Frontend-архитектура
- сборка и изоляция модулей
- real-time взаимодействие (sockets)
- canvas / сложные UI-сценарии


И только после этих этапов начал писать первые строчки кода.

Как выбрать стек приложения? Фронтенд часть

1️⃣Выявление требований
Самый важный пункт. Нужно не выбираем между React/Vue/Svetle, а сначала узнаем что за продукт от нас нужен.

Ответьте на базовые вопросы:

Это лендинг, админка или сложный SaaS?
Нужен ли SEO?
Будет ли мобильная версия / PWA?
Ожидаемая нагрузка и масштаб?

🔠Антипаттерн: брать сложный фреймворк на лендинг или маленькое приложение.


2️⃣ Потребности бизнеса и возможности команды
Если в компании устоявшийся стек и проект нужно сделать, выбирайте его.
Никаких

"а давайте поиграемся с Effector, я читал на хабре что он крутой"

Времени на обучение уйдет уйма.
📱 Переход на новый фреймворк/модуль ради тренда часто замедлит разработку.

Реальный пример из работы:
Много лет назад на моей работе тимлид сказал что вместо redux и redux-saga будем использовать graphql и apollo-client. Никто на нем не умел писать. Целый месяц мы только писали одну страницу и потратили десятки часов на понимание этого модуля и подхода. В итоге тимлид сказал что отказываемся от apollo-client и все перепишем обратно на redux, т.к. так быстрее.

3️⃣ Фреймворк
В данном момент 2026 кроме React или Vue я считаю выбирать нечего. Svetle, Solid, Quick не подходят для продакшен кода большого/среднего приложения. Angular вообще умер 15 лет назад.
Небольшой/средний проект? Vue
Потенциально большой проект? React

4️⃣ Ресерч модулей под требования
После выявления требований можно начать выбирать или ресерчить модули.

Данные в реальном времени? WebSocket/SSE/Long-polling
Много графики? Canvas -> но модулей я не знаю -> иду ресерчить
PDF? pdf.js / react-pdf / PDFObject
Нужен SSR? Подумай о Next/Nuxt

И далее по списку

📱 Подбираешь модуль исходя из требований, функционала, экосистемы и коммьюнити.


5️⃣ Архитектура проекта
Фреймворк это только часть стека.
Нельзя забывать про:
- структуру проекта (FSD, слоистая, модульная)
- state management
- роутинг
- тестирование
- сборщики и линтеры

Хорошая архитектура важнее выбора конкретной библиотеки.

Ускорил разработку в 2 раза с помощью ИИ

🚀 Сейчас работаю на проекте где нам разрешено использовать любые AI инструменты, т.к. сам проект делает огромное количество ИИ интеграций.

🧠 Мой реальный опыт по ускорению и автоматизации написания кода:

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

⚙️ Боилерплейт
Типовые компоненты, обвязка под API, схемы, интерфейсы -> тут нейронки работают отлично. То, что раньше писал механически и монотонно, теперь появляется за минуты.

Было (писал сам):
type User = {
  id: string
  name: string
  email: string
}

export const fetchUser = async (id: string): Promise<User> => {
  const res = await API.call(API_URLS.user(id))
  if (!res.ok) {
    throw new Error('Failed to fetch user')
  }
  return res.json()
}

Стало:

Опиши функцию получения user с сервера с типизацией

🧹Рефакторинг.
Теперь разложить файл, упростить логику, привести код к одному стилю максимально быстро. ИИ делает все нас.

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

Было

export const validateUser = (data: any) => {
  if (!data) {
    return { valid: false, error: 'No data' }
  }

  if (typeof data.email !== 'string') {
    return { valid: false, error: 'Email is required' }
  }

  if (!data.email.includes('@')) {
    return { valid: false, error: 'Email is invalid' }
  }

  return { valid: true }
}

Стало

type UserInput = {
  name: unknown
  email: unknown
}

const isString = (v: unknown): v is string =>
  typeof v === 'string'

const validateName = (name: unknown): string | null => {
  if (!isString(name)) return 'Name is required'
  if (name.length < 2) return 'Name is too short'
  return null
}

const validateEmail = (email: unknown): string | null => {
  if (!isString(email)) return 'Email is required'
  if (!email.includes('@')) return 'Email is invalid'
  return null
}

🐌 Но вот когда реально ИИ начинает тормозить:

❌ если не декомпозировать задачу
❌ не формализовать требования
❌ не проверять результат

Я просто скормил промт

Сделай такую задачу(краткие бизнес требования), напиши фронтенд часть, напиши бекенд часть. Используй стандартный стек.

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

🧑‍💻 По ощущениям, ИИ как джун, который пишет код очень быстро.
Но если правильно не направлять и не проверять, будет больно.


Итог простой:
ИИ реально даёт x2 по скорости,
но только тем, кто умеет думать, формулировать и проверять.

3 ошибки на собеседовании, из-за которых не дают оффер

⏰ 1. Время собеседования
Идеальное время для собеса это 13-15. Обязательно после обеда.
С утра все сонные и злые, под вечер уставшие.
После обеда собеседующие более довольные после еды и также кровь от головы оттекает к желудку и мучать будут не так сильно.

❓ 2. Обязательно задавай вопросы
Большая часть кандидатов не задают вопросов о проекте, компании, команде. Большая часть кандидатов не проходят собеседования.

🤔Всегда задавай интересующие вопросы. О проекте, о команде, о процессах. Это показывают вашу заинтересованность и проактивность.

👨‍💼Представьте себя на роли нанимающего. Пришел разработчик и ничего не спрашивает ничем не интересуется. Получается и в реальной работе также будет молчать.

🤫 3. Молчание во время решения задач

👩‍💻Во время решения задачи(лайфкодинг или систем дизайн) обязательно размышляй вслух
Если ты молча думаешь — интервьюер не понимает:
- как ты рассуждаешь
- почему принимаешь решения
- где именно ты застрял

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

Эти три вещи уже сильно выделяют кандидата среди остальных.


Какие моменты интересно разобрать вам с собеседований?

Почему React всех победил ⚛️

В 2017 я уже работал верстальщиком, писал приложения на Javascript и узнал про React, Vue, Angular.

И что учить было не так очевидно. Потрогал vue, потрогал angular,но в итоге выбрал react. И не прогадал. Почему в итоге реакт победил всех? 🤔

В 2013 вышел Angular == полноценный фреймворк.
С роутингом, реактивностью, полноценной архитектурой. Мощный фреймворк.
Казалось бы, круто, но все перешли на React. Почему?

Суть в том, что React — не фреймворк, а библиотека.
Он стал базовой абстракцией, вокруг которой построили экосистему. Можно было подключить такой модуль валидации или другой не важно. Все вокруг легко настраивалось.

Вокруг него выросла огромная экосистема 🚀
• Next.js
• React Native
• тысячи библиотек
• решения под любой кейс

Также не стоит забывать про прорывные концепции:
• Virtual DOM
• Компонентный подход
• Однонаправленный поток данных
• Hooks переход от ООП к функциональному мышлению

Hooks сделали большой шаг в сторону ФП
👉 компонент = чистая функция
👉 состояние и эффекты — тоже функции
👉 никакого this, наследования и иерархий

После этого все другие подхватили 🌍
• Vue перешёл к Composition API
• Angular начал активно двигаться в сторону сигналов и реактивности
• функциональные паттерны стали нормой даже вне React

🧩 Чистая архитектура (Clean Architecture) — это подход к проектированию приложений.

Главная идея проста:
бизнес-логика должна быть независима от фреймворков, баз данных, UI и внешних сервисов.
То есть если завтра вы поменяете React на другой фронт, PostgreSQL на MongoDB или REST на GraphQL ядро приложения не должно ломаться.

1️⃣Зависимости направлены внутрь
Внешние слои (UI, API, DB) могут зависеть от внутренних, но не наоборот.
Бизнес-логика не знает, какая база используется или какой фреймворк стоит сверху.

2️⃣Бизнес-логика — в центре
Самое важное = правила домена:
- расчёты
- сценарии использования
- бизнес-процессы
Они должны быть максимально чистыми и независимыми.

3️⃣ Инфраструктура лишь детали
Базы данных, HTTP, очереди, UI это всего лишь способы доставки данных, а не ядро системы.

🧠 Как это выглядит слоями
Обычно архитектура делится на несколько уровней:

Entities — бизнес-сущности и правила
Use Cases — сценарии использования (application logic)
Interface Adapters — контроллеры, presenters, gateways
Frameworks & Drivers — UI, базы данных, внешние сервисы

Если архитектура чистая:
✅ проще тестировать
✅ легче менять технологии
✅ код становится понятнее

На бекенде эти принципы спокойно применимы, но на фронтеде довести до такого вида не получается. Как думаете почему ?

Почему ты никогда не внедришь чистую архитектуру на фронтенде

👍Причина проста: Фронтенд сам по себе один большой презентационный слой. Он есть часть слоистой архитектуры. Поэтому и не представляет из себя обособленное целое и не применим для такого типа архитектуры.

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

🏠В классическом подходе бизнес-логика должна быть полностью независима от фреймворков. Но по факту любое действие пользователя проходит через механизмы конкретного фреймворка: lifecycle компонентов, hooks, state-менеджеры, роутеры, формы, реактивные системы.

Вместо этого появляются другие подходы == Feature-based архитектура, модульная. Они не пытаются полностью убрать влияние фреймворка. Они контролируют степень связанности и ограничивают места, где UI может влиять на бизнес-логику.

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


Смотри
👉Посмотреть бесплатный урок по архитектуре

👉 Узнать детальнее в лс

Получить доступ (Оплата РФ)

Получить доступ (Оплата не из РФ)

Что такое AI-агент и как он помогает в разработке

🤖🤖AI-агент — это фактически Бот который самостоятельно выполняет задачи, а не просто отвечает на вопросы. И при этом использует LLM модель и владеет контекстом кода.

AI-агент в разработке:
- генерируют и правят код по требованиям
- анализируют репозитории и предлагают рефакторинг
- могут запускать пайплайны, работать с API и базами.

🚀Они ускоряют рутинные задачи в 2-5 раз и позволяют быстрее прототипировать идеи.

⚡️В ближайшие годы нужно будет учиться управлять сложным воркфлоу таких агентов, а не просто писать промпты.