53. Headless ecommerce – dlaczego nie warto go wdrażać? – Paweł Kryst – Convertis

Grzegorz Frątczak: Cześć Paweł!

Paweł Krysta: Cześć.

GF: Dzisiaj zaprosiłem do podcastu Pawła Krysta, naszego głównego programistę od presty, od PrestaShop. I będziemy dyskutować na temat – czy wchodzić w ogóle w Headless i dlaczego nie Headless. A może Headless? A może…? Co z tym w ogóle zrobić? Zanim pójdziemy dalej, to Pawle, powiedz parę słów o sobie.

PK: Okej. Jestem programistą, już z wieloletnim stażem. Programuję jeszcze od szkoły podstawowej. Ostatnio pracuję w Convertis i od kilkunastu lat specjalizuję się i zajmuję się PrestaShop.

GF: W przypadku Pawła powiedzenie „od szkoły podstawowej” oznacza, że to jest – ile, Pawle – 30 lat?

PK: Od bardzo dawna.

GF: Czy 40? Nie, myślę, że 40 plus.

PK: Tak.

GF: Więc, Paweł jest skromny. Wiecie, kobiet nie pyta się o wiek, może Pawła też się nie powinno pytać. No właśnie. Pawle, powiedz mi, jaką Ty masz w ogóle opinię – wchodzić w Headless czy nie wchodzić? Tak na początek, walnijmy z grubej rury.

PK: To zależy czym się jest. Czy my tutaj będziemy rozmawiać głównie w kontekście sklepów internetowych? Tak?

GF: Tak.

PK: Więc, zależy jakim się jest sklepem. Jaki się ma obrót, jaką się ma sprzedaż i czy nas na to stać? Jest to fajna technologia, nowoczesna, ale też wiążą się z tym pewne koszty.

GF: Tak. I my tutaj trochę… Ja jestem przynajmniej trochę „na nie”, co do Headlessu i uważam, że to jest taki buzzword, jak to się mówi. Czyli takie słowo – chwyt marketingowy – które mówi: „Chodź, chodź, bo to teraz popularne, bo to najnowocześniejsza technologia” i tak dalej, a zapomina się o wielu elementach. I dzisiaj chcielibyśmy parę rzeczy rozwiać, dołożyć swoje pięć groszy odnośnie do całej tej dyskusji: „Headless czy nie Headless?”. Będziemy też patrzeć na nasze doświadczenie na bazie klientów, których obsługujemy, a obsługujemy klientów, którzy mają od 300 tys. obrotu na miesiąc do 7-, 9 mln na miesiąc. Czyli powiedzmy od 1 tys. zamówień w miesiącu do nawet 30–40 tys. zamówień w miesiącu. Więc, dość duża rozbieżność, ale tak czy siak, jest to rynek sklepów małych i średnich. I dzisiaj będziemy z tego poziomu o tym opowiadać i do tego będziemy się odnosić. To chciałem powiedzieć. Dodam też, że specjalizujemy się w PrestaShop, a samo PrestaShop, na ten moment nie wspiera Headlessu. Chociaż, my jako Convertis, dla jednego z naszych klientów, robimy całe API pod Headless, żeby klient mógł sobie zrobić front na innej technologii, a na back-endzie miał prestę. Kosztuje to już grubo powyżej 100 tys. Dla tego klienta jest to bardzo optymalna technologia i rozwiązanie. Natomiast, widzimy plusy i minusy. I po doświadczeniach z budowy tego API, i rozmawiając z różnymi klientami z normalnych sklepów, takich mniejszych, takich większych, ale też ogromnych, ja mam pewne przemyślenia. Dla mnie, Paweł tutaj jest ekspertem, bo ja od technologii jestem dość daleko. Jak ja to mówię: „Ja tylko studiowałem elektronikę, do programowania trochę daleko było, więc…”. No właśnie. Zacznijmy. Pawle, może Ty powiedz, czym jest ten Headless.

PK: Czym jest Headless? Generalnie, jest to nowsza technologia, architektura oprogramowania. Różni się ona od tradycyjnej, tym, że jest podział na aplikację front-endową i back-endową. Cały czas będę mówił w kontekście sklepów internetowych – mogą być to różne aplikacje webowe, ale załóżmy, że jest to sklep internetowy. W tradycyjnym sklepie internetowym mamy jedną aplikację – aplikację sklepu, która realizuje różne funkcje biznesowe, jest na serwerze i generuje na końcu, na swoim wyjściu, widoki sklepu internetowego, które klient przegląda na przeglądarce. I to wszystko jest w ramach jednej aplikacji. Ta aplikacja też realizuje tę całą mechanikę, logikę biznesową – dodawanie do koszyka, odejmowanie do koszyka, realizację zamówienia. Przy Headless następuje podział na front-endową aplikację, czyli zupełnie niezależną aplikację, i back-endową aplikację. Back-endowa aplikacja znajduje się na serwerze. Ona realizuje tę mechanikę biznesową – realizację zamówienia, przygotowanie listy produktów, dodawanie, odejmowanie do koszyka. Natomiast, generowanie widoków sklepu – to, co klient widzi, to w co klika i cała ta obsługa jakby front-endowa, ten user experience – jest na urządzeniu końcowym użytkownika, w aplikacji front-endowej, zupełnie niezależnej. Obie te aplikacje komunikują się ze sobą przez API, przez interfejs API, który jest ustandaryzowany i za pomocą, którego aplikacja front-endowa otrzymuje dane od aplikacji back-endowej i przez który wysyła dane do aplikacji back-endowej.

