Własny integrator czy gotowe narzędzie - jak podjąć decyzję
Wybór między własnym middleware a gotowym integratorem to decyzja o tym, kto utrzymuje logikę: dostawca narzędzia czy Twój zespół. Gotowe rozwiązanie daje szybki start, aktualizacje integracji i wsparcie, ale wymaga dopasowania procesów do jego możliwości. Własny integrator dopasowuje się do procesów, ale wymaga programisty na stałe. Najprostsza reguła decyzji:
[#chart:wpr31b]
| Kryterium | Gotowy integrator | Własny middleware |
|---|
| Czas wdrożenia | Dni lub tygodnie, głównie konfiguracja | Tygodnie lub miesiące, projekt i programowanie |
| Koszt startowy | Niski, abonament | Wyższy, praca programistów |
| Koszt stały | Abonament rosnący ze skalą | Serwer, monitoring, utrzymanie kodu |
| Nietypowe reguły | W granicach ustawień narzędzia | Dowolne, zgodnie z procesem firmy |
| Zmiany w API kanałów | Aktualizuje dostawca | Aktualizuje Twój zespół lub partner |
| Zależność | Od dostawcy narzędzia | Od jakości kodu i dokumentacji |
Częstym i rozsądnym wariantem jest model mieszany: gotowy integrator obsługuje standardowe kanały, a mały własny serwis dopisuje tylko brakującą część, np. połączenie z ERP albo regułę cen. Podobny dylemat opisujemy na przykładzie jednego kanału we wpisie integracja WooCommerce z Allegro - wtyczka czy własne rozwiązanie.
Jak zaprojektować własny middleware między sklepem, ERP i marketplace
Dobrze zaprojektowany middleware jest nudny: robi swoje, zapisuje wszystko, co zrobił, i głośno informuje o błędach. Źle zaprojektowany potrafi przez kilka dni gubić zamówienia bez śladu. Kilka zasad, które stosujemy przy projektowaniu warstwy pośredniej:
Jedno źródło prawdy dla każdego typu danych - np. produkty i ceny w ERP, zamówienia w marketplace i sklepie, stany w WMS. Middleware nie powinien sam „wymyślać” danych.
Kolejka zamiast bezpośrednich wywołań - każde zdarzenie trafia do kolejki i jest przetwarzane osobno, więc awaria ERP nie blokuje pobierania zamówień.
Idempotencja - ponowne przetworzenie tego samego zdarzenia nie tworzy drugiego dokumentu ani drugiej przesyłki.
Ponawianie i limity - błąd sieci lub przekroczony limit zapytań oznacza ponowienie z opóźnieniem, a nie utratę danych.
Dziennik i alerty - każda operacja ma zapis, a błędy trafiają do osoby, która może je naprawić.
Mapowania w konfiguracji - statusy, magazyny, metody wysyłki i stawki VAT w tabelach, nie w kodzie.
Przy marketplace'ach warto korzystać z mechanizmów zdarzeń, jeśli platforma je udostępnia. Allegro REST API ma dziennik zdarzeń zamówień dostępny pod GET /order/events, a szczegóły zamówienia pobiera się z GET /order/checkout-forms/{id} (stan na styczeń 2026 - sprawdź aktualną dokumentację Allegro). Middleware zapamiętuje identyfikator ostatniego przetworzonego zdarzenia i przy kolejnym zapytaniu pobiera tylko nowe. WooCommerce i wiele innych platform sklepowych wysyła webhooki, czyli powiadomienia o nowych zamówieniach, które middleware przyjmuje i odkłada do kolejki.
Osobna kwestia to technologia. Middleware może być małym serwisem w PHP, Node.js lub Pythonie, uruchamianym na serwerze VPS albo w chmurze. Ważniejsze od języka jest to, czy zespół, który będzie go utrzymywał, zna wybraną technologię, i czy kod ma testy oraz dokumentację przepływów. Przykład minimalnego rekordu zdarzenia w kolejce: {"source": "allegro", "type": "order.created", "externalId": "abc-123", "attempts": 0}. Z takiego rekordu da się odtworzyć, co, skąd i ile razy było przetwarzane.
Elementy, z których zwykle składa się taka warstwa:
[#chart:wpr31c]
Jak sprawdzić, czy wystarczy gotowy integrator
Zanim zapadnie decyzja o własnym integratorze, warto przejść krótki audyt obecnych połączeń. Dla każdego przepływu - zamówienia, stany, ceny, dokumenty, przesyłki, zwroty - zapisz, skąd dane wychodzą, dokąd trafiają, jak często i co dzieje się, gdy coś pójdzie nie tak. Potem zaznacz, które przepływy działają bez ręcznej pracy, które wymagają poprawek i których nie ma wcale.
Przy każdej luce sprawdź trzy rzeczy. Po pierwsze, czy obecny integrator nie ma funkcji, której nikt nie skonfigurował - to zaskakująco częsta przyczyna. Po drugie, czy producent ERP lub marketplace'u nie udostępnia gotowego modułu albo nowszej wersji API, która rozwiązuje problem. Po trzecie, czy lukę da się zamknąć małym, osobnym skryptem lub automatyzacją, bez przebudowy całej architektury. Dopiero gdy odpowiedź na wszystkie trzy pytania brzmi „nie”, a luka dotyczy kluczowego procesu, własny middleware staje się realną opcją.
Taki audyt ma jeszcze jedną zaletę: daje gotową specyfikację. Lista przepływów z opisem danych, częstotliwości i wyjątków to dokładnie to, czego programista potrzebuje do wyceny i projektu. Bez niej każda oferta na własny integrator jest zgadywaniem, a różnice między wycenami wynikają głównie z tego, jak różni wykonawcy wyobrażają sobie Twój proces.
Ile kosztuje i ile trwa budowa własnego middleware
Koszt własnego integratora zależy od liczby połączonych systemów, liczby przepływów i jakości dokumentacji API po drugiej stronie. Połączenie z dobrze udokumentowanym REST API marketplace'u jest przewidywalne. Połączenie ze starszym ERP, który wymienia dane przez pliki lub bazę danych, potrafi zająć więcej czasu niż cała reszta projektu. Dlatego wycenę zaczyna się od listy przepływów, a nie od listy systemów.
Do kosztu budowy trzeba doliczyć koszty stałe: serwer, kopie zapasowe, monitoring i godziny programisty na zmiany. Platformy regularnie zmieniają API, wprowadzają nowe pola i wycofują stare zasoby. Gotowy integrator robi to za Ciebie w ramach abonamentu, a przy własnym middleware odpowiedzialność za dostosowanie jest po Twojej stronie. Uczciwe porównanie zestawia więc koszt abonamentu z sumą budowy i kilku lat utrzymania.
Rozsądnie jest budować etapami. Najpierw jeden przepływ o największej wartości, np. zamówienia z marketplace do ERP, uruchomiony równolegle z obecnym rozwiązaniem. Dopiero gdy działa stabilnie, dodaje się stany, ceny, dokumenty i kolejne kanały. Taki plan ogranicza ryzyko i szybko pokazuje, czy szacunki były trafne.
Przed startem warto też ustalić zasady utrzymania. Kto reaguje, gdy integracja zatrzyma się w sobotę wieczorem? W jakim czasie trzeba dostosować kod, gdy marketplace ogłosi zmianę w API? Gdzie są przechowywane klucze dostępu i kto może je odnowić? Odpowiedzi na te pytania warto spisać w umowie serwisowej albo w wewnętrznej procedurze. Middleware, który działa świetnie przez pół roku, a potem staje na kilka dni, bo nikt nie odnowił tokenu albo nie zauważył zmiany w API, kosztuje więcej niż najdroższy abonament gotowego narzędzia.
Najczęstsze błędy przy budowie własnego integratora
Projekty middleware rzadko upadają z powodu technologii. Zwykle problemem jest organizacja i brak decyzji, które powinny zapaść przed pierwszą linijką kodu:
brak właściciela procesu - nikt po stronie firmy nie decyduje, które dane są prawidłowe, gdy systemy się różnią,
przeniesienie bałaganu - middleware kopiuje istniejące obejścia zamiast je uprościć,
brak środowiska testowego - zmiany trafiają od razu na produkcję, bo nie ma sandboxa ani kopii ERP,
ciche błędy - integracja nie wysyła alertów, więc problem wychodzi dopiero przy reklamacji klienta,
jeden programista - cała wiedza w głowie jednej osoby, bez dokumentacji i dostępu do repozytorium po stronie firmy.
[#uwaga] Zadbaj, żeby kod, repozytorium, dostęp do serwera i klucze API należały do Twojej firmy, a nie do wykonawcy. Ustal to w umowie przed startem projektu. Bez tego własny middleware staje się zależnością od jednej osoby lub firmy, czyli dokładnie tym, czego chciałeś uniknąć, rezygnując z gotowego narzędzia.
Warto też pamiętać o procesach, które łatwo pominąć na etapie projektu: korektach zamówień, zwrotach, anulacjach i zmianach adresu po zakupie. To one generują najwięcej wyjątków. Podobnie jest z wysyłką - jeśli middleware ma zamawiać kuriera, sprawdź, czy lepiej podłączyć go do agregatora, o czym piszemy we wpisie integracja z kurierami przez API.
Jak Vinson pomaga przy middleware i integracjach
Programiści Vinson zaczynają od mapy przepływów danych między sklepem, ERP, magazynem i marketplace'ami. Na tej podstawie doradzamy, czy wystarczy konfiguracja integratora, mały dodatek do niego, czy własny middleware. Jako certyfikowany partner Base i autoryzowany partner Shoper znamy możliwości gotowych narzędzi, więc nie budujemy od zera tego, co da się skonfigurować. Gdy własna warstwa jest uzasadniona, projektujemy ją z kolejką, dziennikiem, alertami i dokumentacją, a kod przekazujemy firmie. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.
Najczęściej zadawane pytania
Co to jest middleware w e-commerce?
Middleware w e-commerce to warstwa pośrednia między sklepem, ERP, magazynem i marketplace'ami. Pobiera dane z jednego systemu, przetwarza je według reguł firmy i przekazuje do drugiego. Może to być gotowy integrator albo własny serwis zbudowany dla jednej firmy.
Kiedy warto zbudować własny integrator zamiast kupić gotowy?
Gdy gotowe narzędzia nie obsługują kluczowych reguł firmy, ERP nie ma gotowego połączenia, a ręczne poprawki i abonamenty kosztują więcej niż budowa i utrzymanie własnego kodu. Przy prostym sklepie z jednym marketplace gotowy integrator zwykle wystarcza. Dobrym kompromisem jest gotowe narzędzie uzupełnione małym własnym serwisem.
Ile trwa wdrożenie własnego middleware?
To zależy od liczby przepływów i jakości API po drugiej stronie, zwłaszcza w ERP. Pierwszy przepływ, np. zamówienia z marketplace do ERP, można uruchomić szybciej niż cały system. Bezpieczniej jest budować etapami i uruchamiać nowe przepływy równolegle z obecnym rozwiązaniem.
W jakiej technologii buduje się middleware dla sklepu?
Najczęściej jest to serwis w PHP, Node.js lub Pythonie z kolejką zadań i bazą danych, uruchamiany na serwerze lub w chmurze. Wybór języka jest mniej ważny niż to, czy zespół potrafi go utrzymać, a kod ma testy i dokumentację. Kluczowe są kolejka, ponawianie, dziennik operacji i alerty.
Czy własny middleware zastąpi Base lub inny integrator?
Może, ale nie zawsze powinien. Gotowy integrator aktualizuje połączenia z kanałami i daje panel dla zespołu, czego własny middleware nie ma bez dodatkowej pracy. Często lepiej zostawić integrator do standardowych kanałów i dopisać własną warstwę tylko tam, gdzie go brakuje.
Własny middleware między sklepem, ERP i marketplace to inwestycja, która zwraca się tylko przy jasno opisanych przepływach i dobrym utrzymaniu. Jeśli chcesz sprawdzić, czy w Twojej firmie wystarczy konfiguracja, czy potrzebna jest własna warstwa integracji, zobacz wsparcie programistyczne Vinson i opisz nam swoje systemy.
