#9 Headless Shopify - zalety i wady | Flying with Shopify: Expert Insights | E-commerce | Shopify

Cześć, z tej strony Maciej Czerniak, a to jest kolejny odcinek naszego programu Flying with Shopify. Dzisiaj razem z moim wspólnikiem Kamilem zastanowimy się nad tematem Headless, czyli trendu w e-commerce, który przez ostatnie parę lat zyskuje na uwadze i popularności. I zastanowimy się nad tym, kiedy to podejście do budowania e-commerce jest, a kiedy nie, dobrym pomysłem. Nie wiem, czy przeglądasz sobie czasami naszego Hubspota i co tam klienci do nas wypisują w zapytaniach?

Zdarza mi się. Zdarza się. Ja ostatnio trafiłem na takie ciekawe właśnie zapytanie, które skłoniło Skłoniło nas do tego, żeby nagrać właśnie dzisiejszy odcinek, a mianowicie napisał do nas klient, który potrzebował przejścia z Headless na Liquid, czyli ma już wydarzony Headless, ale potrzebuje się cofnąć. No i co się tam wydarzyło? Pisze do nas, że agencja przekonała go do wdrożenia e-commerce w tym podejściu, ponieważ byłoby to bardziej kompatybilne gdzieś tam z konfiguratorem produktu, jego panelem klienta, jego specyficznymi wymaganiami. Natomiast z biegiem czasu po wdrożeniu okazało się, że

Generuje to więcej problemów niż korzyści. No i chciałbym zrobić krok wstecz. No i wydaje mi się, że to jest dobry przyczynek do rozmowy o tym, kiedy rzeczywiście powinniśmy w ten Headless jeść. Ale żeby otworzyć na to pytanie, to może zaczniemy od tego, czym w ogóle Headless E-commerce, czy Headless Shopify. Jest. Rzeczywiście bardzo, zanim przejdziemy do tego tematu, powiem tyle, że bardzo chętnie bym się dowiedział w szczegółach, jak wyglądał proces wyboru tego narzędzia, jak został przeprowadzony research, jak zabrane zostały wymagania odnośnie technologii, czy sposobu w jaki biznes w ogóle funkcjonuje. Bo są to takie ważne elementy, które determinują to, czy na Headless w ogóle się zdecydujemy, czy zostaniemy przy rozwiązaniu takim natywnym.

Druga sprawa, To świadomość w momencie podejmowania takiej decyzji. Wszelkie analizy i badania pomogą nam tę decyzję podjąć, podjąć świadomie. No ale co chyba najważniejsze tak naprawdę, jaki morał w ogóle z tej historii, to to, że Headless pomimo tego, że tak jak powiedziałeś, jest bardzo ostatnio popularny, jest takim nośnym tematem, dużo ludzi o nim mówi, pisze, pojawia się naprawdę często. To wbrew pozorom nie jest to remedium na wszystkie bolączki. Trzeba być tego świadomym, bardzo mocno zdawać sobie z tego sprawę i pamiętać przy wyborze Headless jako rozwiązania dla nas. No dobrze, to zaczniemy od początku.

Tak właśnie, zaczniemy od początku i w ogóle czym ten Headless jest. Zakasamy rękawy i bierzemy się do roboty, bierzemy byka na rogi. Żeby w ogóle zacząć rozmawiać o Headlessie, musimy cofnąć się krok do tyłu i w ogóle porozmawiać o architekturze Mach. Bo jest to coś szerszego, coś bardziej rozbudowanego. Math to ta nazwa składa się z czterech liter. M-A-C-H. M oznacza mikroserwisy. A oznacza podejście API first. C odnosi się do usług hostowanych murowo. Dopiero H jest naszym Headlessem, więc jak widzimy jest to element szerszej perspektywy.

