Middleware vs. integracje bezpośrednie - kiedy co ma sens

W skrócie

• 1. Bezpośrednio: sklep komunikuje się wprost z każdym systemem (ERP, PIM, BaseLinker, płatności)
• 2. Middleware: warstwa pośrednia między sklepem a systemami - sklep rozmawia tylko z middleware
• 3. Bezpośrednio ma sens: do 2-3 systemów zewnętrznych, stabilne API, mała skala
• 4. Middleware ma sens: 3+ systemów, niestabilne API, plany rozwoju
• 5. Koszt: middleware to +20-30% inwestycji wstępnej, oszczędność 50%+ w utrzymaniu
• 6. Najczęstszy błąd: zaczynanie „bezpośrednio bo prościej", przebudowa po roku

Bezpośrednio - jak to wygląda

[Sklep]
  |
  +-- ERP_module → API Comarch XL
  +-- BaseLinker_module → API BaseLinker
  +-- PIM_module → API Akeneo
  +-- Payment_module → PayU API
  +-- Shipping_module → InPost API
  |
  (każdy moduł ma własne kolejki, własny error handling, własne mapowania)

Każdy moduł w sklepie zna szczegóły konkretnego systemu zewnętrznego. Transformacje danych, kolejki, retry, mapowania - wszystko po stronie sklepu.

Plusy:

• Najszybszy start (mniej kodu do napisania)
• Mniej infrastruktury (nie ma osobnego serwera middleware)
• Łatwiejszy debugging na początku (jedno repozytorium, jeden stack)

Minusy:

• Logika integracji rozjeżdża sklep (kontrolery puchną, moduły zaczynają się przenikać)
• Każdy nowy system zewnętrzny = release sklepu
• Zmiana w API jednego systemu = potencjalne side-effecty na inne
• Drugi sklep (np. wersja DACH) = duplikacja całej logiki

Middleware - jak to wygląda

[Sklep PL]  [Sklep DE]  [Allegro]
    |          |           |
    +----------+-----------+
                |
                v
          [Middleware]  <-- jeden serwis, jedne mapowania, jedne kolejki
                |
        +-------+-------+--------+-------+
        |       |       |        |       |
       [XL]   [Akeneo] [BaseL.] [PayU] [InPost]

Middleware:

• Wystawia REST API dla sklepów
• Trzyma logikę transformacji per system
• Trzyma kolejki, retry, monitoring
• Może być wielofunkcyjny (jeden middleware dla wszystkich integracji) lub specjalizowany (osobne mikrosegmenty)

Plusy:

• Sklep nie wie nic o ERP, BaseLinkerze, PIM
• Zmiana ERP-a (np. migracja XL → enova) = tylko middleware się zmienia
• Drugi sklep = drugi klient middleware, ta sama warstwa integracji
• Centralny monitoring, łatwiej obserwować co się dzieje

Minusy:

• Więcej kodu na start (sklep + middleware vs. tylko sklep z modułami)
• Więcej infrastruktury (osobny serwer / serwery middleware)
• Złożoność operacyjna (deploy 2 serwisów zamiast 1)
• Trochę dłuższy debugging na początku (gdzie szukać błędu - sklep czy middleware)

Kiedy bezpośrednio realnie wystarczy

Trzy warunki, wszystkie muszą być spełnione:

1. Mało systemów zewnętrznych - maksymalnie 2-3. Np. tylko ERP + płatności + kurier. Wtedy logika w sklepie jeszcze nie wybucha.

2. Stabilne, dobrze udokumentowane API po stronie systemów zewnętrznych. Comarch XL z REST API - relatywnie stabilne. Stary XL z SOAP - już niekoniecznie. SAP - generalnie ok. Subiekt GT przez Sferę - niestabilne.

3. Mała skala i krótka perspektywa. Sklep robi 100 zamówień / dzień, plan jest „wpada w 2 lata na pełne obroty albo pivot". Wtedy bezpośrednio = szybki start, krótkoterminowa decyzja.

Dla typowego polskiego B2B z 5+ systemami zewnętrznymi i ambicjami wzrostu - bezpośrednio przegrywa już na starcie. Nie zaoszczędzisz tyle, ile wydasz na refaktor.

Kiedy middleware jest must-have

Każdy z tych punktów osobno wystarcza:

1. 3+ systemy zewnętrzne. Sklep + ERP + PIM + OMS + BaseLinker = 4 integracje. Bez middleware kontrolery sklepu nie wytrzymają.

2. Niestabilne API po jednej ze stron. XL ma timeoutowane SOAP-y, Sfera Subiekta padnie raz w tygodniu, ERP klienta jest aktualizowany co kwartał. Middleware z kolejkami i retry to ratunek.

3. Plany ekspansji. Drugi sklep (DACH), drugi rynek, drugi brand. Middleware = nie powtarzasz integracji.

4. Konieczność transformacji danych. ERP ma swoje słowniki (kategorie, jednostki, ceny), sklep ma swoje, marketplace mają swoje. Mapowania w jednym miejscu = sanity.

5. Wymóg observability. Klient chce wiedzieć co się dzieje w integracjach (które padły, ile, kiedy). Middleware = jeden dashboard. Bez middleware = logi rozsiane po sklepie.

6. Skala wymuszająca asynchroniczność. 10k+ zamówień dziennie, kolejki, batche, retry. To naturalna rola middleware.

Co konkretnie middleware robi

Po stronie technicznej:

