Розробка веб-інтерфейсу 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 місяців після запуску.

Зв'яжіться з нами для оцінки вашого проекту. Отримайте консультацію з архітектури та строків.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.