GF: Czyli, dla mnie to jest tak, jakbyśmy mieli nasz mózg. Mamy lewą i prawą półkulę i do tego pośrodku mamy parę mostów, przez które te nasze półkule się komunikują. Tak? Każda z tych półkul jest za coś innego odpowiedzialna. A to API, czyli taki most pomiędzy półkulami, odpowiada za to, żeby dobrze przesyłać te informacje.

PK: Dokładnie. Żeby nie było za dużo bałaganu, to most jest jeden. API jest jedno. I założenie jest takie, że możemy zmieniać sobie niezależnie tę aplikację front-endową i tę aplikację back-endowdową. Znaczy, niezależnie front-endową od back-endowej, pod warunkiem, że to API jest jak najbardziej najdłużej stałe i niezmienne.

GF: Okej. Dzięki Pawle za wyjaśnienia. Ja, przygotowując się do tego podcastu i w sumie do tego, żeby napisać jakiś większy artykuł o tym – dlaczego tak lub nie Headless? – trafiłem na parę raportów. Na stronie internetowej podamy linki do tych raportów, gdzie można je znaleźć. Jeden jest od Divante, specjalizującego się w dużymi wdrożeniami (ma 300 osób). I jeszcze dwa inne raporty z różnych dwóch firm, które zrobiły to całkiem porządnie i fajnie opisały. Z Webscale. I przejrzałem różne firmy, rozmawiałem też z różnymi osobami na temat Headlessu. W podcaście o PrestaShop „Wszystko o PrestaShop”, gdzie rozmawiam z Łukaszem Janikiem i Krystianem Podemskim, również pojawił się temat Headlessu. Gdy analizowałem ten cały temat, to się zastanawiałem – kto promuje Headless? I patrząc na te różne podsumowania, są to zazwyczaj duże firmy, które rozwijają rozwiązania głównie korporacyjne i są to rozwiązania dla dużego biznesu, gdzie jest bardzo duży ruch. Powiedziałbym, że z 30-, 50-tys. użytkowników jednocześnie, głównie jest to właśnie taki korporacyjny. I na przykład w raporcie Webscale – to jest taka firma, która proponuje różne skalowalne rozwiązania – mają raport „Global Headless Report”. Zrobili badania z różnymi właścicielami e-commerce i nie tylko. I głównie były to duże e-commerce. Z ich badań wynika, że jeśli ktoś decyduje się na Headless, to jako najbardziej preferowany front-end i back-end, kombinacja, to byłby Magento i React. Samo Magento i zbudowanie sklepu na Magento to jest przynajmniej 300 tys., a najpewniej 500 tys. – za samo wdrożenie. I to połączenie wybierają zazwyczaj agencje. Natomiast, właściciele sklepów wolą VM Ware i React, jako front-end i z back-endu Salesforce i SAP. Przez taki wybór na back-end, od razu nasuwa mi się myśl, że w badaniu wzięły odział korporacyjne sklepy. I gdy się czyta taki raport, to się zastanawia: „Kurdę, wszyscy mówią, że Headlerss jest fajny. Musimy tam iść”. Ale proszę zwrócić uwagę, kto to mówi. To jest bardzo ważne – kto to mówi, kto Wam proponuje ten Headless. Tak jak Paweł powiedział, to jest utrzymanie dwóch aplikacji – front-endowej i back-endowej. To są znacząco wyższe koszty. Gdy rozmawiam z różnymi agencjami, które wdrażają Headless, mówią, że koszty zwiększają się o przynajmniej 30% na wdrożeniu. Bo tyle to kosztuje. Z drugiej strony, jak się przyglądałem, Divante też popełniło taki superraport: „14 narzędzi dla Headless”. Ale Divante specjalizuje się w dużych wdrożeniach. Firma w zeszłym roku, została sprzedana za ponad 250 mln zł – plus minus, jeśli dobrze pamiętam. 300 osób na pokładzie i z tego, co słyszę, to nie biorą się za projekty poniżej 0,5 mln. Chociaż mogę się mylić, pewnie są wyjątki. I też ten ich raport jest pisany głównie o enterprise. Na to chciałbym zwrócić pierwszą uwagę – jeśli ktoś Was namawia na Headless i mówi, że „To jest dla Ciebie”, to się zastanów czy to na pewno ten etap. Czy może poczekać, czy może jeszcze to nie jest to? Czemu o tym mówię? Ponieważ większość z Was – czyli takie biznesy, z którymi my współpracujemy, od 300 tys. do paru milionów miesięcznie – to jednak ten budżet na technologię ma ograniczony. I kuszenie się na to, żeby wejść już w Headlles, może być strzałem w kolano. Dzisiaj chciałem z Pawłem omówić parę plusów i parę minusów odnośnie do Headlessu. I czy na pewno to tylko można zrealizować w postaci Headlessu? A może można za pomocą zwykłego sklepu? Przejdźmy po kolei przez te różne rzeczy. Po pierwsze: Headless podobno jest bardzo, bardzo szybki. To prawda, Pawle, czy nieprawda?

