Разработка веб-интерфейса ERP: стек, виртуализация, производительность

Отметим: когда в ERP-системе складской отчёт зависает на 10 секунд при загрузке 50 000 строк, пользователи начинают использовать Excel. Разработка веб-интерфейса ERP — это не про React из коробки, а про тонкую настройку виртуализации, управление состоянием и разрешение конфликтов доступа. В многопользовательской среде критична блокировка записей при одновременном редактировании. Без proper optimistic concurrency control пользователи перезаписывают данные друг друга. Типичные боли: медленная загрузка таблиц, путаница с правами доступа, потеря данных при offline. Мы решаем их с помощью SPA, виртуализации, оптимистичных обновлений и Permission Guard для ERP. Разрабатываем интерфейсы от MVP с четырьмя модулями до полноценной системы на 15+ модулей. В этом материале разберём ключевые архитектурные решения и практические приёмы, которые помогут избежать типовых ошибок и построить масштабируемый интерфейс.

Выбор стека для ERP-интерфейса

Выбор архитектуры и стека — фундамент, от которого зависит производительность и стоимость поддержки. Рассмотрим два распространённых подхода: SPA и SSR.

Для ERP выбор однозначный — SPA. Исключение — если требуется SEO для публичных частей (например, каталог продукции).

Frontend стек: React 18+ с Concurrent Features, TypeScript (strict), TanStack Table для таблиц, TanStack Query для данных, React Hook Form + Zod для форм, Zustand для UI-состояния. Компонентная библиотека — Radix UI + Tailwind (гибкость) или Ant Design (скорость).

Как работать с большими таблицами?

Таблица на 50 000 строк — типичная задача для складского учёта или отчётности. Без виртуализации браузер зависает. Благодаря виртуализации время рендеринга падает до 100 мс даже при 100 000 строк.

import { useReactTable, getCoreRowModel, flexRender, type ColumnDef, } from '@tanstack/react-table'; import { useVirtualizer } from '@tanstack/react-virtual'; import { useRef } from 'react'; interface VirtualizedTableProps<T> { data: T[]; columns: ColumnDef<T>[]; rowHeight?: number; } export function VirtualizedTable<T>({ data, columns, rowHeight = 40, }: VirtualizedTableProps<T>) { const parentRef = useRef<HTMLDivElement>(null); const table = useReactTable({ data, columns, getCoreRowModel: getCoreRowModel(), }); const { rows } = table.getRowModel(); const virtualizer = useVirtualizer({ count: rows.length, getScrollElement: () => parentRef.current, estimateSize: () => rowHeight, overscan: 20, }); const virtualItems = virtualizer.getVirtualItems(); const totalSize = virtualizer.getTotalSize(); return ( <div ref={parentRef} className="overflow-auto h-full"> <table className="w-full border-collapse"> <thead className="sticky top-0 bg-white z-10 shadow-sm"> {table.getHeaderGroups().map(headerGroup => ( <tr key={headerGroup.id}> {headerGroup.headers.map(header => ( <th key={header.id} style={{ width: header.getSize() }} className="text-left px-3 py-2 text-xs font-semibold text-gray-600 border-b" > {flexRender(header.column.columnDef.header, header.getContext())} </th> ))} </tr> ))} </thead> <tbody> {virtualItems.length > 0 && ( <tr style={{ height: virtualItems[0].start }}> <td colSpan={columns.length} /> </tr> )} {virtualItems.map(virtualRow => { const row = rows[virtualRow.index]; return ( <tr key={row.id} className="hover:bg-gray-50 border-b border-gray-100" style={{ height: rowHeight }} > {row.getVisibleCells().map(cell => ( <td key={cell.id} className="px-3 py-2 text-sm"> {flexRender(cell.column.columnDef.header, cell.getContext())} </td> ))} </tr> ); })} {virtualItems.length > 0 && ( <tr style={{ height: totalSize - virtualItems[virtualItems.length - 1].end }}> <td colSpan={columns.length} /> </tr> )} </tbody> </table> </div> ); } 

