Sklep internetowy od zera z integracją logistyczną: pięć warstw i kolejność ich budowy

„Chcę sklep internetowy zrobiony od zera” zwykle znaczy „chcę sklep, który robi to, czego nie robią szablony”. A to, czego szablony nie robią, to prawie zawsze to samo: rozmowa z tym, kto produkuje, z tym, kto wysyła, i z tym, kto pobiera płatność, bez człowieka przepisującego dane z jednego ekranu na drugi. Ten artykuł wyjaśnia, jak porządkujemy tę pracę w pięciu warstwach, co zawiera każda z nich i w jakiej kolejności je budujemy. Przykłady pochodzą z eclipseando.com, naszego sklepu działającego w produkcji, oraz z konektorów przewoźników, które opublikowaliśmy dla Odoo.

Pięć warstw sklepu

Warstwa 1: dane żyją w jednym miejscu

Zanim narysuje się choć jeden ekran, trzeba zdecydować, gdzie żyje katalog. Jeśli klient ma Odoo, odpowiedź brzmi: w Odoo. Produkty, ceny, stany magazynowe i zamówienia są tam, a strona je czyta, nie kopiuje. Jeśli klient go nie ma, sklep potrzebuje własnej bazy danych, najlepiej małej i nudnej. W eclipseando.com to SQLite, w jednym pliku, z kopią zapasową. Nie może się zdarzyć, że cena jest w sklepie, a także w arkuszu kalkulacyjnym i w ERP: po dwóch miesiącach są to trzy różne ceny.

Warstwa 2: kasa nie ufa przeglądarce

Dwie zasady, w których nie negocjujemy. Pierwsza: cena jest obliczana na serwerze, według aktualnego katalogu, w chwili utworzenia sesji płatności. Przeglądarka może przechowywać koszyk, ale nie może mówić, ile on kosztuje. Druga: zamówienie jest opłacone, gdy bramka potwierdzi to podpisanym webhookiem, a nie wtedy, gdy klient wyląduje na stronie z podziękowaniem. W Stripe jest to checkout.session.completed z zweryfikowanym podpisem; w innych bramkach nazywa się to inaczej, ale idea jest ta sama. A jeśli po odebraniu webhooka zawiedzie kolejny krok, odpowiada się błędem, żeby bramka ponowiła próbę, i zapisuje się identyfikator sesji, by nie zrealizować zamówienia dwa razy.

Warstwa 3: każdy dostawca komunikuje się tak, jak potrafi

Tu „integracja logistyczna” przestaje być hasłem i staje się pracą. Dostawcę z API i webhookiem (drukarnię na żądanie, dużego przewoźnika) integruje się w obie strony: zamówienie tworzy się po opłaceniu, a jego powiadomienie „wysłano” odbiera się, by przekazać klientowi numer śledzenia. Dostawcę z API do dropshippingu integruje się w jedną stronę, a w drugą się go odpytuje: przed pobraniem płatności sprawdza się rzeczywistą dostępność w danym kraju, potem przekazuje zamówienie. A dostawcę bez API, których jest wielu, integruje się, redukując pracę człowieka do jednego kliknięcia: system generuje dokładnie taki e-mail lub CSV, jakiego dostawca potrzebuje, a jeśli jego paczki wychodzą z przewoźnikiem, który wysyła e-maile, te e-maile są odczytywane i zamieniane na statusy.

Dwa szczegóły, których uczy się tylko na prawdziwych zamówieniach. Pierwszy: śledzenie dotyczy przesyłki, a nie zamówienia, bo zamówienie z dwoma produktami od dwóch dostawców to dwie paczki. Drugi: terminy podawane w dokumentacji dostawcy nie są tymi, których dotrzymuje; mierzy się je, tworząc zamówienia testowe i czytając, co wraca, i to je pokazuje się klientowi przed zapłatą. Gdy dostawcą jest przewoźnik, a sklep działa na Odoo, wszystko to jest już rozwiązane w publikowanych przez nas konektorach przewoźników: etykieta, śledzenie, manifest i zwrot wewnątrz Zlecenia dostawy.

Warstwa 4: to, co działa samo, i to, co jest ponawiane

Sklep ma pracę, która nie może zależeć od tego, że ktoś o niej pamięta: opróżnianie kolejki e-maili, ponawianie opłaconych zamówień, które nie dotarły do dostawcy, odczyt skrzynki przewoźnika, synchronizacja stanów magazynowych z marketplace’ami. Każde z tych zadań to zadanie zaplanowane z interwałem i dziennikiem. Zasada projektowa jest taka, że żadne z nich nie wywołuje zewnętrznej usługi w ścieżce żądania użytkownika: strona czyta to, co zadanie zostawiło w pamięci podręcznej. Dzięki temu, jeśli dostawca przestanie działać o trzeciej w nocy, sklep nadal serwuje strony, a zamówienia są ponawiane, gdy dostawca wróci.

Warstwa 5: frontend na końcu i szybki

Gdy cztery dolne warstwy są rozwiązane, frontend jest najbardziej wdzięczną częścią. Wolimy strony statyczne generowane w trakcie build, serwowane przez nginx lub Caddy (Astro w eclipseando.com): ładują się błyskawicznie, nie mają bazy danych, którą można zaatakować, i kosztują tyle, ile mały serwer. Część dynamiczna (koszyk, płatność, status zamówienia) działa przez oddzielne API. Wielojęzyczność realizuje się przez jeden adres URL na język i własne teksty, a nie przez automatyczne tłumaczenie nałożone na stronę, i sprawdza testami, że każdy szablon istnieje we wszystkich językach. A szybkość mierzy się przed publikacją: waga strony, obrazy w rozmiarze, w jakim są wyświetlane, nic, co blokuje pierwsze renderowanie.

Kolejność ma znaczenie: od środka na zewnątrz

Najdroższy błąd, jaki widzimy, to zaczynanie od warstwy 5. W drugim tygodniu pokazuje się ładną stronę, klient się cieszy, a warstwy od 1 do 4 improwizuje się pod spodem w pośpiechu. Wynik działa do pierwszego zamówienia z dwoma dostawcami albo do pierwszego zgubionego webhooka. My budujemy odwrotnie: najpierw dane i kasa z testami, potem integracje z prawdziwymi zamówieniami testowymi, potem zadania zaplanowane, a frontend na końcu, gdy wiadomo już dokładnie, co ma pokazywać. Trwa to tyle samo. Przerabia się znacznie mniej.

Najczęstsze pytania

Przydatne linki w FlexigoTech

Co robimy w tym zakresie