PK: Tak, tak. Tylko trzeba sobie zdefiniować tę szybkość. My mówimy tutaj – pewnie chodzi nam o to, w jaki sposób, jak szybko strona trafia do użytkownika, czyli ten czas odpowiedzi serwera, na co teraz dużą uwagę zwraca Google. W przypadku tradycyjnego serwera to jest czas wygenerowania tej strony. W przypadku Headless różnica jest taka, że jeżeli mamy serwer tradycyjny, to on musi wykonać całą pracę polegającą na wygenerowaniu strony, która trafia do klientów. Natomiast, w przypadku Headless podział obciążenia tą pracą jest na dwie części. Czyli tą back-endową i front-endową. I samo generowanie widoków na podstawie danych jest wykonywane w urządzeniu końcowym – czyli czy to w telefonie, czy w komputerze. To znaczy mamy obciążenia przerzucane na użytkownika końcowego, przez co następuje rozkład tego obciążenia. I jeżeli chcemy mierzyć szybkość, to tak – Headless jest szybsze, wydajniejsze (bardziej bym powiedział) przy dużym ruchu, przy dużych obciążeniach. Bo jeżeli weźmiemy sobie na przykład sklep, który ma mały ruch i ta ilość zapytań jest tam 20, 100 na sekundę, no to tradycyjne rozwiązanie też jest w stanie odpowiedzieć. Teraz Google nam podaje, że mniej więcej około 300 milisekund czas odpowiedzi generowania strony jest dopuszczalne, jakby było szybciej to super. Jeśli dłużej, to pojawia się już problem, ale też jeszcze jakoś jest dopuszczalne. Nie powinno się nigdy przekraczać – powiedzmy – tej jednej sekundy. I w przypadku tradycyjnych rozwiązań, tradycyjnych sklepów też można osiągnąć takie szybkości czasu odpowiedzi, ale do pewnego poziomu ruchu.

GF: Do jakiego poziomu ruchu?

PK: Tego nie jestem Ci w stanie powiedzieć, dlatego że mamy tu jeszcze jedną zmienną, mianowicie ten background, czyli sam sprzęt. Serwer też serwerowi nie jest równy. I w zależności od tego, ile wyłożymy pieniążków, to możemy zarówno w tej tradycyjnej architekturze, jak i w Headless, lepsze czasy osiągnąć, lepszą wydajność i mniejszą. Możemy zastosować różne technologie optymalizacji i też osiągnąć krótszy czas odpowiedzi bądź też dłuższy. Dlatego nie da się tak jednoznacznie powiedzieć, że od 1 tys. zapytań na sekundę następuje jakiś problem, albo już trzeba przejść na Headless. A do tego przykładowego 1 tys. to jeszcze nie. Nie ma takiej jednoznacznej odpowiedzi.

GF: Przez 1 tys. pytań rozumiesz użytkowników czy kolejny użytkownik generuje…?

PK: Tysiąc zapytań do serwera. Ale nie trzymajmy się tego. Ja to podaję jako taką totalnie wyrwaną z kontekstu liczbę. Po prostu, nie za bardzo jest jesteśmy w stanie to określić. Natomiast faktem jest, że możemy przygotować serwis w tradycyjnej technologii, który będzie całkiem szybko odpowiadał i będzie miał całkiem fajne wyniki. Do pewnego poziomu, po prostu, zwiększając wydajność serwera, stosując różne techniki optymalizacyjne, skalowanie i tak dalej. Ale przy technologii Headless powyżej… – przy dużym ruchu – mamy zawsze ten zysk, że część obciążenia pracą przechodzi na urządzenie końcowe użytkownika. Dodatkowo, po stronie serwera jest łatwiejsza skalowalność tej części back-endowej. To też dotyczy – to, co powiedziałeś – tych większych graczy, których stać na to, żeby zapewnić to dla swojego dużego ruchu. Bowiem duzi gracze mają duży ruch, żeby zapewnić dla swojego ruchu odpowiednie serwery, odpowiednią infrastrukturę z możliwością skalowania.

GF: Ale, z tego co mi się wydaje, żeby to ogarnąć, to już są kwoty, gdzie sam serwer kosztuje kilka, kilkanaście tysięcy złotych miesięcznie.

PK: Na pewno tak.

GF: I biorąc pod uwagę rozmowy z różnymi klientami, patrząc na to, jak my to robimy, to mamy sklepy, w których otrzymujemy po trzy, pięć tys. użytkowników jednocześnie i PrestaShop daje radę.

1. Tak.

GF: Oczywiście, nie jest to proste, trzeba się postarać i to odpowiednio zeskalować, natomiast daje to radę. I również z rozmowy z Krystianem Podemskim – ambasadorem presty – wynika, że są na świecie sklepy presty, które obsługują dużo większe ruchy i ich sobie radzą. My jeszcze takich sklepów nie obsługiwaliśmy. Czekam na takiego klienta. Więc, jeśli jesteś, to zapraszam. Natomiast w Polsce po prostu te sklepy są dużo mniejsze – 3 tys. użytkowników jednocześnie, to już jest spory sklep. A jeśli policzymy sobie, że taki użytkownik jest pół godziny, to zobaczcie ilu ludzi jest na stronie. Zostawiam Wam to, żeby policzyć sobie te rzeczy. Biorąc też pod uwagę to, co my robimy, a robimy też audyty PageSpeedu i nie tylko, optymalizujemy te różne rzeczy, i ja nie widzę różnicy w szybkości ładowania się tych naszych sklepów, w porównaniu na przykład do Headlesu, Jeśli jest on dobrze zoptymalizowany i zainwestuje się kilka, kilkanaście godzin, żeby to poprawić, może więcej. Jak ty to Pawle widzisz? Jak my to przyspieszamy? Ile to zajmuje, żeby to przyspieszyć, i żeby działo? Żeby to działało tak szybko, jak na przykład promują w Headlessie?