Как ускорить отклик интерфейса?

Оптимистичные обновления — пользователь меняет статус заказа, интерфейс реагирует немедленно, не ждёт ответа сервера. При ошибке происходит откат. Это сокращает воспринимаемое время отклика на 200–500 мс.

const queryClient = useQueryClient(); const updateStatus = useMutation({ mutationFn: (data: { orderId: string; status: OrderStatus }) => api.patch(`/orders/${data.orderId}/status`, { status: data.status }), onMutate: async ({ orderId, status }) => { await queryClient.cancelQueries({ queryKey: ['orders', orderId] }); const prev = queryClient.getQueryData(['orders', orderId]); queryClient.setQueryData(['orders', orderId], (old: Order) => ({ ...old, status, })); return { prev }; }, onError: (_err, { orderId }, context) => { queryClient.setQueryData(['orders', orderId], context?.prev); toast.error('Не удалось изменить статус'); }, onSettled: (_, __, { orderId }) => { queryClient.invalidateQueries({ queryKey: ['orders', orderId] }); }, }); 

Разрешение конфликтов данных при многопользовательском доступе

Используем стратегию last-write-wins с версионированием сущностей. Каждая запись содержит поле version (integer), которое увеличивается при изменении. Клиент передаёт текущую версию, сервер проверяет совпадение. Если версия устарела — возвращает 409 Conflict, клиент получает актуальные данные и предлагает пользователю разрешить конфликт. Это реализовано поверх TanStack Query через механизм optimistic updates + rollback.

Разграничение доступа к модулям с Permission Guard

Создаём компонент Permission Guard, который проверяет наличие разрешения у пользователя. Если разрешения нет — можно показать заглушку или ничего. Роли и разрешения хранятся на сервере, клиент получает их при аутентификации.

type Permission = 'orders:read' | 'orders:write' | 'stock:read'; function PermissionGuard({ permission, children, fallback = null }: { permission: Permission; children: ReactNode; fallback?: ReactNode; }) { const user = useUser(); if (user.permissions.includes(permission)) { return <>{children}</>; } return <>{fallback}</>; } 

Производительность: дополнительные оптимизации

• Code splitting по модулям — пользователь склада не загружает модуль HR, ускоряя загрузку на 40%.
• Дебаунс для поиска и фильтров — отправляем запрос не чаще одного раза в 300 мс, снижая нагрузку на сервер в 3 раза.
• Мемоизация тяжёлых вычислений — отчёты с агрегацией в браузере через useMemo.

Следим за показателями Core Web Vitals — ключевыми метриками производительности, которые напрямую влияют на UX. MDN Web Docs рекомендует ориентироваться на LCP < 2.5 с, FID < 100 мс, CLS < 0.1. Используем TanStack Query для управления серверным состоянием.

Процесс работы

Этапы разработки ERP-интерфейса:

1. Аналитика — изучаем бизнес-процессы, определяем модули и приоритеты.
2. Проектирование — создаём архитектуру, выбираем стек, прототипируем ключевые экраны.
3. Реализация — итеративная разработка с демо каждые две недели.
4. Тестирование — unit, integration, e2e тесты, нагрузочное тестирование.
5. Деплой — настройка CI/CD, миграция данных, обучение пользователей.

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

Сроки

• MVP с четырьмя-пятью модулями: 6–8 месяцев для команды из трёх-четырёх разработчиков.
• Полноценная система (15+ модулей): 1,5–2 года при той же команде.

Итеративный подход — запуск минимального набора, обратная связь от пользователей, постепенное расширение. Попытка сделать всё сразу ведёт к провалу.

Что входит в работу

• Техническое задание и архитектурная документация.
• Разработка и настройка CI/CD.
• Покрытие кода тестами (unit, integration).
• Документация API и пользовательская документация.
• Обучение администраторов и пользователей.
• Гарантийная поддержка 6 месяцев после запуска.

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