Аналіз архітектури e-commerce: чому поточний SPA потребує змін і як це зробити правильно

Логічний потік:

1. Браузер отримує HTML app-shell.
2. Браузер завантажує JS/CSS з хешем вмісту; ці файли можуть довго кешуватися, оскільки ім'я змінюється при зміні збірки.
3. React ініціалізується в #root, а роутер читає location.pathname для вибору компонента сторінки.
4. Сторінка отримує дані bootstrap або викликає REST API, якщо даних немає або вони застарілі.
5. React будує DOM і прикріплює обробники подій.
6. Подальші внутрішні переходи використовують History API; не відбувається повного перезавантаження документа.

Важливе розрізнення: наявність змінних window.__... не доводить SSR. Якщо HTML містить лише JSON і порожній root, це bootstrap/preload для CSR, а не серверний рендеринг. SSR існує лише тоді, коли HTML вже містить вміст продукту, заголовки, ціни, посилання та метадані до запуску JS.

Той факт, що кожен маршрут повертає однаковий app-shell, створює швидку навігацію SPA після першого завантаження, але джерело повинно правильно обробляти fallback, не перетворюючи неіснуючі URL на HTTP 200. Якщо /product/neisnuye також повертає app-shell з кодом 200, а React показує "не знайдено", пошуковий робот може вважати це soft 404. Google вимагає, щоб маршрути CSR правильно обробляли статуси помилок або використовували noindex, щоб уникнути soft 404 .

1.3 Потік даних каталогу

Ендпоінти показують, що каталог не вбудований у frontend bundle:

• GET /api/products?limit=500&active=1

  — отримання списку активних товарів.

• GET /api/products?q=...

  — пошук.

• GET /api/products/<slug>

  — деталі товару.

• GET /api/products/categories

  — таксономія.

Це відокремлює деплой фронтенду від змін у каталозі: зміна ціни, зображення або залишку не вимагає перезбірки Vite. Це явна перевага.

Однак, limit=500 свідчить про те, що API оптимізовано для невеликого каталогу. Для 16 товарів це нормально, але для тисяч SKU це призведе до зайвого навантаження на мережу, пам'ять браузера та інвалідацію кешу. Нова архітектура має використовувати cursor pagination, field projection та окремі ендпоінти для пошуку/фільтрації.

Поточна схема товару має ознаки "product-centric", а не "variant-centric":

• stock знаходиться на рівні товару, хоча існують variants.
• sizes, colors, genders — це масиви, що належать товару, але також можуть дублюватися у варіантах.
• Дані містять як XXL, так і 2XL, як

  ink navy

  , так і

  Ink Navy

  .
• image та images можуть мати дублюючі функції.
• type, isbn — це, ймовірно, загальні поля, перевикористані з іншого домену.

Чому це проблема: фактичний залишок та SKU належать комбінації варіантів, наприклад, Black/M та Black/L мають окремо зменшуватися; нестандартизовані рядки опцій роблять фільтрацію, аналітику та маппінг зображень за кольором нестабільними. Нова версія має стандартизувати значення опцій, SKU та інвентаризацію на рівні варіантів.

1.4 Builder головної сторінки

section_order разом з об'єктами увімкнення/вимкнення свідчить про те, що головна сторінка — це композиція, керована CMS, а не жорстко закодована послідовність компонентів.

Ймовірний рендерер:

1. /api/homepage повертає конфігурацію секцій.
2. Фронтенд обробляє section_order.
3. Кожен ключ (hero, trustbar, catshowcase, promo, products) мапується на React компонент.
4. Рендерер перевіряє toggle перед монтуванням компонента.
5. Компонент читає відповідний payload (зображення, текст, CTA, посилання на товари, термін дії акції).

Перевага: маркетинг може змінювати порядок та приховувати блоки без випуску нового коду.

Недолік: існують як ann, так і announcement, що свідчить про незавершену міграцію схеми або аліас ключа. Якщо section_order, toggle та payload є трьома окремими структурами, вони можуть бути неузгодженими: ключ є в order, але немає payload; toggle використовує іншу назву; payload існує, але не рендериться.

Нова архітектура має використовувати єдиний список блоків, де кожен блок має id, kind, enabled, position, payload, schema_version. Це зберігає порядок, стан та дані в одному агрегаті, зменшуючи ризик помилок синхронізації.

1.5 Builder макету та налаштування

/api/layout швидше за все містить конфігурацію header/footer/navigation, а /api/public/settings — брендинг та політику магазину. Розділення логічне, оскільки header/footer використовуються на всіх маршрутах, а композиція головної сторінки — лише на головній.

