Gdzie założyć sklep internetowy?

Gdzie założyć sklep internetowy? Gdybym to pytanie zadał mojemu wspólnikowi, zacząłby od tego, że to pytanie jest źle sformułowane. Bo to nie „gdzie”, ale „jaki”, albo właściwie „w jakiej technologii ten sklep postawić” powinno być przedmiotem dyskusji początkujących przedsiębiorców z branży e-commerce.

Przekrojowo – masz do wyboru 2 rozwiązania technologiczne, jeśli oceniać je w kontekście biznesowym, strategicznym, kosztowym, ale zanim – upewnij się, że subskrybujesz ten kanał, masz włączone powiadomienie o nowych materiałach, tymczasem zaczynamy.

Usystematyzujmy konteksty

Technologicznie rozwiązania są dwa: CMS’y monolityczne oraz tzw. headless CMS’y. CMS’ami monolitycznymi są zarówno silniki open source’owe instalowane lokalnie na serwerze, jak i silniki/platformy SaaS’owe, za które będziesz płacił abonamentowo co miesiąc. Z kolei headless CMS’y to silniki bezgłowe, których obszary front-end i back-end, a niejednokrotnie także bazodanowe – są odklejone od siebie, rozproszone i zdecentralizowane. Headless CMS’y w kontekście e-commerce (ale i nie tylko w tym kontekście) są rozwiązaniami wciąż mało popularnymi w Polsce, choć b. ciekawymi, bo wydaje się, że są znacznie bardziej perspektywiczne od rozwiązań monolitycznych.

Z kolei gdybyśmy oceniali dostępne rozwiązania biznesowo, to powiedziałbym, że ocenie podlega każda z tych grup z kolei. Monolityczne CMS’y nie są bowiem jednorodne i rozwiązania open source’owe typu Prestashop czy WooCommerce budują zupełnie inną narrację kosztową, rozwojową niż rozwiązania SaaS’owe, mimo że to, jak i komu organizacja płaci za sklep wydawałoby się rzeczą wtórną.

I skoro wyjaśniliśmy sobie już konteksty, wiesz już, że pytanie „gdzie założyć sklep internetowy” nie jest właściwie zadanym pytaniem, zacznijmy po kolei.

• CMS’y monolityczne typu out of the box

CMS’y monolityczne out of the box to silniki, które posiadają pełen zestaw komponentów do funkcjonowania jako sklep. Instaluje się je na hostingu, serwerze i są to najczęściej darmowe silniki typu open source. Mówię najczęściej, bo nie zawsze i tak np. Magento, które jeszcze kilka lat temu występowało wyłącznie jako silnik monolityczny open source, to dzisiaj głównym focusem Adobe – właściciela Magento są kompilacje komercyjne – w tym Magento Commerce oraz Magento Commerce Cloud. Co prawda open source’owa kompilacja Magento wciąż jest rozwijana, bo najnowsza kompilacja pochodzi z października 2020 r., to przyjmijmy, że tymi dominującymi, najpopularniejszymi silnikami out of the box w e-commerce są Prestashop i WooCommerce.

• CMS’y monolityczne typu SaaS

SaaS’y to obok monolitycznych CMS’ów – najpopularniejsze rozwiązanie rozwiązanie w e-commerce. W SaaS’ach płacisz abonament za aktywację sklepu, jego utrzymanie, a w zamian – niskim kosztem otrzymujesz gotowy silnik ze wszystkimi komponentami, które pozwalają sprzedawać w zasadzie od zaraz.

Przykładami CMS’ów Saas’owych są: Shoper, IAI Shop, Sky Shop, czy Ebexo.

• Headless CMS’y

Headless CMS’y to rozwiązania, które są w tej chwili w wyraźnym trendzie zwyżkującym. Bezgłowe silniki dostarczają właścicielowi sam back-end lub ewentualnie back-end + system bazodanowy na dane zapisywane przez użytkowników, choć moduły bazodanowe na ogół stanowią osobny komponent takich silników. Front-end jest tutaj również zupełnie osobnym wątkiem – co do zasady bezgłowy CMS nie ma frontu, więc tutaj front-end projektuje się w oparciu o popularne frameworki javascriptowe.