Headless, czyli ten ostatni element w architekturze, To nic innego jak odseparowanie czy też rozbicie w naszym wypadku e-commerce na dwa elementy. Przy podejściu headlessowym mówimy o tym, że nie korzystamy z natywnej templatki czy też z templatki, którą sami zbudowaliśmy i która jest osadzona wewnątrz naszego sklepu na Shopify, tylko decydujemy się na to, żeby ten frontend odseparować i wystawić go w innym miejscu, jak taki osobny byt stworzony, customował przez nas. Frontend rozumiany jako ten element serwisu, po którym porusza się użytkownik. Tak, dokładnie. Interfejs użytkownika. Nominalnie ten interfejs użytkownika serwowany jest, czy też dostarczany, mówiąc trochę bardziej po polsku, dostarczany na swojego użytkownikowi od środka, jakby bezpośrednio przez Shopify.

Tam generowana, renderowana i dostarczana jest ta treść. Natomiast w przypadku Headlessa, Nie korzystamy z tego. Wykorzystując element architektury Mach, czyli komunikację po API, odwołujemy się do naszego silnika e-commerce, żeby pewne dane pobrać, pewne dane wysłać. Jaka jest korzyść z tego rozdzielenia, tej warstwy frontowej od backendu? Tak naprawdę tych korzyści jest bardzo, ale to bardzo dużo. Jednym z takich elementów, który bardzo często pojawia się w rozmowach z naszymi klientami, to jest poprawienie performance. Mówimy o tym, Mam wrażenie, że to jest w ogóle chyba taki element, który jest najczęściej kojarzony z headlessem i chyba główny motywator w przypadku wielu biznesów do tego, żeby coś zrobić headlessowo, bo wtedy strona będzie po prostu szybsza i nie patrzymy na nic innego.

Drugim takim najczęstszym motywatorem do tego, żeby w ogóle rozważyć headless jest elastyczność. To naprawdę jest fakt, na to warto zwrócić uwagę. Wspomnieliśmy o tym, że możemy mieć kilka mikroserwisów, kilka elementów naszego ekosystemu. Wspomnieliśmy o tym, że sami decydujemy się na zbudowanie naszego interfejsu użytkownika, tego front-endu. Załóżmy, że mamy sklep e-commerce, a zupełnie w innym narzędziu, na innym CMS-ie mamy bardzo rozbudowanego bloga. Dosłownie portal społecznościowy, ale zostawmy przy blogu. Może się okazać, że posadzenie bloga na subloanie nie spełnia jakichś naszych oczekiwań biznesowych czy funkcjonalnych.

Okej, ale rozumiem, że mówimy tutaj o sytuacji, w której potrzebujemy po prostu czerpać te dane z kilku różnych źródeł, bo wydaje mi się, że jeżeli, wiesz, mamy do świadczenia tylko rzeczy ze sklepu, produkty, jakieś tam, wiesz, zdjęcie, opisy i to wszystko, co jest przechowywane przez np. Shopify'a, No to też nie ma raczej żadnych ograniczeń, jeśli idzie o zbudowanie tego, tej warstwy frontowej. Przynajmniej ja tu ich nie widzę. Do pewnego momentu tak, natomiast jeżeli my chcemy i mamy taką potrzebę, żeby nasza ingerencja poszła jeszcze krok dalej, nawet w obrębie tego jednego narzędzia, jak na przykład, nie wiem, powiedzmy swój własny, w pełni skustomizowany check-out, to wtedy, wtedy powinniśmy, czy też

Będziemy zachęceni do tego, żeby pójść w kierunku tego rozwiązania headlessowego. Okej. A co w kontekście tej elastyczności, co z różnymi integracjami, które już mamy? No to jest właśnie bardzo ciekawe zagadnienie tak naprawdę. Mówimy o skalowalności, elastyczności i te elementy są wymieniane jako takie oczywiste, bardzo ważne, fundamentalne wręcz korzyści, jeżeli chodzi o headlessa. Natomiast jest tutaj właśnie taka mała pułapka Shopify, W takim podejściu out of the box, czyli w tym podejściu natywnym, pewne elementy, pewne struktury danych, pewne komponenty dostarcza nam sam z siebie i korzystając z tego podejścia templatkowego, kiedy mamy skórkę zaprojektowaną, stworzoną przez nas albo kupioną gdzieś w sklepie,

