Shopify Next Generation Events: granularne webhooki z GraphQL

Problem tradycyjnych webhooków Shopify

Każdy, kto budował integrację ERP lub PIM na Shopify, zna ten problem: za każdym razem gdy produkt zostaje zaktualizowany, webhook wysyła cały payload, nawet jeśli zmieniło się tylko jeden tag lub metafield nieistotny dla systemu odbierającego.

To generuje trzy konkretne nieefektywności:

• Wysoki wolumen niedającymi się przetworzyć dostarczeń, które pochłaniają zasoby sieciowe i obliczeniowe
• Strukturalny over-fetching, z niepotrzebnymi polami przesyłanymi przy każdym zdarzeniu
• Aplikacyjna logika diff, konieczna do ustalenia co faktycznie zmieniło się względem poprzedniego stanu

Next Generation Events, dostępne teraz w developer preview w Shopify Admin GraphQL API, adresują te trzy problemy bezpośrednio.

Trzy wymiary granularnej kontroli

Nowy system wprowadza kontrolę na trzech odrębnych poziomach: co wyzwala dostarczenie, co zawiera payload i co się zmieniło.

1. Triggery na poziomie pól

Dzięki Next Generation Events można zdefiniować subskrypcję na konkretnej ścieżce, takiej jak product.variants.price. Subskrypcja skonfigurowana w ten sposób nie uruchamia się przy zmianach tytułu, tagów ani innych pól – aktywuje się wyłącznie gdy zmienia się cena wariantów.

To eliminuje u źródła kategorię fałszywych dostarczeń, bez konieczności stosowania filtrów po stronie aplikacji.

2. Spersonalizowany payload przez zapytanie GraphQL

Zamiast otrzymywać stały payload określony przez Shopify, w nowym systemie definiuje się bezpośrednio zapytanie GraphQL wypełniające każde dostarczenie. Efekt jest taki, że każde zdarzenie zawiera dokładnie te pola potrzebne do przetworzenia, bez zbędnych danych i bez konieczności dodatkowego wywołania API w celu pobrania brakujących informacji.

Dla integracji, które dziś stosują wzorzec webhook + wywołanie API wzbogacające, oznacza to wyraźną redukcję liczby żądań kierowanych do API Shopify.

3. Pole fields_changed

Każde dostarczenie zawiera teraz pole fields_changed z jawną listą zmodyfikowanych ścieżek, wraz z pełną ścieżką i ID encji. To sprawia, że wszelka logika porównywania z poprzednim stanem w kodzie aplikacji staje się zbędna.

Zamiast utrzymywać lokalny snapshot encji i obliczać diff przy każdym zdarzeniu, system odbierający może bezpośrednio odczytać które pola uległy zmianie i odpowiednio zareagować.

query_filter: ograniczenie niedającymi się przetworzyć dostarczeń

Dodatkowym mechanizmem kontroli jest query_filter, który pozwala filtrować dostarczenia na podstawie aktualnego stanu encji w momencie zdarzenia. Typowy przykład: dostarczanie zdarzeń tylko dla produktów ze statusem ACTIVE, z pominięciem wersji roboczych i produktów zarchiwizowanych.

W połączeniu z triggerami na poziomie pól, query_filter umożliwia budowanie bardzo precyzyjnych subskrypcji, redukując ruch do endpointów odbierających do ułamka obecnego wolumenu.

Konfiguracja jako kod z shopify.app.toml

Subskrypcje Next Generation Events konfiguruje się bezpośrednio w pliku shopify.app.toml, razem z pozostałą konfiguracją aplikacji. Oznacza to, że definicja zdarzeń jest:

• Wersjonowalna w repozytorium projektu
• Przeglądalna w procesie code review
• Odtwarzalna w różnych środowiskach bez ręcznych konfiguracji

Dla zespołów zarządzających wieloma środowiskami (development, staging, produkcja) lub stosujących praktyki GitOps, to podejście eliminuje zależność od konfiguracji zarządzanych ręcznie w panelu Shopify.

Praktyczny wpływ na integracje ERP i PIM

Dla katalogów o dużym wolumenie suma tych zmian ma mierzalny wpływ na wydajność i koszty:

• Redukcja liczby otrzymywanych dostarczeń dzięki precyzyjnym triggerom i query_filter
• Redukcja średniej wielkości payloadów dzięki spersonalizowanym zapytaniom GraphQL
• Eliminacja wywołań API wzbogacających po dostarczeniu
• Uproszczenie kodu aplikacji dzięki fields_changed

Integracje, które dziś przetwarzają tysiące zdarzeń dziennie przy niskim wskaźniku przetwarzalności, najbardziej skorzystają na tej architekturze.

Rekomendacje dla tych, którzy zaczynają dziś

System jest obecnie w developer preview na niestabilnym API Shopify, z obsługą topiców Product i Customer. Przed oceną jego wdrożenia:

• Zweryfikuj swój obecny ruch: zidentyfikuj webhooki o wysokim wolumenie i niskiej użyteczności payloadu – to priorytetowi kandydaci do migracji
• Testuj w preview: korzystaj z dostępnych dziś topiców Product i Customer, aby zwalidować oczekiwane zachowanie
• Zastąp logiki diff: refaktoryzuj istniejące konsumery w oparciu o fields_changed
• Skonfiguruj query_filter: zdefiniuj kryteria filtrowania według aktualnego stanu, aby wyeliminować niedające się przetworzyć dostarczenia
• Zaplanuj migrację: API jest na unstable i nie nadaje się do produkcji bez planu przejścia na stabilną wersję

Jeśli budujesz lub rozwijasz niestandardowe integracje na Shopify Plus i chcesz ocenić architekturę najlepiej dopasowaną do Twojego wolumenu i wymagań, szczegółowe informacje znajdziesz na stronie usług dla deweloperów Shopify.

Podsumowanie

Next Generation Events to nie tylko ulepszenie wydajności webhooków: redefiniują model integracji z Shopify, przenosząc granularną kontrolę na stronę dewelopera. Dla tych, którzy budują poważne integracje na katalogach o dużym wolumenie, warto eksplorować ten wzorzec już teraz, zanim osiągnie stabilność i stanie się oczekiwanym standardem.