Розробка інтернет-магазину

Розробка інтернет-магазину

Інтернет-магазин — це не шаблон з корзиною та формою оплати. Це операційна система для бізнесу: управління складом, ціноутворення, логістика, маркетинг, аналітика — все це має працювати узгоджено та без ручного втручання там, де його можна уникнути. Розробка починається з розуміння бізнес-моделі, а не з вибору движка.

Вибір технологічного стеку

Питання «на чому робити» вирішується на основі трьох чинників: об'єм каталогу, сценарії інтеграцій, планована нагрузка. Типові варіанти:

Для більшості проектів середнього розміру оптимален монліт з чіткими границами модулів — швидше в розробці, простіше в підтримці.

Каталог та структура даних

Модель даних каталогу визначає все інше. Поширена помилка — робити таблицю products з колонками color, size, material напрямую. Це працює до першого нестандартного товару.

Правильний підхід: EAV (Entity-Attribute-Value) або JSONB-атрибути в PostgreSQL. Приклад схеми:

products (id, sku, slug, base_price, status)
product_variants (id, product_id, sku, price_delta, stock)
variant_attributes (variant_id, attribute_id, value)
attributes (id, name, type, filterable, sortable)

Для каталогів з різнородними товарами (електроніка + одяг + меблі) використовуємо product types — кожен тип задає власний набір атрибутів. Саме так працює Akeneo PIM, який підключається при каталогах від 10 000 SKU.

Пошук та фільтрація

Стандартний SQL-пошук LIKE '%запрос%' не годится навіть для каталогу на 500 позицій — нема релевантності, нема морфології, нема синонімів. Опції:

• PostgreSQL FTS з ts_vector — підходить до ~5 000 товарів, настройка під російський язык через ispell або hunspell
• Elasticsearch / OpenSearch — full-featured: нечіткий пошук, буст по полям, синоніми, перколятор для «схожих товарів»
• Typesense — простіше в експлуатації, гарно для невеликих команд

Фільтри по атрибутам будуємо через агрегації Elasticsearch: користувач бачить тільки ті значення фільтрів, які дадуть ненульовий результат. Це називається faceted search — стандарт для ecommerce.

Корзина та чекаут

Корзина — місце, де теряється 60–80% конверсії. Критичні рішення:

Гостева корзина зберігається в Redis з TTL 30 днів, при авторизації мержується з серверною. Без гостевої корзини реєстрація стає бар'єром.

Чекаут в один екран статистично краще багатошагового для B2C. Для B2B навпаки — потрібні кроки: реквізити, адреса доставки, затвердження менеджера.

Розрахунок доставки в реальному часі: API СДЕК, Boxberry, Nova Poshta, DHL. Ставки залежать від ваги, габаритів, точки відправлення — це вичисляється на льоту, не зберігається в таблиці.

Платіжний шлюз: Stripe для міжнародних, CloudPayments / ЮKassa для РФ/СНГ, Fondy / WayForPay для України. Інтеграція йде через webhook-підтвердження, статус замовлення змінюється тільки після верифікації підпису.

Управління замовленнями

Життєвий цикл замовлення — це кінцевий автомат (state machine). Стани: draft → pending_payment → paid → processing → shipped → delivered → completed. Плюс бічні гілки: cancelled, refunded, on_hold.

Бібліотеки: winzou/state-machine для Laravel, xstate якщо частина логіки на фронте. Кожен перехід стану — подія, яка тригерить повідомлення (email, SMS, push), оновлення складу, запис в лог.

Інтеграції

Типовий набір для повноцінного магазину:

• 1С / МойСклад / Retailio — синхронізація остатків та цін. Обычно через чергу (RabbitMQ/Redis Queue) з інтервалом 5–15 хвилин
• CRM (AmoCRM, HubSpot) — автоматична передача замовлень та лідів
• Email-маркетинг (Klaviyo, Mailchimp, Sendpulse) — тригерні ланцюжки: покинута корзина, постпродажа, реактивація
• Аналітика: GA4 з Enhanced Ecommerce + серверний GTM для точних даних без впливу блокувальників реклами

Продуктивність та SEO

Сторінки каталогу мають кешуватися. Стратегія: stale-while-revalidate — повертаємо кеш немедленно, оновлюємо у фоні. Redis для серверного кешу, CDN (Cloudflare) для статики.

SEO-специфіка ecommerce:

• Канонічні URL для сторінок з фільтрами — без цього пошукувачи бачать тисячи дублів
• hreflang для мультимовних магазинів
• Schema.org розмітка: Product, Offer, AggregateRating — впливає на rich snippets у виданні
• Пагінація через rel="next"/"prev" або нескінченна прокрутка з SSR-рендером першого екрану

Терміни та етапи

Типовий інтернет-магазин середнього масштабу (1 000–10 000 SKU, стандартний чекаут):

• Аналітика та проектування — 2–3 тижні: ТЗ, wireframes, схема даних, вибір інтеграцій
• Бекенд: каталог + корзина + замовлення — 4–6 тижнів
• Фронтенд — 4–6 тижнів паралельно або послідовно
• Інтеграції (1С, платіжка, доставка) — 2–4 тижні
• Тестування та запуск — 1–2 тижні

Итого: 12–20 тижнів для повноцінного проекту без готових шаблонів. Проекти на Shopify з мінімальними кастомізаціями — 4–8 тижнів.

Ключовий принцип: інтернет-магазин запускається не тоді, коли готово всё, а тоді, коли готово достатньо для перших продажів. Решта — ітерації.