DEV Community: Adrian Synowiecki

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

Adrian Synowiecki — Fri, 15 May 2026 11:54:24 +0000

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.

Zobacz projekt

Kod: https://github.com/AMPLIFIER-sp-z-o-o/amper-b2c

Strona produktu: https://ampliapps.com/amper-b2c/

Środowisko QA: https://amper-b2c.ampliapps.com/

Inside AMPER B2C: how we built an e-commerce platform on Django

Adrian Synowiecki — Fri, 15 May 2026 11:52:47 +0000

Repository: github.com/AMPLIFIER-sp-z-o-o/amper-b2c
Product page: ampliapps.com/amper-b2c

What is interesting about AMPER B2C is not a single storefront screen. It is the way the storefront, admin panel, catalog, inventory, checkout, orders, and media are tied together by one data model.

This is a practical walk through the project: what customers see, what administrators can change, and which parts of the code matter when the store is running on data that keeps changing. The article is based on the public repository and the QA environment.

1. The homepage is not hardcoded into a template

The homepage is built from database records: hero banners, product sections, banner groups, HTML blocks, storefront categories, and sliders. That means a campaign or section order can be changed from the admin panel without touching templates.

The repository also includes draft preview logic. Admin forms can save draft changes into the session, and the storefront can render those changes before they are published. It is a small detail, but it makes day-to-day content work much less fragile.

The same idea appears in dynamic pages. The DynamicPage model stores the slug, CKEditor content, basic SEO settings, visibility, noindex, and sitemap exclusion. In practice, informational pages can be linked from the navigation or footer without adding a separate view for each page.

Screen: homepage with navigation, categories, campaign banners, and product sections.

Screen: homepage sections in the admin panel, with ordering and active status.

Screen: banner configuration, images, and campaign settings.

2. The catalog is data-driven

A product in AMPER B2C is not just a name, price, and image. It has a category, status, images, price, stock, warehouses, and attributes. Attributes are modeled as separate definitions and options, so they can be reused in filters, product cards, and category pages.

Screen: catalog view with product cards, prices, attributes, cart actions, and shopping lists.

Screen: category page narrowed to a specific catalog context.

Screen: search with filtering, sorting, and pagination.

Screen: product list in the admin panel, with statuses, prices, images, stock, sales, and revenue.

One useful implementation detail is prefetching product images and tile attributes. It is not a flashy screenshot feature, but with a larger catalog it keeps product listing views away from the classic N+1 query problem.

3. The product page uses the same model

The product page renders catalog data: image, description, price, availability, category breadcrumb, and attributes. Product status distinguishes values such as active, hidden, and disabled, so a product can be hidden or left visible without allowing purchase.

Screen: product page with image, description, price, quantity, cart action, shopping list, and attributes.

4. Cart and checkout refresh data before purchase

The cart stores order lines, quantities, prices, discounts, coupons, delivery method, payment method, and totals. Before checkout, the data is synchronized with the current database state again. If someone changes a price or coupon rule in the admin panel, the customer sees the updated order before submitting it.

Screen: cart with quantity control, promo code, shopping lists, and recalculated total.

Screen: checkout with server-side data storage and expiry time.

Screen: coupon configuration with discount type, active state, date range, usage limits, and minimum cart value.

Screen: delivery methods configured from the admin panel.

Screen: product stock maintained separately per warehouse.

The most important part happens during order placement. Products and stock records are locked with select_for_update(), stock is checked again, quantities are decreased in the warehouse, the coupon is verified one more time, and only then is the order created.

5. Orders keep their own history

An order stores a copy of the customer details, delivery address, delivery method, payment details, product value, discount, delivery cost, currency, and final total. Order lines keep their own unit price and line total, so history does not change when the catalog is edited later.

Screen: orders panel with durable business records.

Stock allocation between warehouses is modeled separately as well. An order line can store which warehouse supplied the product. That is a good starting point for later ERP or WMS integrations.

6. Favorites are closer to shopping lists

In this project, favorites do not stop at a simple heart icon on a product card. A user can have multiple lists, anonymous users are tracked by session key, items remember the price from the moment they were added, and a list can be shared through a non-guessable identifier.

Screen: shopping list view in the storefront.

The login moment is interesting. Default anonymous lists can merge into the account without duplicates, while custom anonymous lists are moved to the user with automatic conflict handling for names.

7. Media can run locally or through S3

Product images, category images, banners, and media library records use DynamicMediaStorage. The same storage model can run locally or through S3 with an optional CDN, so different environments can use different media setups.

Screen: media library in the admin panel, with file metadata and source references.

What stands out in the code

The parts of the repository worth looking at are the ones that usually matter only when a real store is being used: stock locking during order placement, coupon revalidation, cart total refreshes, server-side checkout data, order data copies, merging anonymous shopping lists into user accounts, and media storage that can run locally or through S3/CDN.

These are not the most visually impressive parts of the interface, but they decide whether the store behaves predictably when data changes in the admin panel while a customer is already in the middle of a purchase.

Explore the project

Code: https://github.com/AMPLIFIER-sp-z-o-o/amper-b2c

Product page: https://ampliapps.com/amper-b2c/

QA environment: https://amper-b2c.ampliapps.com/

QA login: admin@example.com / admin