Te produkty, te komponenty, te moduły i funkcjonalności są dla nas dostępne w bardzo, ale to bardzo prosty sposób. Jeżeli natomiast wyjdziemy z tego obszaru i zdecydujemy się na podejście headlessowe, musimy zdawać sobie sprawę z tego, że wszelkiego typu apki, moduły, dodatki, które kupimy sobie do naszego sklepu niestety nie będą działać. Wynika to bezpośrednio z tego, że, tak jak powiedzieliśmy już, co najmniej dwukrotnie, korzystamy tutaj z API do komunikacji pomiędzy naszym storefrontem, a zapleczą naszego sklepu, czyli silnikiem Shopify. I niestety te aplikacje nie są dostępne z tego poziomu. Nie są dostępne w API. Więc jeżeli chcemy włączyć jakieś klavio, czy jakieś inne narzędzie do automatyzacji marketingu, czy jakąkolwiek inną aplikację,

To zazwyczaj będziemy aktualizowali i wprowadzali usprawnienia do jednego, dwóch komponentów, które z danego komponentu korzystają. Możemy też myśleć tutaj o korzyściach związanych z tym, że dostawcy, producenci poszczególnych narzędzi, technologii będą te narzędzia rozwijali i dzięki czemu będziemy zyskiwali na tym Będziemy zyskiwali w tym aspekcie. Niemniej jednak, dlaczego nie wydaje mi się to takie czarno białe, bo widzimy jak bardzo szybko i w jakim zakresie Shopify rozwija swój własny silnik. Rozwija nie tylko sam core,

Ale dodaje szereg nowych funkcjonalności. Poza tym bardzo uważnie słucha swoich użytkowników i odbiorców. Trzeba przyznać, że są naprawdę świetni w obserwowaniu tego, jakie są potrzeby rynku. Więc dobrze też idzie im w dostarczaniu tych dodatków, usprawnień i nowych elementów. Tak więc jestem tutaj raczej spokojny o to, jak będzie wyglądała przyszłość i czy te potrzeby będą zaspokajane. Nie jest to takie, jak powiedziałem, takie super czarno-białe, że to jest gwarancja, bo w przeciwnym wypadku będziemy mieli problem. Wydaje mi się, że warto też napomknąć o tym, że Shopify jest, pierwsza sprawa, super przygotowane pod podejście Headless, bo do wszystkiego mamy API i możemy się fajnie komunikować ze wszystkimi obszarami e-commerce, ale druga sprawa, Shopify sam jakby inwestuje.

Mocno w to podejście i rozwija swoje własne rozwiązania i usługi wokół Headlessa. Mam tu na myśli Hydrogen, Oxygen czy zakup jakiś czas temu CMS-a Sanity. Dokładnie, ale świadczy to tylko o dwóch rzeczach. Po pierwsze o tym, że Headless rzeczywiście jest nośnym tematem. Wynika to bezpośrednio z potrzeb rynku. Mamy coraz bardziej skomplikowane biznesy, tych usług jest coraz więcej. Potrzebujemy łączyć i integrować ze sobą naprawdę bardzo różne elementy i te dane, które wyświetlane są na store froncie, mogą pochodzić naprawdę z różnych miejsc. A drugi element, o którym chciałem powiedzieć, to właśnie to, że są naprawdę dobrymi obserwatorami i aktywnie patrzą na to, żeby ich produkt był po prostu na czasie.

Uruchomienie w ogóle platformy, czy podejścia headlessowego w ramach Shopify jest tylko dowodem na to, że rynek po prostu potrzebuje tego rozwiązania. No wydaje mi się, że to wynika troszeczkę też z takiej strategii, którą też Shopify wdraża, direct to customer, w sensie, żeby być, prowadzić sprzedaż tam, gdzie jest ten klient. Więc z jednej strony oczywiście to są inwestowanie i rozwijanie w sprzedaż w różnych kanałach social media, czy to na YouTube, Pinterest, TikTok i tak dalej. Ale z drugiej strony to podejście headlessowe daje nam tę możliwość, żeby i wydaje mi się, że chyba to nie wybrzmiało gdzieś tam na początku, że tym store frontem niekoniecznie musi być sklep internetowy. To mogą być inne rzeczy. Dokładnie.