PK: To też jest wszystko względne. Ty mówisz – tak, jak promują w Headlessie. Nigdzie w tych materiałach promocyjnych, które przeglądałeś, czytałeś – że Headless jest taki super – też nie znajdziesz na przykład jednoznacznego miernika, że to są czasy 100 milisekund, albo że 200 milisekund, albo że obsługują 1 tys. użytkowników na sekundę albo 10 tys., albo 1 mln. Nie ma tam takich danych. I ich nie znajdziesz. To wszystko zależy. Wszystko zależy od specyfiki danego sklepu. Ile zajmuje… My zajmiemy się prestą – ile w przypadku tradycyjnego sklepu presty? Wszystko zależy od tego, jaki to jest sklep, jaką ma specyfikę. Jedni mają bardzo proste sklepy z małą ilością obrazków i mają sklepy z dużą ilością obrazków o dużej jakości, bo niektórzy wymagają dużej jakości. Niektórzy mają nawet filmy. Niektórzy mają spory ruch stały, a niektórzy mają taki nierytmiczny, że występują obciążenia chwilowe w okresie jakichś akcji promocyjnych. Niektórzy mają na przykład 20 produktów na sklepie, ale spory ruch, a niektórzy mają 20 tys. produktów, ale z kolei niewielki ruch, bo to jest jakieś B2B, gdzie jest mniejsza ilość zamówień, ale za to o większym nominale. I nie da się tego tak jednoznacznie przełożyć, ile to zawsze zajmuje. Z tą optymalizacją to jest zawsze troszkę pracy, dlatego że na szybkość sklepu wpływa wiele czynników. Po pierwsze mamy ten czynnik sprzętowy, czyli sam serwer – na ile on jest wydajny. I to jest jakby podstawa, bo jeżeli mamy słaby procesor, małą ilość pamięci, to nic tutaj nie zrobimy. Do tego jeszcze wchodzi wiele warstw różnych aplikacji. Serwer http, serwer MySQL, które możemy optymalizować, jakieś pośredniczące serwery keszujące, serwery Content Delivery Network, za pomocą których możemy też dostarczyć treść statyczną klientom końcowym. Mamy dużo możliwości. W zależności od tego, jaki jest sklep, jaka jest specyfika, jaki jest ruch, to możemy zastosować różne warianty o różnym koszcie. Za niektóre rzeczy trzeba też więcej zapłacić, za niektóre mniej. Przy preście również. Przy dużych obciążeniach też można zastosować skalowanie. Tylko że, też jest to już rozwiązanie na bazie infrastruktury, która kosztuje i nie da się jednoznacznie określić czasu, ile trzeba nad tym spędzić. Czasami zdarzają się nam w takie przypadki, że sklep działa wolno. Przychodzimy, klient nam zgłasza, że chciałby coś zrobić, bo w PageSpeedzie wyszło mu, że ma tam straszne wyniki i okazuje się, że wystarczy po prostu poprawić nieco layout, zoptymalizować kilka wtyczek, które przez lata sobie instalował i nie zwracał uwagi na to, że one są w jakiś sposób nieoptymalne. I okazuje się, że można uzyskać całkiem niezłe efekty.

GF: No właśnie, więc tu mamy taką miarę, jak to jest z tą szybkością. Czy tylko Headless zdaje ją, czy nie? Tutaj myślę, że z każdym z Was musielibyśmy porozmawiać i zobaczyć. Mój wniosek jest podstawowy – na pewno szybkość… Jak jest mały ruch i średni, cokolwiek to dla Was może znaczyć, ja bym powiedział do 5-, 30 tys. użytkowników jednocześnie, może mniej, to tutaj są porównywalne wyniki. Od pewnego etapu okazuje się, że ten Headless jednak jest tym must have i trzeba to zrobić, po prostu. To jest jedna z rzeczy, którą trzeba rozważyć przy Headlessie, czyli szybkość. Druga rzecz, to jest to, że Headless jest zbudowany na standardzie composable, czyli że każda aplikacja jest jakby oddzielna i komunikuje się poprzez API, tworząc mikroserwisy, co jest dużo prostsze niż na przykład jedno – monolityczne oprogramowanie. W ogóle teraz robi się tak, że pod sklep podłącza się coraz więcej aplikacji: wyszukiwarki, które potrafią wyszukiwać po obrazie i nie tylko, koszyk oddzielnie się podłącza, jakieś programy lojalnościowe, które są na zewnętrznej aplikacji. Czyli nie buduje się wewnątrz na sklepie, tylko na zewnątrz. Promocje różnego rodzaju, do tego opinie, które są zasysane z zewnętrznego systemu i tam to jest wszystko obsługiwane, gdzie cały kontent, który tworzymy. Jest oddzielny system do zarządzania tym, oddzielny system zarządzania produktami. I to wszystko łączy się poprzez API do jednego systemu, jakim na przykład jest nasz sklep. Ale to wszystko nie odbywa się w samym sklepie. I w tę stronę idzie świat, i przypuszczam, że za parę lat to się okaże, że będziemy musieli płacić za każdą taką aplikację nie do na przykład PrestaShop, czy Magento, tylko do zewnętrznych producentów, którzy dostarczają dany produkt. Będą to tak zaawansowane rzeczy, że samemu tego się nie uda zrealizować. Trochę tak jak teraz używamy, nie wiem, oddzielnie Google Docs, oddzielnie jakiegoś programu do zarządzania zadaniami, typy Asana. Oddzielnie emaile, oddzielnie w Zoom do komunikacji. I za każdą z tych aplikacji albo dostaniemy część za darmo, część za opłatą, ale do tego dąży cały e-commerce, bo to się profesjonalizuje. I teraz oczywiście Headless powoduje, że łatwiej podłączyć pod ten sklep te różne elementy, bo wszystko jest jakby cały sklep napisany w formule API REST. I ja się tak zastanawiam, że te nasze sklepy, które obsługujemy – to API do zrobienia, żeby się komunikowały z różnymi systemami – jest do zrobienia i to nie jest jakieś zbyt trudne, to można też zrobić. Oczywiście nie będzie to idealnie, tak jak na przykład w Headlessie, gdzie jest to od początku zrobione, ale z drugiej strony jest to dużo tańsze niż budowanie sklepu, od razu technologii takich mikroserwisów i tak dalej. Co Ty na to, Pawle?