Список налаштувань свідчить про те, що key-value або JSON конфігурація керує:

• брендом та кольорами;
• логотипом/favicon;
• інформацією про компанію;
• комісіями та порогами безкоштовної доставки;
• вікнами обробки/транзиту;
• платіжним провайдером та PayPal client ID;
• соціальними посиланнями, способами оплати, навігацією та оголошеннями;
• кампаніями.

Перевага: гнучке адміністрування; додавання ключа не вимагає міграції.

Недолік: key-value не має контролю типів, зовнішніх ключів та валідації між полями. Наприклад, standard_handling_min не може бути більшим за standard_handling_max; paypal_sandbox має бути булевим; URL соціальних мереж потребують валідації. Нова версія має використовувати валідацію схеми та розділяти публічну конфігурацію від секретної/внутрішньої.

tax_id, юридична адреса, email операцій або інформація, не потрібна для вітрини, не повинна передаватися через публічні налаштування. PayPal client ID може бути публічним, але client secret — лише на сервері. Причина: браузер і будь-які змінні window.__... можуть бути прочитані користувачем.

1.6 Купони та оплата PayPal

Логічний платіжний потік:

1. Клієнт надсилає кошик та купон на сервер.
2. Сервер завантажує поточні товари/варіанти з бази даних, перевіряє активність, залишок та промо-акції.
3. Сервер самостійно розраховує суму, знижку, доставку, податок та загальну суму.
4. /api/paypal/create-order створює замовлення на PayPal з серверними обліковими даними та зберігає зв'язок із внутрішнім оформленням.
5. Клієнт відкриває потік підтвердження PayPal.
6. /api/paypal/capture захоплює підтверджене замовлення.
7. Сервер перевіряє суму/валюту/статус, створює офіційне замовлення, записує спробу оплати та резервує/списує залишок.
8. Webhook PayPal звіряє асинхронні статуси або перервані запити.

Сервер НЕ повинен довіряти price, discount, shipping або total, надісланим браузером. Причина: користувач може змінити запит; сервер має перераховувати все з SKU, правил промо-акцій та способів доставки.

Два ендпоінти create/capture — правильний напрямок, але якість залежить від:

• idempotency key для запобігання подвійному створенню/захопленню;
• транзакцій/блокувань для запобігання oversell;
• запису спроби оплати перед викликом провайдера;
• перевірки підпису webhook;
• перевірки валюти та суми;
• чіткої машини станів оформлення замовлення;
• завдання reconciliation для випадків, коли PayPal успішний, але відповідь не дійшла до сайту.

1.7 Відгуки, розсилка, контакти та відстеження

Ці ендпоінти перетворюють бекенд на повноцінний комерційний додаток, а не просто API каталогу.

• Відгуки: потрібна система статусів (pending/approved/rejected), захист від спаму, rate limit та верифікація покупця (verified purchase).

  POST /api/reviews/<id>

  — дивна назва маршруту для створення відгуку; нова версія має використовувати чіткішу семантику ресурсів.
• Розсилка: потрібна нормалізація email, унікальність, double opt-in (залежно від юрисдикції), відписка та захист від неконтрольованого логування email.
• Контакти: потрібна CAPTCHA або захист від ботів, rate limit, черга для надсилання листів; HTTP запит не повинен безпосередньо залежати від поштового провайдера.
• Відстеження замовлення: не дозволяйте пошук за коротким порядковим номером. Використовуйте signed tracking token або пару order reference + email/ZIP. Причина: публічний ендпоінт може бути використаний для перебору (enumeration) та витоку PII.

1.8 Аналітика/трекінг

Ендпоінт трекінгу не повинен приймати довільний JSON та зберігати його безстроково. Потрібен whitelist назв подій/властивостей, обмеження розміру, видалення або хешування PII та відправка через чергу. Причина: збір подій — це поверхня для зловживань, яка може штучно роздути базу даних/логи.

1.9 Ймовірний стек бекенду

Node.js з Express/Fastify/NestJS — найбільш імовірний, оскільки React/Vite часто поєднується з TypeScript та REST middleware Node. Вставка window.__INITIAL_DATA__ в HTML також легко реалізується через шаблони або middleware. Але це лише кореляція екосистеми, а не доказ. REST маршрути та snake_case поля не є унікальними для Node.

PHP з Laravel/Symfony — також можливий. Laravel легко створює REST контролери, міграції, черги, пошту, валідацію та може віддавати Vite app-shell через catch-all маршрут. Cloudflare може приховати будь-які ознаки X-Powered-By або cookie.

