Magento 2 vs inne platformy e‑commerce Open Source. Czym naprawdę się wyróżnia?

Platformy Open Source wrzuca się często do jednego worka, mimo że zostały zbudowane według różnych założeń.

Magento Open Source i PrestaShop są samodzielnymi platformami e‑commerce. Shopware Community Edition również jest pełną platformą commerce rozwijaną w modelu Open Source. WooCommerce działa jako rozszerzenie WordPressa i wykorzystuje jego architekturę.

Sylius Community Edition jest natomiast frameworkiem e‑commerce zbudowanym na Symfony. Oficjalna dokumentacja (otwiera się w nowej karcie) określa go jako rozwiązanie headless i Open Source, dające zespołowi developerskiemu kontrolę nad modelem danych, logiką biznesową, checkoutem i frontendem.

Nie są to więc produkty zbudowane według jednego wzorca. Dlatego pytanie „która platforma ma najwięcej funkcji?” niewiele pomaga przy wyborze technologii. Znacznie ważniejsze jest pytanie:

Jaki model e‑commerce dana platforma pozwala zbudować bez walki z jej podstawową architekturą?

Jedną z najbardziej charakterystycznych cech Magento jest hierarchia:

Website → Store → Store View

Jedna instalacja Magento Open Source może zawierać wiele websites, stores i store views (otwiera się w nowej karcie).

Website jest najwyższym poziomem tej struktury. Może działać na osobnej domenie oraz mieć własną konfigurację m.in. płatności, dostaw i checkoutu.

W ramach website mogą działać różne stores. Mogą wykorzystywać odrębne struktury katalogu oparte na różnych root categories.

Store View służy m.in. do prezentacji sklepu w różnych wersjach językowych i pozwala nadpisywać część danych oraz ustawień na poziomie konkretnego widoku.

Magento wykorzystuje przy tym mechanizm scope:

Global → Website → Store → Store View

Dzięki temu określone dane i ustawienia mogą obowiązywać globalnie albo wyłącznie w konkretnym obszarze struktury sklepu.

Przykładowo cena produktu może mieć zakres globalny albo website. Ten sam produkt może więc mieć inną cenę na dwóch websites, jeżeli konfiguracja price scope (otwiera się w nowej karcie) została ustawiona na poziom website.

Produkty można również przypisywać do konkretnych websites. Daje to możliwość zbudowania z jednej instalacji np.:

• sklepu polskiego i niemieckiego,
• kilku marek należących do jednej firmy,
• kilku domen,
• kilku katalogów,
• różnych wersji językowych,
• różnych konfiguracji sprzedaży dla poszczególnych rynków.

Nie oznacza to, że Magento jako jedyne posiada multistore.

PrestaShop również pozwala zarządzać wieloma sklepami z jednego back office. Funkcja multistore umożliwia m.in. wykorzystanie różnych domen i zarządzanie kilkoma frontami sprzedażowymi w jednej instalacji. Shopware korzysta z kolei z modelu Sales Channels.

Różnica Magento polega przede wszystkim na tym, jak mocno struktura wielu websites, stores, store views i scopes jest wpisana w podstawowy model platformy.

Drugim istotnym obszarem jest katalog.

W Magento atrybuty (otwiera się w nowej karcie) są jednym z podstawowych elementów modelu produktu. Można tworzyć własne atrybuty oraz łączyć je w Attribute Sets, które działają jak szablony dla poszczególnych rodzajów produktów.

Przykładowo producent może mieć osobny zestaw atrybutów dla:

• elektronarzędzi,
• akcesoriów,
• części zamiennych,
• odzieży roboczej.

Każda z tych grup może wymagać zupełnie innych parametrów. Atrybuty mogą być później wykorzystywane m.in. podczas prezentacji produktu, wyszukiwania, filtrowania czy porównywania produktów.

Ma to znaczenie w e‑commerce z rozbudowaną ofertą, w której produkty różnią się nie tylko nazwą, zdjęciem i ceną, ale posiadają dziesiątki parametrów technicznych i należą do różnych rodzin produktowych.

Nie oznacza to jednak, że Magento zastępuje system PIM.

Jeżeli organizacja posiada rozbudowany proces zarządzania danymi produktowymi, tłumaczeniami, opisami marketingowymi czy materiałami multimedialnymi, źródłem tych informacji może pozostać PIM. Magento odpowiada wtedy przede wszystkim za wykorzystanie odpowiednich danych w procesie sprzedaży.

Inventory Management (otwiera się w nowej karcie) jest elementem Magento Open Source, a nie funkcją zarezerwowaną wyłącznie dla Adobe Commerce. Moduły Inventory Management są instalowane w Magento Open Source i domyślnie udostępniają funkcje związane zarówno z pojedynczym, jak i wieloma źródłami zapasu.

Magento rozróżnia między innymi:

Producent może więc mieć np. magazyn centralny, magazyn zagraniczny i dodatkową lokalizację fulfillmentową, a Magento może uwzględniać te źródła przy określaniu dostępności produktów.

Nadal nie oznacza to, że Magento powinno zastępować ERP lub WMS. W wielu architekturach to ERP albo WMS pozostaje systemem źródłowym dla stanów magazynowych, a Magento wykorzystuje otrzymane dane w kanale sprzedaży internetowej.

W rozwiniętym e‑commerce sklep rzadko funkcjonuje samodzielnie. Obok niego mogą działać:

• ERP,
• PIM,
• WMS,
• CRM,
• system księgowy,
• marketing automation,
• marketplace'y,
• systemy płatnicze,
• systemy logistyczne.

Magento Open Source udostępnia REST API (otwiera się w nowej karcie) oraz GraphQL.

REST pozwala wykonywać wiele operacji związanych m.in. z katalogiem, klientami, zamówieniami i integracjami backendowymi.

GraphQL jest szczególnie istotny dla aplikacji klienckich i alternatywnych frontendów. Adobe wprost wskazuje (otwiera się w nowej karcie) możliwość wykorzystania GraphQL Magento Open Source do budowania m.in. headless storefrontów, PWA oraz aplikacji mobilnych.

Samo posiadanie API nie jest jednak przewagą Magento.

• WooCommerce posiada REST API pozwalające m.in. zarządzać produktami, zamówieniami, klientami czy kuponami.
• Shopware Community Edition posiada API jako jeden z elementów swojej architektury rozszerzalności.
• Sylius od początku rozwijany jest w kierunku API-first i headless.
• PrestaShop 9 dostał natomiast nowe Admin API zbudowane na API Platform.

Dlatego nie należy argumentować wyboru Magento samym stwierdzeniem: „Magento ma API”.

Znaczenie ma zakres procesów, które stoją za tym API, oraz sposób, w jaki platforma może zostać włączona do całej architektury sprzedażowej firmy.

Magento składa się z modułów, a własne moduły są podstawowym mechanizmem dodawania nowych funkcji i rozszerzania istniejących. Framework udostępnia mechanizmy takie jak między innymi:

• moduły,
• dependency injection,
• service contracts,
• plugins/interceptors,
• events i observers,
• REST API,
• GraphQL.

Oficjalna dokumentacja Magento Open Source (otwiera się w nowej karcie) opisuje rozszerzanie i modyfikowanie istniejących komponentów oraz budowę własnych komponentów wprost jako część architektury platformy.

Pozwala to zmieniać nie tylko wygląd sklepu, ale również logikę biznesową. Może chodzić np. o:

• sposób obliczania ceny,
• własne zasady dostępności,
• niestandardowy proces zamówienia,
• dodatkowe operacje wykonywane po złożeniu zamówienia,
• własny model integracji z ERP,
• dodatkowe elementy katalogu,
• indywidualne procesy klienta.

Ta możliwość jest jedną z ważniejszych cech Magento, ale jednocześnie łatwo jej nadużyć. Każdy dodatkowy moduł i każda indywidualna modyfikacja stają się częścią systemu, który trzeba testować, aktualizować i utrzymywać.

Duża możliwość ingerencji w platformę ma wartość tylko wtedy, gdy rzeczywiście wynika z procesu biznesowego.

To szczególnie ważne w przypadku B2B.

Magento Open Source można wykorzystać jako podstawę sklepu obsługującego klientów biznesowych. Nie oznacza to jednak, że posiada ono cały zestaw natywnych funkcji B2B znanych z Adobe Commerce. Mechanizmy takie jak:

• Company Accounts,
• Shared Catalog,
• Negotiable Quotes,
• Quick Order,

należą do rozwiązania Adobe Commerce B2B. Adobe oznacza te funkcje w dokumentacji (otwiera się w nowej karcie) jako dostępne wyłącznie w Adobe Commerce B2B.

Jeżeli podobne procesy mają działać na Magento Open Source, mogą wymagać rozszerzeń albo developmentu. To ważne przy porównywaniu kosztów platform.

Nie można zestawić ceny Magento Open Source z innym systemem, a następnie przypisać darmowej wersji funkcji dostępnych dopiero w komercyjnym Adobe Commerce.

Porównania Magento oparte na sytuacji sprzed kilku lat mogą prowadzić do błędnych wniosków.

Tabela nie wskazuje „najlepszej” platformy. Pokazuje przede wszystkim, że podobny efekt biznesowy można osiągnąć na różnych technologiach, ale droga do niego może wyglądać zupełnie inaczej.

Jeżeli spojrzymy osobno na poszczególne funkcje, trudno znaleźć coś, co istnieje wyłącznie w Magento.