PK: Tak, można przyjąć takie rozwiązanie. Nawet jest taka wtyczka opensource’owa, za pomocą, której możemy sobie uruchomić i odpalić w preście API REST-owe, za pomocą którego już coś takiego można zbudować. To zawsze – jeszcze tutaj nie powiedzieliśmy, jaki jest jeden z plusów Haadlessu – to jest możliwość budowania wielu aplikacji front-endowych, dedykowanych dla różnych środowisk. Czyli, jeżeli komuś bardzo zależy na tym, żeby – w tej dyskusji jakby zamknęliśmy się i tak mentalnie myśleliśmy o sklepie internetowym jako aplikacji przeglądarkowej – natomiast, jeżeli komuś bardzo zależy na tym, żeby zrobić dedykowaną aplikację, natywną na przykład na iOS-a i osobno na telefony Samsunga, na Androida, i zakłada, że przyniesie mu to większą sprzedaż, bo te odczucia użytkownika sprawią, że będzie się łatwiej robiło zakupy, to może założyć, że będzie miał oddzielne aplikacje front-ednowe na te systemy. I w tym momencie mamy jeden back-end, ale załóżmy trzy aplikacje, cztery aplikacje front-endowe. No to przy tych dużych graczach może w jakiś sposób podnieść zysk, bo przy wzroście sprzedaży, zyskując użytkowników tych, którzy wolą kupować na telefonie, a nie w przeglądarce i zysk na zwiększeniu tego nominału sprzedaży będzie na tyle duży, że stać go będzie na obsługę czterech aplikacji, bo Ty tam na początku powiedziałeś, że mamy dwie aplikacje zamiast jednej. To może być więcej niż dwie. Mogą być trzy, mogą być cztery do obsługi. Zaleta jest taka, że każdą z tych aplikacji możemy jakby serwisować osobno i rozwijać osobno, pod warunkiem, że nie będziemy naruszali API, czyli samego tego mechanizmu czy reguł wymiany tych danych. Sam back-end też możemy podzielić na mikro serwisy, jeżeli ktoś już chce iść w taką technologię, też w ten sposób optymalizując wydajność. Można to zeskanować, że pewne elementy będzie serwowała inna aplikacja bakc-endowa, a pewne inna, no ale to też już jest większy koszt.

GF: I to jest, w każdym razie, właśnie też plus Headlessu, że można go bardziej dostosowywać do poszczególnych urządzeń, rozwiązań. I teraz, jak pracujemy z klientami, to ja obserwuję, że to, co klienci chcieliby zrobić na froncie, w takim PrestaShop, czyli takim monolitycznym oprogramowaniu też da się to wszystko zrobić. Znaczy, powiedzmy – prawie wszystko. Pewnie nie da się zrobić oddzielnie aplikacji tu i tu, natomiast większość tych e-commerce nie potrzebuje tego, żeby mieć oddzielnie aplikacje. Parę lat temu, też był taki trend: „Róbmy aplikacje do sklepów internetowych”. Tak chyba z cztery lata temu, co rozmawiałem z klientami, to mówili, że dostawali oferty” „Zrób aplikację do sklepu internetowego”. I to było bardzo, bardzo popularne. Wielu klientów zdecydowało się na to.

PK: Chodzi Ci o takie aplikacje natywne, na Androida czy iOS-a?