Python з FastAPI/Flask/Django — також можливий. FastAPI/Flask легко створюють JSON REST API, а Django має потужний ORM/адмінку. Vite build може обслуговуватися Nginx або окремим статичним джерелом, незалежно від Python бекенду.

Висновок щодо ідентифікації: недостатньо доказів для визначення мови бекенду. Ознаки, які можна законно зібрати у власній системі: deployment files, process manager, lockfile, container image, заголовки відповідей (до Cloudflare), префікси cookie, згенерований OpenAPI, формат помилок, драйвер бази даних. Не варто робити висновки лише з назв URL.

1.10 Технічні переваги

• Незалежний від платформи UI: React не залежить від тем PHP або життєвого циклу сторінок Woo; весь шар представлення знаходиться в окремому дереві компонентів.
• Гарне кешування статики: хеші Vite дозволяють

  Cache-Control: immutable

  ; новий деплой створює нові імена файлів замість інвалідації всіх активів.
• Достатня CMS для бренду: builder головної/макету зосереджений на блоках, які використовує магазин, без зайвого page-builder.
• Чіткий домен API: каталог, контент та операції можуть обслуговувати різні канали (веб, додаток, адмінка).
• Менше плагінів: зменшує ланцюжок залежностей теми/плагінів та конфлікти хуків.
• Швидка навігація після першого завантаження: SPA лише отримує дані та змінює компонент, а не перезавантажує весь документ.

1.11 Слабкі місця та ризики

• Перше завантаження залежить від JS: app-shell не має HTML вмісту товару; потрібно завантажити, розпарсити, виконати JS та викликати API; повільна мережа/слабкий чіп призводять до затримки контенту.
• API waterfall: якщо налаштування, головна, макет та товари викликаються послідовно, це збільшує LCP. Потрібен агрегований bootstrap, паралельні запити або серверний рендеринг.
• SEO/статус коди: catch-all app-shell легко створює однакові title/canonical та soft 404; соціальні роботи можуть не виконувати JS.
• Складна інвалідація кешу: каталог, головна, макет та налаштування мають різні TTL; занадто довгий кеш — застарілі дані, занадто короткий — навантаження на джерело.
• Власна бізнес-логіка: купони, статуси замовлень, податки, повернення, інвентаризація, webhook та адмінка потребують ретельного тестування.
• Нестандартизована модель даних: масиви кольорів/розмірів та stock на рівні товару ускладнюють розширення до inventory за SKU.
• Поверхня безпеки: контакти, відгуки, розсилка, відстеження та оплата — це публічні мутаційні ендпоінти, які потребують валідації/rate limiting/idempotency.
• Bus factor: якщо лише одна людина розуміє власний бекенд та builder, вартість передачі знань вища, ніж налаштування Woo.

2. Пряме порівняння з WooCommerce

2.1 Чи "крутіший" власний SPA за Woo?

Не можна зробити висновок лише на основі використання React/Vite та власного API. "Власний" дає більше контролю; це не автоматично означає швидше, краще для SEO, безпечніше або дешевше. Якість залежить від моделі даних, стратегії рендерингу, кешу, спостережуваності, тестування та платіжного процесу.

З каталогом лише на 16 товарів, власна розподілена архітектура може бути брендовою перевагою, але також може бути over-engineering, якщо команда мала, а основні потреби — управління замовленнями, купонами, доставкою, поверненнями, податками та звітами.

2.2 Швидкість завантаження

Власний SPA:

• Потенційно дуже швидкий при наступних навігаціях (JS/CSS кешуються, змінюються лише дані).
• Статичні активи можна роздавати через CDN.
• Перший перегляд може бути повільним через завантаження JS та API waterfall; невеликий app-shell не гарантує швидкого LCP, якщо зображення та текст з'являються лише після запиту.
• Один запит products?limit=500 стане вузьким місцем при зростанні каталогу.

Традиційний WooCommerce:

• HTML товару/категорії надходить відразу з сервера, тому контент з'являється без очікування React.
• Full-page кеш, CDN, об'єктний кеш та оптимізація зображень можуть зробити невелику вітрину дуже швидкою.
• Важкі плагіни, багато JS в темі, неоптимізовані запити до БД та нестача ресурсів PHP worker можуть збільшити TTFB.
• Кошик, обліковий запис та оформлення замовлення — це персоналізований контент, який важче кешувати, ніж landing сторінки.

Висновок: власний SPA має вищу стелю продуктивності при правильному SSR/SSG, кешуванні та оптимізації bundle; Woo має простіший базовий рівень. Порівнюйте реальні p75 Core Web Vitals на мобільних, TTFB джерела/CDN, обсяг JS, затримку API та частоту помилок, а не назви технологій.