Komunikacja między front-endem, back-endem, systemami bazodanowymi i wszystkimi zewnętrznymi komponentami odbywa się przez API, więc sam sklep jako taki bardziej przypomina w swojej architekturze aplikację niż typowy silnik CMS open source złożony z PHP’u i MySQL’a, które są tak popularne w Polsce, Europie i na świecie. Back-end hostowany jest przez dostawcę silnika, front-end zwyczajowo osadza się na serwerze własnym, a całość skomunikowana jest przez API. A jako, że API pozwala na w zasadzie nieograniczone zarządzanie zawartością back-endową, danymi, to bezglowe silniki e-commerce’owe mogą służyć w przyszłości właścicielom do budowy i rozwoju aplikacji mobilnych, dać początek dedykowanemu systemowi zamówień. Jako, że dane z headless CMS’ów można wstrzykiwać w wiele różnych miejsc, jest to rozwiązanie skalowalne i wygodne. Nie ma też problemu, aby dane z headless CMS’a e-commerce’owego wstrzykiwać równolegle np. w dwa różne fronty sklepów – pod różnymi domenami , więc headless daje ten komfort, że posiadacie jedno miejsce, z którego zarządzacie back-endem, a to co z tymi danymi zrobicie, to już pole do popisu wyobraźni.

Przykładami bezgłowych silników e-commerce są m.in. Sanity, Strapi, Saleor.

Co wybrać?

Jeśli oglądasz, słuchasz tego materiału, bo jeszcze nie podjąłeś decyzji, w której technologii chcesz pracować, to w takim telegraficznym skrócie: według mnie – będąc małą firmą, ale z konkretnymi aspiracjami, tzn. wiesz, że chcesz budować organizację, zespół, a nie pracować sam, to na tym etapie najzdrowszym, najrozsądniejszym rozwiązaniem będzie CMS monolityczny out of the box – WooCommerce, Prestashop lub jakikolwiek inny CMS open source z dużym wsparciem społeczności. Te monolity out of the box nie są bez wad, ale bazując na tych dwóch skryptach możesz prowadzić zarówno mały sklep w pojedynkę lub z kilku-, kilkunastoosobowym zespołem. Zwyczajowo WooCommerce wybierają osoby, które sprzedają rozwiązania B2B lub handlują w B2C w mniejszej skali, a także marki typu DTC, gdzie np. PrestaShop mogłaby się okazać zbyt kosztowna w dewelopowaniu. O tym, czym są sklepy DTC i czym różnią się od sklepów masowych retail i DNVB posłuchacie w materiale, do którego odnośnik znajdziecie tuż powyżej.

Możecie spytać, Adrian dlaczego nie SaaS’y?

Jeśli śledzicie ten kanał, to prawdopodobnie znacie już mój materiał pt. „Sklep internetowy SaaS”, w którym tłumaczę, dlaczego nie każdemu właścicielowi e-commerce SaaS będzie po leżał. O ile za SaaSa zapłacicie na starcie jakieś grosze, równie niewiele miesięcznie za utrzymanie sklepu, o tyle w przypadku projektów mocno prorozwojowych, support SaaS’ów z czasem albo wymięka, albo kosztuje tyle, że wdrażanie swoich rozwiązań doprowadza do tego, że i tak docelowo będzie rozglądali się po rynku w celu ucieczki na coś swojego. Oczywiście – na SaaSach stoją z powodzeniem także duże marki, to wciąż – my jako agencja nie czujemy się zbyt komfortowo z tym, że klienci, którzy z SaaS’ów korzystają – w większości – z powodów podanych przeze mnie wcześniej – stawać w roli szybko rozwijającego się partnera, który elastycznie reaguje na zmiany rynkowe.