GF: Tak. Było to drogie. Klienci często mówiąc: „Okej. Zrobię, bo to nowy kanał”, zapominali o jednej rzeczy. Że trzeba zachęcić klientów do instalowania tej aplikacji. Poza tym, to są ogromne koszty, żeby taką aplikację później utrzymać. Bo to jest podwojenie, potrojenie takich kosztów, bo są dwa oddzielne systemy, czyli iPhone i Android, gdzie trzeba to jakoś rozwijać, utrzymywać. Później weszło PWA, które trochę rozwiązuje ten problem, ale, tak czy siak, rzeczywistość pokazała, że użytkownicy telefonów nie chcą instalować aplikacji. Bardzo szybko je odinstalowują. I to, według mnie, nie ma większego sensu dla większości sklepów. Mogę podać tu przykład Rossmanna i Żabki, jak dużo ich kosztuje zachęcanie klientów do instalowania aplikacji, i jak dużo muszą oferować tym klientom, którzy mają tę aplikację, żeby chcieli w ogóle jej używać. Bo ludzie nie chcą. Nie chce im się wyciągać tej aplikacji, skanować i tak dalej. Jest to bardzo niekorzystne. I teraz, jeśli już mówimy o takiej elastyczności, to z drugiej strony, minusem takiego monolitycznego podejścia PrestaShop na przykład jest to, że mamy wszystko w jednym. I często w opracowaniach o Headless mówi się, że jak jest monolityczne oprogramowanie, to ono jest ciężkie do aktualizacji, do rozwiązywania kolejnych rzeczy, że jest jakiś dług technologiczny i parę kolejnych rzeczy, które powodują, że zniechęcają. Tylko to dalej jest mówione i komunikowane do firm typu enterprise, czyli firm, korporacji, które mają bardzo duże i powiązane z sobą oprogramowania, gdzie, jeśli mają coś zmienić, to jest masakra, bo to duży koszt jest. A w takim podejściu Headless Compose, który jest częścią technologii composable, czyli mogą wymienić łatwo każdy z elementów, nie muszą całego systemu wymieniać, bo poszczególne części, wymieniają się danymi w jakiś tak zwany most, czy poprzez API. I to na pewno jest prostsze. Natomiast pytanie, ile, drodzy klienci, drodzy słuchacze, macie Wy, takich systemów, które musicie używać. Teraz w Polskim e-commerce, takim mostem staje się chyba Buzz Link, do którego wszystko podpinamy, i tyle.

PK: Tak, tak. Tylko, tutaj też jest taki trik. Bo z jednej strony mówisz, że jest łatwiejsze w modyfikacji czy modernizacji, bardziej elastyczne – i to prawda. Ale gdzieś tu się przemyciło takie słowo, że jest to wtedy tańsze. No nie do końca. Dlaczego modernizacja ma być tańsza? Ona faktycznie jest może łatwiejsza, bo jeżeli chcemy zmodyfikować coś w tej aplikacji back-endowej, to modyfikujemy tylko tam, a nie musimy tego modyfikować w trzech aplikacjach front-endowych, bo są osobno. Albo, jeżeli chcemy zmodyfikować coś w jednej aplikacji front-endowej, na przykład na Androida, bo weszły jakieś nowe funkcje, to nie musimy tego samego implementować w aplikacji webowej fornt-endowej. Więc, jest pewna elastyczność, ale czy wprowadzenie tych modyfikacji będzie tańsze niż w takim monolicie tradycyjnym? No nie wiem. Tak czy siak, musimy za to zapłacić, żeby ktoś to zrobił.

GF: Tak.

PK: Więc, to bywa różnie. Też jest kwestia tej skali, na ile my modyfikujemy system i jak często go aktualizujemy.

GF: Tak. Tu właśnie przechodzimy tak naturalnie do tych minusów. I z tych wszystkich, tak jakby sumując, to przede wszystkim utrzymanie Headlessu – to są wysokie koszty rozwoju i utrzymania później.

PK: Po pierwsze jest tu klucz – rozwój. Czy zakładasz rozwój?

GF: Tak.

PK: Jeżeli cały czas chcesz pracować nad tym, żeby ten swój sklep internetowy rozwijać, zmieniać, modyfikować. No to tak. To musisz mieć świadomość tego, że będziesz ponosił koszty.

GF: A czemu wysokie koszty? Podam taki przykład. Wyobraź sobie, że chcesz zrobić dodatkową promocję, na jakiś produkt. Chcesz zrobić promocję „3+1”, czyli ktoś kupi trzy produkty i czwarty dostanie gratis. To monolitycznym podejściu, w preście, musisz napisać jedną aplikację, która będzie to obsługiwać od frontu, od back-endu, i ona jest dość prosta. Prostsza niż zrobienie to w takiej technologii, jak Headless. Bo z jednej strony całą taką logiczną część musisz napisać w back-endzie, który to będzie wykorzystywał. Później musisz wysyłać te dane poprzez API do frontu, a we froncie oddzielna aplikacja, która będzie robić, jakby…

PK: W jakiś sposób to wizualizować.

GF: Wizualizować, pokazywać na poszczególnych stronach. Ona też musi być inteligenta, że na tej stronie to, to i tak. Ja już sobie wyobrażam, że to jest dwa razy więcej roboty. Może przesadzam. Z drugiej strony, jak rozmawiam z różnymi klientami, agencjami, które robią Headless, wynika, że to są koszty wyższe o przynajmniej 30%. To załóżmy, że to jest od 30% więcej do 100% więcej, w zależności od poszczególnych rozwiązań, które potrzebujecie. I też potrzebujecie mieć oddzielny zespół do back-endu i oddzielny zespół do front-endu. To są jakby dwie oddzielne technologie, dwa oddzielne rozwiązania, które komunikują się poprzez jakieś tam API. I to też komplikuje ilość pracy i zarządzanie tym. Tak? Pamiętajmy, że jeśli mamy dwie aplikacje, to ilość testów, które mamy do wykonania też jest znacząco większa, bo już nie wystarczy tylko przetestować jedną aplikację, tylko musimy przetestować back-end oddzielnie i oddzielnie front-end. No i to może być taki Zonk. Jak Ty na to patrzysz, Pawle?