Najlepszym przykładem tego może być aplikacja mobilna, gdzie mówimy o natywnej aplikacji mobilnej, nie o stronie RWD. Tak jak powiedziałeś, wtedy Storefront jest po prostu natywna aplikacją instalowana na naszych telefonach, a silnikiem e-commerce'owym, czyli tym, co w tle przeprowadza całą transakcję, może być właśnie Shopify. No to mogą być też jakieś ten wearables, różne tam smartwatcha, kioski, info kioski, czy asystent głosowy. Czekam na to, w jaki sposób będzie można robić zakupy przez czatę NGPT, czy inne tam narzędzia do sztucznej, sztucznej inteligencji.

Dokładnie tak. Można też jeszcze do tej bardzo długiej listy dołożyć na przykład platformy, które umożliwiają nam zrobienie zakupów wiadomości tekstowych, zwykłym SMS-em. Można potwierdzić transakcję jakiejś oferty, którą dostajemy właśnie na SMS-a i w ten sposób złożyć zamówienie produktu, który na przykład zamawiamy często i spodziewamy się tego, że miesiąc po ostatniej transakcji nasz dostawca Zwróćcie się do nas z zapytaniem, czy nie chcemy kupić danego produktu. Wydaje mi się, że takim argumentem, który też często się pojawia w rozmowach na temat Headlessa jest taka dowolność technologii i to jest, mam wrażenie, że głównie argument podnoszony przez deweloperów, że dzięki temu oni mogą sobie zrobić frontend w tym, czym chcą i niekoniecznie muszą się uczyć liquida, która akurat jest relacyjnie prosta do nauczania się, ale często się pojawia i taka uwaga.

Co o tym myślisz? Uważam, że jest w tym na pewno trochę racji, ale Wydaje mi się, że kluczowy jest jakby powód dostania takiej opinii. Otóż Shopify jako narzędzie SaaSowe ma pewną swoją architekturę. Ma pewne swoje wymagania, ale też ograniczenia. Operowanie w tej relatywnie zamkniętej przestrzeni może powodować pewien dyskomfort u naszych kolegów i koleżanek. I może dlatego chętniej sięgają po narzędzia bardziej otwarte. Chciałbym jednak tylko zaznaczyć, że wraz z przejściem do architektury otwartej nie jesteśmy w stanie skorzystać z tych dobrodziejstw, które jednocześnie produkty sosowe dostarczają.

Takim przykładem, pomimo tego, że jest ich wiele, może być np. dostęp do pewnego rodzaju obiektów, które np. w Shopify wyświetlanie wszystkich produktów, Przy podejściu natywnym jest operacją banalną, a przy podejściu headlessowym musimy zwracać uwagę na limit operacji, które nasze API jest w stanie obsłużyć w jednostce czasu. Nie jest to takie czarno-białe. Wydaje mi się, że te problemy, o których mówisz Shopify, stara się rozwiązać w ten sposób, że oferuje właśnie ten swój framework headlessowy Hydrogen, który ma pewne wspólne, coraz więcej, bo to się zmienia, ale ma coraz więcej właśnie tych metod likwidowych i ma dostęp do tych obiektów, o których mówisz.

Na pewno będzie to rozwiązanie, które połączy te dwa światy. Z jednej strony będziemy mieli rozwiązanie markowane, firmowane przez Shopify, dzięki czemu można spodziewać się tego, że będzie posiadało więcej metod i możliwości dostępu do danych niż API obecnie, a jednak wykorzysta tą elastyczność i swobodę działania, której doświadczamy korzystając z innych technologii headlessowych. No dobrze, porozmawialiśmy trochę o tych korzyściach Headlessa i tak mam nadzieję, że udało nam się pokazać, że to co czasem jawi się jako taka oczywista korzyść ma swoje drugie dno i nie jest często takie naznaczne. Chciałbym, żebyśmy teraz porozmawiali jakby o tym z drugiej strony, czyli o wadach tego

