Почнемо з чесного визнання
WooCommerce — це, без перебільшень, одна з найпотужніших e-commerce платформ у світі. За 10+ років розвитку екосистема плагінів і інтеграцій виросла настільки, що на WooCommerce сьогодні будують і невеликі магазини на 50 товарів, і серйозні e-commerce проєкти з тисячами SKU, маркетплейс-функціоналом, мультивалютністю, складними знижками й інтеграціями з ERP. Практично будь-яку "стандартну" бізнес-задачу магазину WooCommerce вирішує — і вирішує добре.
Те саме частково стосується й інших рішень на ринку — той-таки Shopify чи Tilda закривають свої ніші: Tilda чудово підходить для простих лендінгів і невеликих каталогів, де головне — швидко запуститись і мати мінімум технічного обслуговування.
Тому ця стаття — не про те, що "WooCommerce поганий, а Payload+Next.js хороший". Це не так. Стаття про інше: є вузька, але цілком реальна категорія проєктів, для яких навіть найкраще налаштований WooCommerce перестає бути правильним фундаментом — і чому в таких випадках ми переходимо на зв'язку Payload CMS + Next.js.
Де саме проходить межа
WooCommerce будується поверх WordPress, а це означає, що архітектурно він успадковує і сильні сторони WordPress (величезна екосистема, легкий контент-менеджмент), і його обмеження (структура даних заточена під пости й сторінки, а не під складні бізнес-сутності; продуктивність під навантаженням залежить від якості хостингу й кількості плагінів; будь-яка нестандартна логіка, як правило, реалізується через додаткові плагіни, кожен з яких — це окрема точка відмови).
Для 95% магазинів це не проблема — навантаження і бізнес-логіка вкладаються в те, що плагіни й хуки WordPress дозволяють зробити. Але є конкретний, вузький набір задач, де ця архітектура починає тиснути:
- Дуже важке й нестандартне API — коли магазин має живити не тільки сайт, а й мобільний застосунок, кілька зовнішніх сервісів, партнерські інтеграції, і всі вони мають різні вимоги до формату даних і швидкості відповіді.
- Мультисинхронізація в реальному часі — коли залишки, ціни й статуси замовлень мають одночасно й миттєво синхронізуватись між кількома складами, ERP-системою, маркетплейсами (Prom, Rozetka, Allegro) і CRM, причому з обробкою конфліктів і чергами подій.
- Дуже складна бізнес-логіка процесів — багатоступеневі workflow погодження замовлень, динамічне ціноутворення за десятками правил, індивідуальні B2B-прайси для сотень контрагентів з різними умовами.
- Екстремальні вимоги до продуктивності на масштабі — мільйони товарних позицій, тисячі одночасних користувачів, де кожна мілісекунда відгуку API критична.
Це саме та категорія проєктів, де рішення "візьмемо WooCommerce і будемо доробляти плагінами" стає дорожчим і крихкішим, ніж побудова окремого бекенду під конкретні задачі. Таких проєктів дійсно небагато — але вони існують, і власники таких магазинів зазвичай самі відчувають, що вперлися в стелю.
Що стосується OpenCart — тут ситуація трохи інша: сама платформа менш активно розвивається, спільнота плагінів помітно вужча, ніж у WooCommerce, а якість багатьох розширень нерівна. Тому поріг, після якого доцільніше перейти на кастомну архітектуру, для OpenCart настає значно раніше, і навіть середньої складності проєкти на ньому часто виграють від переходу на headless-рішення.
Що дає Payload CMS + Next.js у таких випадках
Payload — headless CMS на Node.js/TypeScript, яка по суті є фреймворком для побудови бекенду: моделі даних, поля, зв'язки, права доступу, хуки на будь-яку подію пишуться як звичайний код у вашому репозиторії, а не налаштовуються через сторонні плагіни. Це дає кілька речей, критичних саме для описаної вище категорії проєктів:
1. Потужне, повністю кастомне API. REST і GraphQL з коробки, і будь-яка додаткова точка входу для мобільного застосунку чи партнерської інтеграції пишеться напряму, без прошарку сумісності з чужим плагіном.
2. Ланцюжки подій без сторонніх залежностей. Наприклад, afterChange hook на колекції Orders може одночасно: створити накладну через API Нової Пошти, відправити SMS через TurboSMS, оновити залишки на кількох складах і засинхронізувати статус у CRM — усе одним контрольованим ланцюжком, який ми самі спроєктували й самі тестуємо.
3. Адмінка, яка проєктується під конкретні процеси компанії, а не підганяється під те, що дозволяє чужий движок: свої поля, свої ролі, свої масові дії, свої дашборди.
4. Фронтенд на Next.js без компромісів у швидкості й SEO — SSR/ISR, тонке налаштування структурованих даних, контроль над кожним байтом, що йде в браузер, і показники Core Web Vitals, яких важко досягти на важкому CMS-стеку з десятками плагінів.
Підсумок
Якщо у вас типовий інтернет-магазин, навіть із серйозними оборотами, — WooCommerce, найімовірніше, залишається розумним і надійним вибором, і переписувати його на кастомну архітектуру заради самої архітектури сенсу немає. Але якщо ваш бізнес впирається саме в ту вузьку категорію задач — важке мультисистемне API, складна логіка, синхронізація в реальному часі на масштабі — варто розглянути Payload CMS + Next.js як фундамент, який будується під вас, а не навпаки.