PK: No tak, tak. Ja się z Toba zgadzam. Czasami klienci, którzy wchodzą dopiero w temat e-commerce i sklepów internetowych, to zakładają tak, że: „Zainwestuję. Zrobię sobie sklep internetowy i on będzie działał i pracował. I już, i koniec”. A to tak nie do końca jest. Technologie się zmieniają, środowisko się zmienia, rynek się zmienia, świadomość zmienia i na bieżąco coś trzeba robić. Niektórzy robią więcej, niektórzy zmieniają więcej, niektórzy tylko drobne jakieś modyfikacje front-endu, inni eksperymentują właśnie z promocjami, kampaniami promocyjnymi. I zawsze jest tak, że trzeba mieć świadomość tego, że wymaga jakieś koszty. Wymagają utrzymania modernizacji. I w przypadku, tak jakby porównujemy taką tradycyjną nie-Headlessową architekturę i Headlessową, i teraz pytanie – co jest, gdzie jest tańsza modyfikacja, gdzie jest droższa. To też zależy. Jeżeli ktoś chce zmienić jakąś drobną rzecz we front-endzie tylko, to właściwie to będzie podobny koszt. Ale jeżeli ktoś ma trzy aplikacje front-endowe na różnych środowiskach i będzie chciał zmienić sposób prezentacji produktów w trzech aplikacjach, to tak jak mówisz, to się mnoży. Jeżeli będzie chciał wymienić system płatności w swoim sklepie na inny, no to w przypadku PrestaShop, wystarczy zmienić wtyczkę. Może też dopasować, zainstalować i mamy gotową wtyczkę. A w przypadku takiej architektury Headless może być – tak jak mówisz – konieczność i modyfikacji i back-endu i front-endu. I to jeszcze tego front-endu w trzech egzemplarzach, na przykład. Więc to się faktycznie multiplikuje. Może nie do końca, tak jak mówisz, nie do końca to jest razy trzy, ale te koszty są spore.

GF: To jest z jednej strony, a z drugiej strony, skoro koszty są większe, to oczywiście wymaga to więcej też pracy, bo zazwyczaj koszty idą z ilością pracy. Po prostu wolniej i więcej czasu potrzeba, żeby zaimplementować takie rozwiązanie niż na przykład prestę. Tak? Czyli takie monolityczne rozwiązanie, Bo potrzebujemy i zaprojektować front, i back-end oddzielnie, wymyśleć jak to połączyć. Są oczywiście systemy, które to łączą i działają, i dają już jakieś rozwiązania. Natomiast, to dalej wymaga większej ilości czasu.

PK: Tak. Aczkolwiek, w przypadku tej architektury Headless, jest większa elastyczność. To znaczy, można sobie ten czas, o którym mówisz, że jeśli są jakieś modyfikacje, które mamy zaplanowane, to można sobie je rozłożyć. Część zrobimy tutaj w back-endzie, część we front-endzie i jakoś tam to podzielić. Też można, ale to wszystko zależy od specyfiki danej modernizacji. Tak czy siak, to wszystko zależy od tego, jaki mamy ruch i jaką mamy sprzedaż, i czy ten zysk z tej modernizacji związany ze wzrostem sprzedaży będzie nam spłacał koszty tych modernizacji. W przypadku tych dużych graczy, którzy mają duży ruch, dużą sprzedaż, no to mają możliwość, żeby cały czas modernizować i cały czas coś zmieniać na swoich sklepach, tak aby, aby uzyskiwać coraz lepsze wyniki.