I w tym miejscu zachęcam Was do obejrzenia jeszcze dwóch materiałów uzupełniających na temat monolitów – w tym po pierwsze „Jaki skrypt sklepu internetowego wybrać?”, w którym pokrótce omawiam różnice między typowymi open source’ami – Prestashop, WooCommerce i open-source’owym Magento. A po drugie – „WooCommerce czy Prestashop?” – wideo, w którym porównuję szczegółowo oba te silniki.

No dobra, a co z headlessami?

Jakikolwiek headless CMS jest w mojej ocenie znacznie bardziej dojrzałą technologią, z potencjalnie dłuższym cyklem życia niż jakikolwiek monolit. W SaaS’ach macie ten problem, że co prawda z rozwojem backendu nie jest tak źle, są firmy, które nie nadążają, są też firmy, które nadążają za rynkiem, ale zasadniczo fakt tego, że front-end jest przyklejony do back-endu, a wy jako właściciele – w zasadzie dzierżawcy tej technologii nie macie absolutnie żadnego wpływu na indywidualne rozwiązania; a te, które są w zasięgu, albo trwają nieproporcjonalnie długo i kosztują kilka razy tyle, ile zapłacilibyście na wolnym rynku deweloperom pracujących na open source’ach. Bawiąc się w SaaS – nie napiszecie sami nic w PHP’ie, w CSS’ie, w JS’ie, co w silnikach out of the box pozwala wam na ogrywanie rynku, szukanie dróg na skróty, wprowadzanie indywidualnych rozwiązań. Z kolei bawiąc się w silnikach out of the box, czyli np. w Prestę czy Woo możecie wszystko, ale musie pamiętać o tworzeniu dokumentacji, zachowaniu dobrej kultury pracy, bo bywa i tak, że kod tego jednego czy drugiego open source’a jest już tak poklejony różnymi rozwiązaniami, że update silnika lub jakaś core’owa zmiana funkcjonalności ciągnie się procesowo i nadbudowuje dług technologiczny.

Headless e-commerce’y są przy tym lepiej zabezpieczone przed atakami – i to nawet nie jest wypadkowa tego, że są lepiej napisane od monolitów, a z samego faktu, że korzystają z interfejsu API. O ile w monolitach out of the box typowym sposobem na zainfekowanie silnika jest SQL injection, czyli wstrzyknięcie instrukcji SQL np. przy odpytaniu silnika o dane użytkownika i hasło.

Co więcej – headless e-commerce’y są nieporównywalnie szybsze w obsłudze od monolitów. I wynika to z kilku okoliczności – po pierwsze jeśli się na niego zdecydujesz, to headless będzie aplikacją, sklepem o dedykowanej funkcyjności, więc nie będzie obciążony na starcie komponentami, których nie potrzebuje. Jeśli nie potrzebujesz w silniku komponentu do obsługi treści na blogu sklepu, to po prostu go nie napiszesz itd. Sam fakt, że w headlessie trzeba wszystko napisać pod siebie jest powodem, dla którego kod jest bardziej skompilowany, a serwer odpytywany tylko o te dane, których potrzebuje do obsługi zapytania.

Tyle tylko, że headlessy mimo swoich zalet nie są ani proste, ani tanie w dewelopowaniu. Wymagają zaawansowanej znajomości JS’a, zarówno po stronie fron-endowej, jak i back-endowej i tutaj deweloperzy, którzy mają ograniczoną znajomość technologii do PHP’a, MySQL’a, czyli technologii typowych dla CMS’ów out of the box – będą mieli pod górę, bo budowaine headless e-commerce’u przypomina bardziej pełnoprawne dewelopowanie aplikacji niż coś, co przypomina budowę typowej strony www. I trudno jest mi sobie wyobrazić, że da się taki projekt poprowadzić w pojedynkę, dlatego headless e-commerce mimo że najdojrzalszy i absolutnie zachęcam, abyście śledzili je biznesowo, nie będą odpowiednie dla wszystkich tych osób, które zadają sobie pytanie, jakie padło w tytule tego materiału, czyli – „Gdzie założyć sklep internetowy””.

Tymczasem dzięki bardzo za uwagę, mówił do Was Adrian Pakulski Paq z agencji SEO Paq Studio, do następnego, cześć.