Adrian Synowiecki

Posted on May 15

AMPER B2C od środka: jak zbudowaliśmy platformę e-commerce opartą na Django

#django #python #webdev #showdev

Repozytorium: github.com/AMPLIFIER-sp-z-o-o/amper-b2c
Strona produktu: ampliapps.com/amper-b2c

W AMPER B2C najciekawsze nie są pojedyncze ekrany sklepu, tylko sposób, w jaki część sklepowa, panel administracyjny, katalog, magazyn, finalizacja zakupu, zamówienia i media są spięte jednym modelem danych.

Poniżej przechodzę przez projekt od strony praktycznej: co widzi klient, co może zmienić administrator i które fragmenty kodu mają znaczenie, kiedy sklep działa na zmieniających się danych. Tekst powstał na podstawie publicznego repozytorium oraz środowiska QA.

1. Strona główna nie jest zaszyta w szablonie

Strona główna składa się z rekordów w bazie: głównych banerów, sekcji produktowych, grup banerów, bloków HTML, kategorii widocznych w sklepie i sliderów. Dzięki temu kampanię albo kolejność sekcji można zmienić z panelu, bez grzebania w szablonach.

W repozytorium widać też mechanikę podglądu szkiców. Formularze w panelu mogą zapisać robocze zmiany w sesji, a sklep potrafi pokazać taki podgląd przed publikacją. To drobiazg, który oszczędza dużo nerwów przy pracy nad treścią strony.

Ten sam kierunek widać przy dynamicznych stronach. Model DynamicPage przechowuje slug, treść z CKEditora, podstawowe ustawienia SEO, widoczność, noindex i wykluczenie z mapy strony. W praktyce oznacza to, że strony informacyjne można podpinać do nawigacji albo stopki bez dopisywania osobnego widoku dla każdej z nich.

Screen: strona główna z nawigacją, kategoriami, banerami kampanii i sekcjami produktowymi.

Screen: sekcje strony głównej w panelu, z kolejnością i statusem aktywności.

Screen: konfiguracja banerów, obrazków i ustawień kampanii.

2. Katalog jest oparty na danych

Produkt w AMPER B2C nie jest tylko nazwą, ceną i obrazkiem. Ma kategorię, status, obrazy, cenę, stany magazynowe, magazyny i atrybuty. Atrybuty są osobnymi definicjami oraz opcjami, więc mogą być używane w filtrach, na kartach produktów i na stronach kategorii.

Screen: katalog w sklepie z kartami produktów, cenami, atrybutami, koszykiem i listami zakupowymi.

Screen: strona kategorii zawężona do wybranego kontekstu katalogu.

Screen: wyszukiwanie z filtrowaniem, sortowaniem i paginacją.

Screen: lista produktów w adminie, ze statusami, cenami, obrazami, stanem magazynowym, sprzedażą i przychodem.

W kodzie istotny jest też prefetch obrazów i atrybutów kafelkowych. To nie jest efektowna funkcja na screenshot, ale przy większym katalogu chroni widoki list produktów przed klasycznym problemem N+1 query.

3. Strona produktu korzysta z tego samego modelu

Strona produktu renderuje dane z katalogu: obraz, opis, cenę, dostępność, breadcrumb kategorii i atrybuty. Status produktu rozróżnia między innymi active, hidden i disabled, więc produkt można ukryć albo zostawić widoczny bez możliwości zakupu.

Screen: strona produktu z obrazem, opisem, ceną, ilością, koszykiem, listą zakupową i atrybutami.

4. Koszyk i finalizacja zakupu odświeżają dane przed zakupem

Koszyk przechowuje linie zamówienia, ilości, ceny, rabaty, kupony, metodę dostawy, metodę płatności i podsumowanie kosztów. Przed finalizacją zakupu dane są ponownie synchronizowane z bazą. Jeśli ktoś zmieni cenę albo warunki kuponu w panelu, klient zobaczy aktualną wersję zamówienia.

Screen: koszyk z kontrolą ilości, kodem promocyjnym, listami zakupowymi i przeliczaną sumą.

Screen: finalizacja zakupu z danymi przechowywanymi po stronie serwera i czasem wygaśnięcia.

Screen: konfiguracja kuponów z typem rabatu, aktywnością, zakresem dat, limitami użycia i minimalną wartością koszyka.

Screen: metody dostawy konfigurowane w panelu.

Screen: stany produktów utrzymywane osobno dla magazynów.

Najważniejszy fragment dzieje się podczas składania zamówienia. Produkty i rekordy stanów magazynowych są blokowane przez select_for_update(), stan jest sprawdzany ponownie, ilości są zmniejszane w magazynie, kupon jest weryfikowany jeszcze raz i dopiero wtedy powstaje zamówienie.

5. Zamówienia zachowują własną historię

Zamówienie zapisuje kopię danych klienta, adresu dostawy, metody dostawy, płatności, wartości produktów, rabatu, kosztu dostawy, waluty i końcowej sumy. Linie zamówienia zachowują cenę jednostkową oraz sumę linii, więc historia nie zmienia się po późniejszej edycji katalogu.

Screen: panel zamówień z trwałymi rekordami biznesowymi.

Osobno modelowana jest też alokacja stanów między magazynami. Linia zamówienia może przechować informację, z którego magazynu pochodził produkt. To dobry punkt wyjścia pod późniejsze integracje ERP albo WMS.

6. Ulubione produkty są bliżej list zakupowych

W tym projekcie ulubione produkty nie kończą się na prostym serduszku przy karcie produktu. Użytkownik może mieć wiele list, anonimowi użytkownicy są śledzeni po kluczu sesji, elementy pamiętają cenę z momentu dodania, a listę można udostępnić przez niezgadywalny identyfikator.

Screen: widok list zakupowych w sklepie.

Ciekawy jest moment logowania. Domyślne listy anonimowe mogą połączyć się z kontem bez duplikatów, a własne listy anonimowe są przenoszone do użytkownika z automatycznym rozwiązywaniem konfliktów nazw.

7. Media mogą działać lokalnie albo przez S3

Obrazy produktów, kategorii, banerów i rekordy biblioteki mediów korzystają z DynamicMediaStorage. Ten mechanizm przechowywania może działać lokalnie albo przez S3 z opcjonalnym CDN, więc ten sam model obsługuje różne konfiguracje środowiska.

Screen: biblioteka mediów w panelu, z metadanymi plików i powiązaniami źródłowymi.

Co wyróżnia kod

W repozytorium najbardziej warte uwagi są te fragmenty, które zwykle wychodzą dopiero przy realnym użyciu sklepu: blokowanie stanów magazynowych przy składaniu zamówienia, ponowna weryfikacja kuponu, odświeżanie sum koszyka, serwerowe przechowywanie danych finalizacji zakupu, kopie danych zamówień, łączenie anonimowych list zakupowych z kontem oraz przechowywanie mediów lokalnie albo przez S3/CDN.

To nie są widowiskowe elementy interfejsu, ale właśnie one decydują o tym, czy sklep zachowuje się przewidywalnie, kiedy dane zmieniają się w panelu administracyjnym, a klient jest w środku procesu zakupowego.