2.3 Кастомізація UI та builder

Власний React явно виграє, коли брендовий досвід потребує анімацій, редакційних блоків, специфічних кампаній або поведінки компонентів, які не схожі на звичайні теми магазину. Команда контролює markup, стан, переходи маршрутів та дизайн-систему.

Власний builder головної/макету також може бути легшим за плагін page-builder, оскільки містить лише 10–15 типів блоків. Payload менший, а редактор має менше варіантів для помилок.

Woo виграє у speed-to-market та back-office. Редактор товарів, управління замовленнями, купони, повернення, інтеграція податків/доставки та маркетплейс розширень вже існують. Для аналогічної кастомізації потрібно створити адмін UX, валідацію, аудит та міграцію, а не лише вітрину.

2.4 SEO

Традиційний Woo має перевагу за замовчуванням, оскільки HTML товару/категорії та метадані рендеряться на сервері. Чистий клієнтський рендеринг (CSR) не означає "не індексується": Google може виконувати JavaScript, але вміст все одно залежить від черги рендерингу, доступності API, семантики маршрутів та внутрішніх посилань.

Реальні ризики чистого SPA:

• Початковий HTML не має назви товару, опису та структурованих даних.
• title/canonical/Open Graph оновлюються після JS, тому соціальні боти можуть їх пропустити.
• catch-all повертає 200 для помилкових URL.
• API заблоковано, timeout або помилка hydration призводять до того, що робот бачить порожню сторінку.
• Пагінація/фільтри створюють неканонічні URL.
• Посилання, створені через обробники кліків, а не

  <a href>

  , важче сканувати.

Google вважає dynamic rendering за user-agent workaround, а не довгострокове рішення; рекомендує SSR, static rendering або hydration . Тому нова архітектура не повинна покладатися лише на сервіс "рендеринг для ботів".

Правильне виправлення:

1. SSG/ISR для товарів, категорій, контенту та головної сторінки, щоб HTML мав контент одразу.
2. SSR для маршрутів, що потребують даних за запитом.
3. CSR лише для кошика, персоналізації та взаємодій після завантаження.
4. Генерація метаданих, canonical, JSON-LD Product/Breadcrumb/Organization на сервері.
5. Повернення справжніх 404/410 для неіснуючих ресурсів.
6. XML sitemap, robots policy, пагінація та редиректи при зміні slug.
7. Тестування через рендеринг HTML, Search Console та краулер без JS.

2.5 Супровід

Власний:

• Потрібно підтримувати фронтенд, бекенд, базу даних, адмінку, API контракти, платіжну інтеграцію, поштові завдання, кеш та деплой.
• Зміна поля може вплинути на багатьох клієнтів. Потрібні contract tests, зворотно сумісні міграції та спостережуваність.
• Плюс: лише необхідний код; не потрібно мати справу з конфліктами десятків плагінів. Команда володіє всім roadmap і може видаляти legacy.

WooCommerce:

• Основна комерційна логіка та адмінка підтримуються спільнотою/вендором, але потрібно оновлювати WordPress core, Woo, тему та плагіни.
• Кожне оновлення потребує тестування на staging, оскільки хуки, перевизначення шаблонів та сумісність плагінів можуть змінитися.

Висновок: Woo переносить витрати з "власної розробки домену" на "управління екосистемою"; власна розробка переносить витрати з ліцензій плагінів/сумісності на інженерну зарплату та експлуатацію.

2.6 Вартість хостингу

Невеликий Woo може працювати на одному managed WordPress хостингу з БД та CDN, що спрощує рахунки та експлуатацію. Власний SPA має дуже дешевий статичний фронтенд, але вся система все одно потребує API compute, базу даних, об'єктне сховище, пошту, черги, логи та бекапи.

Тому власна розробка не обов'язково дешевша. При низькому трафіку витрати на персонал та кількість сервісів часто перевищують витрати на compute. При високому читаючому трафіку статичний/edge рендеринг headless може значно зменшити навантаження на джерело.

2.7 Масштабованість

Власна розробка відокремлює фронтенд від бекенду, тому можна масштабувати CDN, read API, worker та БД незалежно. Це перевага, якщо трафік кампанії різко зростає або є багато каналів, що використовують один commerce API.

Але масштабування оформлення замовлення — це не лише додавання серверів. Транзакції БД, резервування інвентарю, idempotency платежів, порядок webhook та узгодженість кешу — ось що складно.

Woo може обслуговувати значний обсяг за умови хорошого хостингу, кешу, налаштування БД та невеликої кількості плагінів. Вузьким місцем часто є динамічні запити, meta таблиці, хуки плагінів та PHP worker. Для 16 товарів немає доказів, що поточний масштаб вимагає власних мікросервісів.

