Зачем вообще говорить про архитектуру SPA
Когда-то фронтенд был «посверкать кнопочками и анимировать меню». Сейчас — это сложные SPA-приложения, которые тащат на себе бизнес‑логику, сложные данные и интеграции. Ошибка в архитектуре легко превращается в:
- сломанный деплой;
- непредсказуемые баги;
- невозможность масштабировать команду.
Поэтому разговор про архитектуру современных SPA — это не теория, а вопрос выживания проекта.
От jQuery к SPA: как мы вообще сюда пришли
Эпоха jQuery: «немного магии поверх HTML»
В начале 2010‑х картинка была простой: есть серверный рендер (PHP, Ruby, .NET), который отдает HTML‑страницы. jQuery добавляет динамику: модалки, AJAX, валидатор форм.
Типичная логика выглядела так:
```js
$('#save').on('click', function () {
$.ajax({
url: '/api/save',
method: 'POST',
data: $('#form').serialize(),
success: function (response) {
$('#status').text('Готово!');
}
});
});
```
Код работает… пока таких обработчиков 10–20. На реальных проектах через год:
- 3000+ строк в одном файле;
- глобальные переменные;
- «магические» селекторы `$('.btn-blue')`, которые ломаются от смены дизайна;
- тестировать нечего — всё спаяно в одну кучу.
В консалтинге мне попадался проект на jQuery и Bootstrap 3: 14 экранов, три человека в команде, и никто уже не решался «что-то менять», потому что любое исправление ломало что‑то в другом месте.
Первое поколение SPA: «давайте перенесём всё в браузер»
Появились AngularJS, Backbone, Knockout. Идея проста: раз браузер стал мощным, пусть он рендерит интерфейс, а сервер отдает только API (JSON).
Это дало:
- роутинг на клиенте (без перезагрузки страниц);
- шаблонизацию;
- первые попытки выделить слои: `models`, `views`, `controllers`.
Но всплыли новые проблемы: тяжелый бандл, SEO, сложность вхождения. Тогда же родилась мысль, к которой сейчас мы вернулись в Next.js: часть работы всё-таки стоит делать на сервере.
Появление React: UI как функция от состояния
React в 2013–2014 изменил мышление: «интерфейс = функция от state». Не «нарисуй элемент и потом модифицируй DOM», а:
```jsx
function TodoList({ items }) {
return (
-
{items.map(item =>
- {item.text}
)}
);
}
```
Компоненты стали единицей переиспользования и мысли. Это критически важно для архитектуры: появилось естественное место, куда класть логику, разбивать на модули, выделять абстракции.
На реальном проекте в финтехе мы заменяли jQuery‑панель управления на React. Количество багов, связанных с «DOM не в том состоянии», упало примерно на 40 % после перехода на предсказуемый state и компоненты. Просто потому, что исчезла ручная возня с DOM.
Архитектура SPA на React: из чего вообще всё состоит
Если отбросить модули, папки и спор про «правильный» стиль, типичное SPA на React делится на несколько слоёв.
1. UI‑слой (компоненты)
Отображает данные, почти не думает. Идеально, если 70–80 % компонентов у вас — «тупые» (presentational), без бизнес‑логики.
2. Слой состояния (state management)
Redux, Zustand, MobX, React Query + локальный state. Здесь живут данные, которые важны сразу для нескольких частей приложения: текущий пользователь, корзина, фильтры.
3. Слой работы с сервером (API‑клиент)
Axios/fetch, обёртки над запросами, обработки ошибок и ретраев.
4. Роутинг
React Router или встроенный роутер Next.js. Управление страницами, параметрами, protected routes.
5. Инфраструктурный слой
Конфиг Webpack/Vite, линтеры, тесты, CI/CD. Всё, что определяет, как приложение живет в проде.
Технический блок: простая, но жизнеспособная структура
```txt
src/
app/ # роуты, layout'ы, провайдеры
entities/ # сущности домена: User, Product, Order
features/ # фичи: auth, cart, filters
shared/ # общие компоненты и утилиты
widgets/ # сложные блоки: Header, Sidebar, Dashboard
```
Эта идея близка к feature-sliced архитектуре и хорошо заходит на проектах с командой от 4–5 фронтендеров.
Почему Next.js стал де-факто стандартом для современных SPA
Долгое время React решал только проблему интерфейса, но не:
- SSR;
- SEO;
- разбиение кода;
- маршрутизацию на сервере.
Next.js закрыл эти дыры: серверный рендер, гибридный режим (SSR + SSG), отличная история с роутингом и файловой системой.
На практике это означает, что:
- первая отрисовка страницы в 2–4 раза быстрее для медленных сетей за счёт SSR;
- Core Web Vitals улучшаются без «танцев с бубном»;
- SEO для маркетинговых/контентных страниц работает «из коробки».
На одном e‑commerce проекте переход с CRA на Next.js дал:
- снижение Time to First Byte ~с 800–900 ms до 200–300 ms;
- рост конверсий с органики на 12–15 % за счёт лучше индексируемого контента.
Технический блок: гибридный рендеринг в Next.js
```tsx
// app/products/[id]/page.tsx
import { getProduct } from '@/shared/api';
export default async function ProductPage({ params }) {
const product = await getProduct(params.id); // SSR-запрос
return
}
```
Здесь:
- данные для конкретной страницы грузятся на сервере;
- HTML отдаётся уже с готовым содержимым;
- на клиенте React просто «гидратирует» страницу.
Практическая архитектура: как не утонуть в хаосе
1. Чёткое разделение слоёв
Главная ошибка начинающих — тянуть всё в компонент.
```jsx
// Антипример
function ProductsPage() {
const [products, setProducts] = useState([]);
useEffect(() => {
axios.get('/api/products').then(res => setProducts(res.data));
}, []);
return (
);
}
```
Через полгода страницу невозможно тестировать и переиспользовать. Лучше:
```jsx
// hooks/useProducts.ts
export function useProducts() {
return useQuery(['products'], fetchProducts);
}
// pages/ProductsPage.tsx
function ProductsPage() {
const { data: products } = useProducts();
return
}
```
Результат:
- API-логика живет отдельно;
- UI можно реально протестировать изолированно;
- переезд с REST на GraphQL потребует меньше переписывания.
2. Стандартизация фич
На проектах, где 10+ разработчиков, спасает договорённость: «Каждая существенная фича — это модуль со своим API».
Например, у вас есть `features/auth`:
- внутри лежат компоненты `LoginForm`, `RegisterForm`;
- хук `useAuth`;
- сервисы `login`, `logout`.
Снаружи используется только то, что явно экспортируется из `index.ts`. Это и есть маленькая архитектура в масштабе одной фичи.
3. Числа и факты из практики
На реальном B2B‑продукте (длинные формы, много состояний, сложная таблица) сравнивали:
- хаотичный подход «как получится»;
- модульную архитектуру по фичам (feature-based).
После рефакторинга:
- время онбординга нового разработчика сократилось с 3–4 недель до ~10 дней;
- количество регрессионных багов после релизов упало примерно на треть;
- рефакторинг больших кусков логики стал возможен без тотальной переписки.
Next.js и архитектура: что меняется по сравнению с «чистым» React
Страницы vs компоненты
В Next.js у вас появляются новые «точки входа» архитектуры:
- страницы (pages/app routes) — «контейнеры» для данных и роута;
- layout‑ы — обёртки над группами страниц (общий header/footer, провайдеры);
- серверные компоненты — место, где можно безопасно ходить в БД или приватное API.
Важно не повторять ошибку старых SPA: не тащить сейчас всю логику в layout или page. Часть должна оставаться в фичах и сущностях.
Технический блок: серверные и клиентские компоненты
```tsx
// server component
import { getUser } from '@/entities/user';
export default async function ProfilePage() {
const user = await getUser();
return (
);
}
// client component
'use client';
export function ProfileView({ user }) {
const [tab, setTab] = useState('info');
return (
// интерактивщина уже здесь
);
}
```
Логика:
- всё, что можно сделать на сервере (запросы, тяжелые вычисления) — делаем там;
- всё, что требует интерактивности (формы, локальный UI‑state) — в клиентских компонентах.
Где тут обучение и как это все осваивать
Многие разработчики пытаются «нащупать» архитектуру сами, через боль. Но сейчас есть нормальные курсы по современному фронтенд‑разработке React и Next.js, где вам не просто объяснят, как сделать todo‑лист, а разберут реальные паттерны: разбиение на слои, работу с API, SSR/SSG, кеширование, роутинг.
Если хотите зайти в профессию с нуля, то формат «frontend разработчик React Next.js удаленно обучение с нуля» с практическими проектами и разбором чужого legacy кода обычно эффективнее разрозненных статей. Важно, чтобы в программе было именно обучение архитектуре SPA приложений React Next.js онлайн, а не просто «вот вам JSX и вот useState».
Для действующих инженеров логичным шагом будет повышение квалификации фронтенд разработчиков по архитектуре SPA: разбор сложных кейсов, микрофронтенды, модульные монолиты, монорепы, дизайн публичных API между фичами.
Практика: на что смотреть при старте нового SPA
Чтобы не утонуть в деталях, можно ориентироваться на чек‑лист.
Небольшой чек‑лист из практики
1. Определите доменные сущности
Пользователь, продукт, заказ — и т.п. Под них создайте `entities/`.
2. Выделите ключевые фичи
Авторизация, корзина, поиск, фильтры, оплата. Каждая — в своем модуле `features/`.
3. Заранее договоритесь о правилах импорта
Например: фичи не могут импортировать друг друга напрямую, только через `entities` и `shared`.
4. Сразу выберите стратегию работы с данными
REST/GraphQL, React Query/RTK Query и т.д. Избегайте «и так, и сяк» одновременно.
5. Настройте минимальный CI
Линтеры, форматтер, базовые тесты. Это дешевле, чем потом чинить архитектурный хаос.
Сколько стоит архитектура и «разработка SPA под ключ»
Когда бизнес заказывает разработку SPA на React и Next.js под ключ цена сильно зависит именно от архитектуры. Два проекта с одинаковым количеством экранов могут отличаться в 2–3 раза по стоимости поддержки через год.
Из практики:
- «большой» SPA без внятной структуры → через 12–18 месяцев до 40–50 % времени команды уходит на «поддержать шатающийся домик»;
- хорошо спроектированный SPA (слои, разделение по фичам, понятные правила импорта) → основное время тратится на развитие, а не на тушение пожаров.
Инвестиции в архитектуру на старте — это не «красиво по диаграммам», а конкретные деньги и скорость вывода фич в прод.
Итоги: куда всё движется дальше
Фронтенд прошёл путь:
- от «прицепить jQuery и считать, что этого достаточно»;
- через первичные SPA, где всё переехало в браузер;
- к современным гибридным архитектурам на React и Next.js, где часть логики снова живет на сервере.
Сейчас фокус не в том, «какой фреймворк моднее», а:
- как разделить ответственность между слоями;
- как сделать код поддерживаемым при росте команды;
- как балансировать между SSR, SSG и клиентскими компонентами.
Если вы только заходите в тему, начните с простых приложений, но сразу думайте слоями: UI, состояние, данные, фичи. Если уже работаете на проде — посмотрите, где у вас смешаны уровни: компоненты, которые знают слишком много, хаотичные импорты, отсутствие чётких контуров модулей.
Архитектура SPA — это не про диаграммы в Confluence. Это про то, сможете ли вы через два года спокойно открыть свой проект, а не переписывать его с нуля.