Rozwiązania i myślę, że też możemy zaspoilować, że też nie jest to takie czarno białe, zero jedynkowe i trzeba po prostu uwzględnić, że wszystko zależy od kontekstu, od sytuacji, w której jesteśmy. Na pewno jest tak jak mówisz, że nie ma narzędzia idealnego. I po raz kolejny to powiemy, Headless takim narzędziem nie jest. Chociażby ze względu na swoją złożoność będzie wymagał trochę więcej czasu na development, na stworzenie tego narzędzia. To co powiedzieliśmy, niektóre moduły są niedostępne, nie możemy korzystać z obrozień z produktu sosowego, wszystko musimy zrobić własnymi rękami. Dlatego czas potrzebny na stworzenie takiego narzędzia jest dłuższy niż przy podejściu natywnym.

Jeżeli czas, to automatycznie koszt. Możemy spodziewać się, że ta inwestycja pochłonie więcej środków. Dodatkowo Shopify sam w sobie przy podejściu natywnym jest rozwiązaniem, tak jak powiedziałeś wcześniej, które można zrobić prawie że samemu. Przy jakiejś tam znajomości tego narzędzia i wiedzy takiej ogólnie technologicznej, chociaż są sklepy, które powstały przy udziale osób niezwiązanych z branżą IT. Tutaj niewątpliwie będziemy potrzebowali już programistów, programistów, którzy mają już odpowiedni skillset, odpowiednie doświadczenie komercyjne, będą potrafili zbudować taką rozbudowaną architekturę. Będą potrafiły poradzić sobie z taką bardziej rozbudowaną, skomplikowaną architekturą.

W związku z tym też możemy spodziewać się, że nakład finansowy, chociażby na ich wynagrodzenie czy zatrudnienie, będzie dużo wyższy niż w przypadku podejścia natywnego. Więc tutaj mamy co najmniej kilka takich aspektów stricte finansowo-biznesowych, które należy wziąć pod uwagę. Tutaj pewnie dochodzi też kwestia infrastruktury. Jeżeli stawiasz sobie ten storefront headlessowy, no to stawiasz go przeważnie póki co u siebie na swoim hostingu, więc musisz martwić się o ten hosting, o jego bezpieczeństwo, o to, żeby został utrzymany Ok, ale załóżmy, że nie decydujemy się, a nawet jeśli, to i tak zostaniemy obarczeni dodatkowymi kosztami, ponieważ to jest taki kolejny aspekt, który rzeczywiście będzie widać w naszym budżecie, ponieważ tak jak powiedziałeś, przy podjęciu tej decyzji o pójściu w Headless,

Musimy zapewnić sobie hosting. Na pewno też, tak jak powiedziałeś, będziemy musieli się o niego martwić, monitorować, dbać o to, żeby on działał, żeby ten uptime był jak najwyższy. Dostawcy oczywiście to zapewniają, ale jednak najważniejsze chyba jest to i trzeba to jasno powiedzieć, że zmartwienie jest mocne i przesunięte w naszą stronę. Przy podejściu natywnym Shopify bardzo mocno zbawa o wszystko i ilość tych naszych zmartwień jest mniejsza. Możemy skupić się wtedy na tym, co rzeczywiście jest ważne w danym momencie dla naszego biznesu. Mówiliśmy o tej kompatybilności, czy o tym z różnymi aplikacjami Shopify, o tym tak, że nie możemy de facto korzystać z tych dobrodziejstw, tak to nazwijmy, które gdzieś tam daje nam Shopify w postaci tego time to market i wdrażania różnych funkcjonalności.

Struktura linków. Nie możemy tego zmienić. Przechodząc z markupu do struktury linków, elementu dość istotnego z punktu widzenia SEO. W przypadku podejścia headlessowego mamy pełną dowolność i sami możemy zdeterminować, jakie rozwiązanie będzie dla nas najlepsze. Także wbrew niektórym opiniom uważam, że SEO przy podejściu headlessowym może zostać naprawdę dużo lepiej wykonane. No dobrze, to spróbujmy jeszcze zestawić tego Headlessa z takim tradycyjnym podejściem, tym powiedzmy monolitycznym, czyli po prostu tym szablonem Shopify zrealizowanym w oparciu o język Liquid.