• Multistore? Ma go również PrestaShop.
• API? Mają je wszystkie porównywane rozwiązania.
• Headless? Sylius jest nawet mocniej zorientowany na taki model.
• Reguły biznesowe i automatyzacje? Shopware posiada Rule Builder i Flow Builder.
• Rozszerzalność? To podstawowa cecha praktycznie każdego rozwiązania Open Source.

Magento zaczyna się wyróżniać wtedy, gdy kilka potrzeb występuje jednocześnie. Przykładowo firma:

• ma kilka marek,
• działa w kilku krajach,
• wykorzystuje różne domeny,
• ma duży i zróżnicowany katalog,
• potrzebuje różnych cen na różnych rynkach,
• posiada kilka źródeł zapasu,
• integruje e‑commerce z ERP, PIM i WMS,
• chce rozwijać własną logikę sprzedażową,
• potrzebuje jednego zaplecza dla kilku sklepów.

W takim przypadku znaczenie ma nie pojedyncza funkcja, ale sposób, w jaki poszczególne elementy Magento działają razem.

Rozbudowana architektura nie jest darmowa w utrzymaniu.

Aktualna dokumentacja wymagań Magento 2.4.9 (otwiera się w nowej karcie) pokazuje rozbudowany stos technologiczny obejmujący m.in. PHP, bazę danych, OpenSearch oraz dodatkowe komponenty infrastruktury związane z cache, kolejkami i obsługą aplikacji.

Do tego dochodzą mechanizmy charakterystyczne dla samego Magento:

• indeksowanie,
• cron,
• cache,
• kolejki,
• moduły,
• zależności pomiędzy komponentami,
• proces deploymentu,
• aktualizacje bezpieczeństwa.

Im więcej indywidualnego kodu i integracji, tym większe znaczenie mają również testy, monitoring i sposób publikowania zmian.

Dlatego Magento może być technicznie nieuzasadnione w projekcie, który potrzebuje po prostu standardowego sklepu. Większe możliwości platformy nie mają wartości, jeżeli firma z nich nie korzysta.

Magento warto poważnie analizować, kiedy występuje kilka z poniższych elementów:

1. 01

   Wiele rynków

   Firma prowadzi sprzedaż w różnych krajach, językach i walutach oraz potrzebuje różnych konfiguracji poszczególnych rynków.

2. 02

   Wiele marek lub sklepów

   Jedna organizacja prowadzi kilka sklepów albo marek i chce zarządzać nimi w ramach jednej instancji platformy.

3. 03

   Rozbudowany katalog

   Produkty mają wiele atrybutów, wariantów, rodzin produktowych oraz zależności.

4. 04

   Wiele źródeł zapasu

   Dostępność produktów pochodzi z kilku magazynów lub innych lokalizacji.

5. 05

   Duża liczba integracji

   E‑commerce musi komunikować się z ERP, PIM, WMS, CRM i kolejnymi systemami firmy.

6. 06

   Nietypowa logika sprzedaży

   Standardowy proces zakupowy nie wystarcza i część procesów trzeba dopasować do sposobu działania przedsiębiorstwa.

7. 07

   Dalszy rozwój platformy jest przewidywalnym elementem biznesu

   Sklep nie jest jednorazowym projektem, tylko systemem, który będzie regularnie rozwijany razem z ofertą, rynkami i procesami firmy.

W takich przypadkach znaczenie zaczyna mieć architektura Magento jako całości.

Jeżeli firma prowadzi jeden stosunkowo prosty sklep, ma standardowy katalog, jeden rynek i niewiele integracji, znaczna część możliwości Magento może pozostać niewykorzystana. Wtedy warto sprawdzić, czy koszt:

• wdrożenia,
• hostingu,
• utrzymania,
• aktualizacji,
• developmentu,
• testów

jest proporcjonalny do problemów, które platforma ma rozwiązać.

PrestaShop albo WooCommerce mogą być wystarczające dla części takich projektów. Shopware może być alternatywą, gdy ważne są m.in. Sales Channels, reguły i automatyzacja procesów.

Sylius może być interesujący wtedy, gdy projekt od początku zakłada bardzo dużą liczbę indywidualnych procesów i zespół chce budować rozwiązanie na frameworku zamiast dopasowywać biznes do standardowej platformy.

Wybór powinien wynikać z wymagań projektu, a nie z przekonania, że jedna technologia jest z definicji lepsza od pozostałych.

Dlatego zamiast pytać:

„Czy Magento jest lepsze od PrestaShop, WooCommerce, Shopware albo Sylius?”

lepiej ustalić:

„Która platforma najlepiej pasuje do katalogu, rynków, integracji i procesów sprzedażowych naszej firmy?”

Jeżeli odpowiedź wymaga jednocześnie obsługi wielu sklepów, rynków, rozbudowanego katalogu, kilku źródeł zapasu i wielu integracji, Magento staje się jednym z rozwiązań, które warto szczegółowo przeanalizować.