Routing. Sklep wysyła OrderCreated. Middleware wie, że to idzie do ERP (utworzenie dokumentu), do PIM (decremental stock), do BaseLinkera (synchronizacja stanów z marketplace'ami). Wszystko z jednego eventu.

Transformacja danych. Sklep ma customer_id = 12345. ERP oczekuje kontrahent_id = "K00012345". Middleware wie.

Kolejki. Każde wywołanie idzie przez RabbitMQ / Redis. Sklep nie czeka aż ERP odpowie - middleware kolejkuje. Kolejki RabbitMQ i Redis.

Retry z exponential backoff. ERP padł na 4 minuty? Middleware retryuje 1s, 2s, 4s, 8s, 16s, aż uda się lub trafi do DLQ.

Idempotencja. Sklep wysyła to samo zamówienie drugi raz (race condition, retry sklepu). Middleware widzi external_id, nie tworzy duplikatu.

Monitoring. Sentry, Datadog, dedykowany dashboard. Liczba transakcji, retry rate, opóźnienia, błędy per system.

Webhook hub. Webhooki z systemów zewnętrznych (XL → middleware → sklep). Centralna autentykacja, monitoring.

Technologie do middleware

Opcja 1: Custom w PHP/Symfony lub Node.js.

Najczęściej dla polskich średnich B2B. Symfony Messenger + RabbitMQ + Redis + PostgreSQL/MySQL. Czas budowy: 6-12 tygodni dla solidnej bazy. Plus: full kontrola, własny zespół to utrzymuje. Minus: budujesz sam.

Opcja 2: iPaaS (Integration Platform as a Service).

• n8n - open-source workflow automation, polskie B2B coraz częściej używa
• Make (dawne Integromat) - komercyjny, wizualne workflow
• Zapier - głównie B2C i drobne firmy
• Tray.io - bardziej enterprise

iPaaS dobre dla integracji „w mniejszej skali" (kilkaset transakcji dziennie). Dla 10k+ - własny middleware zazwyczaj wygrywa.

Opcja 3: ESB / Integration Platform (klasyka enterprise).

• Mulesoft (Salesforce) - bardzo drogi (od kilkuset tys. zł rocznie)
• Boomi (Dell) - średnio droższy
• WSO2 - open-source ESB
• Apache Camel (Java) - open-source library

To dla bardzo dużych firm. W polskim B2B średnim segmencie rzadko sensowne.

Opcja 4: Komercyjne polskie integratory.

• Comarch Webcon / BPM Suite - orientacja na Comarch ekosystem
• Comarch EDI - dla EDI
• Mniejsi gracze branżowi

Dla scenariuszy zdominowanych przez Comarcha - czasem ma sens. Dla mixu różnych ERP-ów - własny middleware.

Koszt obu podejść

Dla typowego średniego polskiego B2B (sklep + 4 zewnętrzne integracje):

Bezpośrednio:

• Wdrożenie integracji: 200-400 tys. zł (każda integracja w sklepie)
• Utrzymanie roczne: 60-150 tys. zł
• Refaktor po 2 latach (jeśli skala rośnie): 150-400 tys. zł

Middleware (custom Symfony/Node):

• Wdrożenie middleware (baza): 80-200 tys. zł
• Wdrożenie integracji w middleware: 200-400 tys. zł
• Sklep jako klient middleware: 50-120 tys. zł
• Utrzymanie roczne: 50-120 tys. zł
• Skalowanie: dokładasz integracje za 20-60 tys. zł każda

Wniosek: middleware kosztuje więcej w pierwszym roku (~25-35% więcej), ale w roku 3 jest taniej w utrzymaniu i bez refaktoru.

Najczęstsze błędy

1. Middleware „bo nowoczesne" przy małej skali. Sklep 1k SKU + 1 ERP + płatności - middleware to nadinżynieria.

2. Bezpośrednio „bo prościej" przy dużej skali. Sklep 50k SKU + 5 systemów - bezpośrednio kończy się po roku.

3. Mixanie obu podejść bez planu. Część integracji w sklepie, część w middleware, brak granic - najgorsza opcja, kod rozjeżdża się szybciej niż w obu czystych podejściach.

4. Middleware jako „warstwa cienka". Tylko routing bez transformacji, retry, kolejek = niedokończony middleware, problemy obu opcji + złożoność.

5. Zakładanie iPaaS skalowalności. n8n czy Make działają świetnie do pewnej skali. Powyżej (rzędy 10k transakcji / mies.) - łapią opóźnienia, awarie, koszt rośnie.

FAQ

Czy mogę zacząć bezpośrednio a potem dodać middleware? Tak, ale refaktor jest kosztowny (150-400 tys. zł). Lepiej decyzję podjąć od początku z perspektywą 3-5 lat.

Czy middleware musi być w innej technologii niż sklep? Nie. Często jest w tej samej (Symfony jeśli sklep Symfony, Node jeśli Node). Ważne, żeby był osobnym deploymentem.

Czy iPaaS (n8n, Make) wystarczy dla średniego B2B? Do ok. 3-5k transakcji dziennie i prostych integracji - tak. Powyżej - własny middleware. Wiele firm zaczyna od n8n i przechodzi na custom w roku drugim.

Czy middleware potrzebuje własnej bazy danych? Tak, do trzymania mapowań, idempotency keys, logów. Może to być PostgreSQL, MySQL, MongoDB - zależnie od stacku.

Czy mogę używać Symfony Messengera jako middleware? Tak. Symfony Messenger + RabbitMQ (lub Doctrine transport) + osobna aplikacja = solidna podstawa middleware dla średniej skali.

Co dalej

• Integracje konkretnych ERP-ów: Comarch XL, SAP
• Kolejki w architekturze: RabbitMQ i Redis
• Pełna architektura dużego sklepu: pillar /architektura-duzych-sklepow
• Pełny przegląd integracji: pillar /integracje