2.8 Залежність від плагінів та вендорів

Woo більше залежить від плагінів, якщо кожна функція додається через розширення; ризики: ліцензії, частота оновлень, покинуті плагіни та конфлікти хуків.

Власна розробка зменшує залежність від плагінів WordPress, але не усуває залежності: все одно потрібен фреймворк, npm пакети, хмара/CDN, PayPal SDK, поштовий провайдер та команда розробників. Це зміна типу залежності, а не її відсутність.

2.9 Таблиця рішень

2.10 Рекомендації щодо вибору

• Якщо мета: швидкий запуск, маленька команда, стандартні комерційні процеси, не потрібен унікальний UX — використовуйте традиційний WooCommerce з легкою темою, мінімумом плагінів, managed хостингом та хорошим кешем.
• Якщо мета: власний брендовий досвід, власний builder, інтеграція з багатьма каналами, команда має компетенції в бекенді/платежах — продовжуйте власну розробку, але замініть чистий SPA на фреймворк з SSR/SSG/ISR.
• Не рекомендується "headless Woo" лише заради сучасності, якщо все одно доведеться підтримувати і WordPress, і фронтенд без чітких потреб UI/каналів. Це поєднує витрати обох підходів.

Для цього сайту найбільш логічним напрямком є збереження підходу власної комерційної розробки, але переписування вітрини з використанням гібридного рендерингу, а не копіювання поточного SPA і не обов'язковий перехід на Woo. Причина: builder та брендовий UI вже є ключовими компетенціями; частини, які потребують виправлення — це рендеринг, модель даних, коректність оформлення замовлення та експлуатація.

3. Напрямки переписування

3.1 Принципи

Нова версія повинна використовувати бізнес-вимоги та дані, до яких власник має законний доступ, але не копіювати декомпільований bundle, структуру модулів, приватні символи або стару реалізацію.

Можна використати універсальні ідеї:

• каталог/категорія/деталі товару;
• головна сторінка з блоків;
• макет з header/footer/nav;
• купони, розсилка, контакти, відгуки, трекінг;
• PayPal create/approve/capture;
• рівні доставки та налаштування магазину.

Потрібно зробити новими:

• найменування маршрутів та обгортки відповідей;
• модель даних (variant/inventory);
• реєстр компонентів та схема builder;
• стратегія рендерингу;
• машина станів оформлення замовлення;
• інвалідація кешу;
• безпека, спостережуваність та тестовий набір.

3.2 Рекомендований стек

Вітрина (Storefront):

• Next.js App Router + React + TypeScript для серверних компонентів, SSR, статичної генерації/ISR та клієнтських компонентів для інтерактивних зон.
• Zod для валідації контрактів на межі.
• TanStack Query лише для серверного стану, який потребує оновлення на клієнті; не перезапитувати дані, які вже відрендерені.
• CSS Modules/Tailwind або система дизайн-токенів; вибрати одну і обмежити runtime CSS-in-JS.
• Оптимізація зображень через CDN/об'єктне сховище з чіткими width/format.

Next.js — не єдиний варіант; Remix або аналогічний SSR фреймворк також підходять. Ключові критерії: HTML, відрендерений на сервері, правильні статус-коди, контрольований кеш та мінімум JS на клієнті, а не назва фреймворку.

Бекенд:

• NestJS з Fastify адаптером + TypeScript, або модульний Fastify, якщо команда віддає перевагу меншій абстракції.
• PostgreSQL як єдине джерело правди.
• Drizzle ORM або Prisma для міграцій та типобезпечних запитів; транзакції оплати/інвентарю все одно потребують ручного проєктування.
• Redis лише якщо дійсно потрібен кеш, розподілене блокування або rate-limit; не додавати Redis з першого дня, якщо одного екземпляра та невеликого трафіку достатньо.
• BullMQ/аналогічна черга для email, повторної обробки webhook, аналітики та reconciliation.
• S3-сумісне об'єктне сховище для медіа; база даних зберігає лише метадані/ключі.
• OpenTelemetry + структуровані логи + трекінг помилок для з'єднання запиту, оформлення замовлення та спроби оплати.

Деплой:

• Вітрина за CDN/edge кешем.
• API запускається в окремому контейнері/сервісі.
• PostgreSQL managed з point-in-time recovery.
• Об'єктне сховище окремо від файлової системи контейнера.
• Preview/staging використовують PayPal sandbox та окрему базу даних.
• Секрети через secret manager, а не в репозиторії.