GF: No właśnie. I przechodzimy do podsumowania – zastanowienia się, czy na pewno Headless jest potrzebny do małego, średniego sklepu, który ma obrót kilkaset tysięcy złotych, czy kilka milionów, kiedy warto, w ogóle, wejść w Headless? Czy na pewno to jest problem Headlessu, czy na przykład problem dobrego wsparcia? Jak tak się nad tym wszystkim zastanawiam, to jeśli masz kilkaset tysięcy obrotu, to w ogóle bym nie rozważał wchodzenia w Headless. Jeśli masz już z 8–10 mln, to być może już jest czas na przemyślenie, czy nie warto przejść. Tak naprawdę, ten Headless się rozwija i myślę, że tak na poważnie wejdzie za 3–5 lat, może 2–5 lat i to będzie takie must have. Natomiast ja bym nie podejmował teraz decyzji, żeby w to wchodzić. Niech konkurencja się wykrwawia, trochę niech się nauczy. Żeby inne agencje się nauczyły, żeby programiści się nauczyli, co tak naprawdę jest potrzebne w Headlessie. Tak jak kiedyś proponowali właśnie te aplikacje, żeby każdy sklep miał swoją i ludzie wchodzili, bo to miało być jakimś złotym środkiem do zwiększenia sprzedaży, a tak nie było. Ja bym się wstrzymał z tą decyzją, nie robił się liderem tego trendu, no chyba że jesteś liderem w ogóle w swojej kategorii i już masz ogromny sklep. Bo często myślę, że chcemy użyć zbyt dużego młotka do małego problemu. Z drugiej strony, często słyszę, że klienci narzekają, że jest wolny, i ten Headless ma być takim rozwiązaniem, bo przecież Headless jest szybki. A może ten sklep jest wolny, dlatego że nie masz programisty, który potrafi go przyspieszyć, albo może nie chciałeś na to wydać pieniędzy, żeby to przyspieszyć? Często widzę te problemy, takie podstawowe problemy w sklepach, nie dlatego, że jakieś oprogramowanie nie daje rady tylko, dlatego że prowadzący ten sklep nie był gotowy wydać pieniędzy na to, żeby rozwinąć to oprogramowanie. Presta ma za sobą jeszcze taki ogon, że to opensource’m, więc się wydaje, że to jest bezpłatne oprogramowanie. Bardzo dużo ludzi narzeka na to, że tam jest dużo błędów, że to jest wolne, brzydkie i tak dalej. I takim wybawicielem miało być wejście na Magento. Bo przecież tam wszystko tak fajnie działa, szybko i tak dalej. Różnica była tylko taka, że ci, co wchodzili na Magento, to widzieli, że muszą za każdą rzecz zapłacić, więc wszystko dało się naprawić, poprawić i tak dalej, a ilość tych błędów była podobna. Natomiast, przy preście większość tych klientów narzekała, a nie sięgała do kieszeni. I dlatego, wydaje mi się, że z takimi, którzy w PrestaShop nie dają rady albo jakiś inny system nie daje rady, po prostu trzeba wziąć trochę pieniędzy, otworzyć kieszeń i to zrobić. Więc to jest jedna rzecz. Kolejną rzeczą jest to, czy nasz sklep jest tak bardzo skomplikowany? Ile tak naprawdę mamy różnych serwisów, które komunikują się z naszym sklepem? Bo jeśli ktoś ma multichannel, czyli jeszcze ma sklepy stacjonarne i tam ogromny system do zarządzania tym, na przykład sprzedażą, do zarządzania stanem magazynowym, a do tego ma różne inne systemy, które muszą komunikować, no to taki Headless może pomóc, bo to wszystko tam jest, a komunikacja jest poprzez API. Natomiast, mamy klientów, którzy mają kilkanaście, kilkadziesiąt sklepów i mają sklepy w formie monolitycznej, i to działa. Ja bym powiedział, że jeśli chcieliby zmienić na Headless, to byłoby to… Musieliby zmienić wszystkie systemy, które mają obecnie, żeby to miało w ogóle ręce i nogi, i wymagałoby to znacznego inwestowania i zmiany myślenia, co do tego. Wiele osób mówi: „Bo Headless daje mi przewagę w przyszłości”. Czy na pewno Ci da? Czy na pewno wykorzystasz potencjał jaki Ci da Headless? A czy to nie będzie też tak, że teraz jesteś jeszcze trochę za mały i po prostu poświęcisz za dużo czasu i energii, żeby to rozwijać? Może to nie jest moment? Ja jestem zwolennikiem całej technologii lean startup, czyli zaczynajmy krok po kroku, od małych narzędzi, od tego co nam teraz wystarczy, ale gdzieś tam z tyłu, myśląc, że kiedyś chcemy być więksi dwa razy, pięć razy, dziesięć razy, i pod to podpierajmy, ale nie róbmy wszystkiego od razu na tip-top, bo to jest według mnie, wyrzucanie pieniędzy. Inaczej się to źle skończy. I ja to widzę, gdy wdrażamy różne sklepy internetowe i klienci przychodzą z dziesiątkami różnych funkcjonalności, które by chcieli robić, a później, gdy z nimi rozmawiamy, pół roku pytamy, ile tych funkcjonalności użyli, to się okazuje, że duża część z nich nie jest używana. Że to były w wyrzucone pieniądze w błoto, bo nikt tego nie używa, bo to był fajny pomysł, ale tak naprawdę nie było kiedy i jak tego używać. No właśnie, Pawle, jak Ty byś podsumował to, o czym tutaj rozmawialiśmy?

PK: Ja się z Tobą zgadzam. Headless będzie się popularyzował i próg wejścia będzie coraz niższy, bo będzie coraz więcej standardowych rozwiązań przygotowanych dla Headlessu, które będzie można uruchomić. Ale, tak czy siak, zawsze będzie to wymagało dopasowania do Twojego biznesu. To, co dosyć często powtarzasz, że zaczynając sklep od zera, to lepiej zacząć od SAAS-a. I nie przewiduję, że kiedyś SAAS-y przestaną istnieć na koszt Headlessu. Zawsze będą istnieć. I tak samo przypuszczam, że rozwiązania monolityczne sklepów internetowych też będą istnieć. Jest tylko kwestia rozwoju firmy i tego głównego motywatora. Głównym tym motywatorem, gdzie określamy: „Przychodzimy na Headless” albo „Zaczynamy od Headless”, to jest wyłącznie ruch na sklepie i obciążenie.

GF: I takie jest nasze podsumowanie. Więc, drodzy słuchacze, nie polecamy. Jeśli nie jesteś dużą firmą, nie polecamy kombinowania za bardzo, bo to tylko skomplikuje Ci życie. Natomiast, jeśli masz inne zdanie, to zapraszamy do komentowania. Czy tutaj pod postem na naszej stronie, czy na LinkedInie, czy na jakiejkolwiek innej platformie. Z chęcią podyskutuję. I nawet jestem gotów nakręcić kolejny odcinek o tym Headlessie. Jeśli ktoś chciałby o tym pogadać, to zapraszam. I dzięki za wysłuchanie. Dzięki, Pawle, za pogaduchy.

PK: Dzięki.