Zrozumieć headless eCommerce - słowniczek pojęć i zagadnień

Wchodząc w świat headless commerce natrafić można na wiele pojęć, które są nowe i niezrozumiałe. Elementy, takie jak frontend, backend, framework czy API wydają się jasne tylko dla osób technicznych.

Pierwszym krokiem do stworzenia platformy headless commerce jest zrozumienie terminologii, której używa się podczas budowy takiego rozwiązania. W tym poście wytłumaczę Ci kluczowe pojęcia i zagadnienia, dzięki czemu próg wejścia w tematykę headless stanie się o wiele łatwiejszy do pokonania. Zaczynajmy!

Dzień z życia programisty

Zanim rozpoczniemy opisywanie zagadnień ze świata technologii headless, wyobraźmy sobie dzień z życia programisty:

Programista otrzymuje za zadanie zbudować sklep internetowy.

Zanim przystąpi do programowania, staje przed wyborem: czy stworzyć rozwiązanie w architekturze monolit, czy może headless.

Po wybraniu architektury staje przed kolejnym wyborem. Jaki framework do budowy strony sklepu internetowego wybrać?

Kiedy zdecyduje się na architekturę i framework, może przystąpić do programowania (czy też kodowania) aplikacji. W przypadku wyboru architektury headless programista musi stworzyć zarówno warstwę backend jak i frontend (o zaletach technologii headless przeczytasz tutaj). Warstwy te w jakiś sposób muszą się porozumiewać. Tutaj znów mamy pole do wyboru. Możemy zdecydować się na komunikację poprzez REST API lub GraphQL.

Po stworzeniu strony sklepu staje przed wyborem w jaki sposób hostować aplikację, czyli umieścić ją na serwerze (komputerze podpiętym do sieci, działającym 24 godziny na dobę) i udostępnić ją dla wszystkich użytkowników internetu poprzez wpisanie odpowiedniego adresu w przeglądarkę internetową. Do wyboru ma rozwiązania takie jak private VPS lub cloud server. Headless daje większe pole do wyboru sposobu hostowania i aspekt ten wykracza poza tematykę dzisiejszego posta. O sposobie hostowania aplikacji w modelu headless wkrótce napiszemy dedykowany artykuł na naszym blogu.

Skoro już omówiliśmy sobie, jak wygląda dzień z życia dewelopera oraz z jakimi zagadnieniami na co dzień się spotyka, teraz zagłębmy się w tematykę headless commerce i wytłumaczmy sobie, co to wszystko oznacza.

Frontend vs Backend

Zrozumienie rozdziału między warstwy front a back najlepiej będzie przedstawić na przykładzie:

Wyobraźmy sobie konsolę do gier typu PlayStation. Kupując PlayStation, kupujemy urządzenie, które pozwala nam na granie w gry, przechowywanie plików w pamięci itp.

Jednak to, do czego podłączymy tę konsolę, jest zupełnie dowolne. Może być to każdy telewizor, monitor czy jakiekolwiek inne urządzenie wyświetlające. Potrzebujemy jedynie odpowiedniego kabla, który połączy nasze PlayStation z wyświetlaczem i już możemy grać w nasze ulubione gry.

W tym przykładzie rolę backendu pełni PlayStation. Przechowuje ona logikę niezbędną do wykonywania funkcjonalności sklepu, oraz przechowuje i zarządza danymi. To jest jego główne zadanie. Nie przejmuje się, w jaki sposób te dane zostaną wyświetlone użytkownikowi.

Frontend natomiast jest warstwą wizualną aplikacji. Odpowiada za wyświetlanie danych użytkownikowi w jak najlepszy dla niego sposób oraz na interakcję użytkownika z aplikacją (nawigację po niej, wprowadzanie danych itp.). Daje to możliwość wprowadzania modyfikacji wyglądu aplikacji, bez ingerencji w warstwę logiczną aplikacji. Rozdzielenie warstwy frontend i backend umożliwia wprowadzenie unikalnych doświadczeń użytkownika, wyróżniając naszą platformę na tle konkurencji. Pozwala również na wdrożenie nowych kanałów sprzedaży oraz korzystanie z aplikacji na różnych urządzeniach.

Headless serwer dodatkowo udostępnia warstwę API, dającą dostęp do tych danych oraz funkcjonalności. Wyobraźmy to sobie jako wejście HDMI w konsoli PlayStation. Warstwa API jest stworzona optymalnie dla serwera, nie zwracając uwagi na to, jakie urządzenie będzie z niego korzystać. Jedynym wymaganiem jest używanie interfejsów API zgodnie z jego założeniami. Więcej o API dowiesz się w kolejnych akapitach tego wpisu.

Headless vs monolit

Co to jest architektura headless?

Architektura headless w języku programistycznym oznacza wydzielenie backendu od frontendu aplikacji.

Tradycyjne monolityczne podejście ściśle wiąże ze sobą bazę danych, backend oraz frontend. Powoduje to, że każda decyzja i zmiana na backendzie może wpłynąć lub ograniczyć zachowanie frontendu (oraz w drugą stronę). Rozwiązanie to było bardzo modne podczas tworzenia pierwszych sklepów internetowych, jednakże z powodów problematycznej modyfikacji, utrudnionego rozszerzania i innych kluczowych czynników, nie jest w stanie sprostać wymaganiom, które stawia przed nim nowoczesny rynek eCommerce.

Przykładami rozwiązań typu monolit dla sklepów internetowych są WooCommerce, Magento lub PrestaShop. Są to najczęściej wybierane rozwiązania do budowy tradycyjnych sklepów internetowych. Najbardziej popularne systemy zarządzania treścią oparte o monolit to WordPress i Drupal.

Wdrożenie technologii headless usuwa to połączenie. Backend (headless serwer) skupia się wyłącznie na przetwarzaniu i obsłudze logiki i danych. Podobnie frontend, który skupia się wyłącznie na tym, jak informacje są przedstawiane użytkownikowi w sposób jak najbardziej intuicyjny i szybki. Frontendem może być strona internetowa, aplikacja mobilna lub asystent głosowy np. Alexa. Podejście headless to najczęściej stosowane rozwiązanie podczas tworzenia nowoczesnych i największych sklepów internetowych, które stawiają na rozwój platformy.

Przykładami rozwiązań headless commerce są Medusa.js lub Saleor.

Jakie są zalety podejścia headless?

Backend:

• Użycie technologii headless zapewnia większą niezależność w tworzeniu logiki i warstwy API. Programiści nie muszą już tworzyć rozwiązań naokoło tak jak w rozwiązaniach typu monolit.
• Dzięki rozwiązaniu headless skalowanie oraz integracje z zewnętrznymi serwisami jest znacznie łatwiejsze.
• Większe bezpieczeństwo - w interakcje z backendem wchodzi tylko frontend, który zazwyczaj utrzymywany jest w innym miejscu niż backend. Użytkownik nie ma dostępu do backendu, a co za tym idzie, nie może samodzielnie ingerować w bazę danych.

Frontend:

• Frontend aplikacji może zostać zbudowany w dowolnej technologii. Może być to również strona internetowa, aplikacja mobilna, aplikacja na asystenta głosowego np. Alexa itp.
• Użycie technologii headless pozwala programiście frontend w pełni skupić się na dobrym designie i UX bez bycia ograniczonym przez backend.
• Istnieje wiele hostingodawców, którzy skupiają się wyłącznie na utrzymywaniu aplikacji front, co zmniejsza ogólny koszt utrzymywania aplikacji oraz znacznie poprawia ich wydajność.
• Wdrożenie zmian wizualnych nie powoduje ryzyka modyfikacji części aplikacji odpowiedzialnej za logikę. Daje to większą elastyczność programistom, pozwalając na tworzenie unikalnych doświadczeń użytkowników.

Co to jest Framework?

Framework, pełni rolę "szkieletu". Zawiera zestaw narzędzi, funkcji i różnych komponentów, które ułatwiają i przyspieszają pracę nad budową aplikacji. Framework jest standardem, którego należy się trzymać podczas budowy i wdrożenia projektu. Dzięki niemu programista nie musi budować wszystkiego od zera, co znacznie skraca czas realizacji projektów.

Wiele frameworków stworzone jest na licencji open-source. Oznacza to, że są one budowane przez społeczność, i korzystanie z nich jest zupełnie darmowe. Zaletą używania frameworków opartych o open-source jest możliwość konsultacji wszelkich problemów i wątpliwości ze społecznością, która tworzy dane rozwiązanie.

Frameworki stworzone są w różnych językach programowania i podobnie jak one, mają różne przeznaczenia. Niektóre frameworki służą do tworzenia warstwy front, takie jak React.js, Next.js, Vue.js. Inne używa się podczas tworzenia warstwy back. Przykładami są Node.js (na którym oparta jest Medusa.js) lub Django (na którym stworzono platformę Saleor). Poza powyższymi istnieją frameworki, które używane są do tworzenia systemów cms i wielu innych rozwiązań. Korzyścią korzystania z tych frameworków jest optymalizacja czasu realizacji nowego projektu - nie musimy wymyślać koła na nowo, ponieważ wszystkie podstawowe funkcje (takie jak na przykład konta użytkowników na backendzie lub zarządzanie sesją na frontendzie) są już gotowe.

API - co to takiego?

API (Application Programming Interface) to sposób komunikacji między warstwą front i back w aplikacji. Pozwala ono na połączenie i wymianę informacji między warstwami. Wyobraź sobie API jako kelnera w restauracji - to on jest "połączeniem" między Tobą a kucharzem, który przygotuje Twoje danie. Najpierw dostarczy Twoje zamówienie do kuchni, a kiedy zostanie ono przygotowane, dostarczy je do Twojego stolika.

W przypadku sklepów internetowych API służy do przesłania listy produktów z backendu (który wyciąga ją z bazy danych) do frontendu (który wyświetli ją w przystępny dla użytkownika sposób), utworzenia koszyka, złożenia zamówienia, stworzenia produktu przez administratora sklepu internetowego itp.

W przypadku headless API może też służyć do integracji z zewnętrznymi serwisami. Wyobraźmy sobie, że na naszej stronie internetowej mamy formularz kontaktowy. Po wypełnieniu go przez użytkownika korzystamy z Sendgrida do wysyłania mailem treści formularza do administratora. W momencie kiedy użytkownik kliknie przycisk "Wyślij", korzystamy z API Sendgrida, a konkretniej jego elementu odpowiedzialnego za wysłanie maila, podając zawartość formularza (jest to przykład uproszczony, ponieważ komunikacja z zewnętrznymi serwisami powinna odbywać się przez nasz backend ze względu na bezpieczeństwo przechowywania kluczy autentykacyjnych do zewnętrznych serwisów).

API może też służyć jako bramka bezpieczeństwa. W momencie kiedy chcemy, żeby jakieś dane były dostępne tylko dla określonego źródła (na przykład tylko mój frontend może odpytać mój backend o listę produktów, żadna inna aplikacja nie może tego zrobić) wraz z zapytaniem API możemy wysłać klucz API (token), który następnie jest sprawdzany na backendzie. W przypadku kiedy wysłany klucz jest poprawny, zwracamy informacje. Jeżeli klucz ten jest niepoprawny lub zupełnie go nie ma, możemy zwrócić błąd 403 (brak dostępu do uzyskania zasobów).

Kolejną korzyścią API może być przesyłanie różnych informacji w zależności od frontendu który odpytuje backend. Wyobraźmy sobie, że mamy sklep internetowy, który jest stworzony w technologii headless. Posiadamy backend oraz dwa frontendy w postaci strony internetowej i aplikacji mobilnej. W momencie kiedy wykonamy zapytanie o listę produktów z któregoś frontendu, wraz z zapytaniem przychodzi informacja, z którego frontendu zapytanie zostało wykonane. Jeżeli mamy takie zapotrzebowanie biznesowe, na podstawie tej informacji możemy wyświetlić inną listę produktów na aplikacji mobilnej i inną na stronie internetowej. Może być to przydatne podczas wdrażania nowych kanałów sprzedaży.

REST API vs GraphQL

Istnieją dwa najpopularniejsze architektury tworzenia API: REST API oraz GraphQL.

REST API (Representational State Transfer) jest zbiorem zasad, które opierają się na klasycznych metodologiach HTTP: odbieraniu, tworzeniu, edytowaniu i usuwaniu danych (eng. GET, POST, PUT, DELETE). Oznacza to, że API wystawia analogiczne endpointy (punkty końcowe, czyli adresy url), na które możemy wykonać odpowiednie zapytanie w celu wykonania założonej operacji. Jest to klasyczne i najbardziej popularne podejście do tworzenia architektury API.

Alternatywnym podejściem do REST jest GraphQL. W tym rozwiązaniu wystawiony jest tylko jeden endpoint, na który musi zostać wykonane zapytanie w odpowiednim formacie, aby otrzymać lub wysłać informację. W przypadku kiedy chcemy odebrać informacje wykonujemy zapytanie query, natomiast wszelkie operacje związane z zapisaniem danych (tworzenie lub edytowanie) wykonujemy poprzez mutacje. Dodatkową różnicą jest to, że podczas tworzenia zapytania musimy zdefiniować jakie informacje chcemy otrzymać. Na przykład jeżeli chcemy wykonać zapytanie na listę produktów, musimy zdefiniować, że informacje, które chcemy otrzymać to nazwa produktu, jego cena i zdjęcie główne (jeżeli tylko te informacje na liście produktów chcemy wyświetlić). Dzięki temu payload (ładunek danych) jest znacznie mniejszy niż w przypadku RESTa i zawsze otrzymamy dane, które potrzebujemy (w przypadku RESTa jeżeli nie mamy jakiejś informacji w "zwrotce" musimy wykonać kolejne zapytanie na inny endpoint, aby tę informację otrzymać). Są to korzyści, które mogą mieć duże znaczenie kiedy stawiamy na jak najniższe zużycie energii i przesyłu danych na frontendzie (na przykład tworząc aplikację na Apple Watch). GraphQL jest rozwiązaniem stosunkowo nowym, ale szybko gromadzi rzeszę fanów i jest wdrażany w coraz większej ilości projektów.

Które rozwiązanie wybrać? Na to pytanie nie ma oczywistej odpowiedzi. Jeżeli Twój projekt przewiduje potrzebę korzystania z jak najmniejszej ilości danych internetowych (aplikacja będzie działała w krajach, gdzie internet mobilny jest bardzo drogi) lub musi korzystać z jak najmniejszej ilości energii (małe mobilne urządzenia jak na przykład smart watch) wtedy GraphQL może być lepszym rozwiązaniem. W innych przypadkach REST API powinno być wystarczające.

Co to są webhooki?

Webhook to element API, który przeznaczony jest do jednostronnego odbierania danych i wykonywania odpowiedniej akcji. W praktyce oznacza to, że jest to endpoint (punkt końcowy, czyli adres url), który "oczekuje" wywołania przez jakiś zewnętrzny serwis wraz z pewnymi danymi, które następnie ten endpoint przetworzy i wykona odpowiednią akcję. Przykładem webhooka może być oznaczanie zamówienia jako opłacone w sklepie internetowym. Wyobraźmy sobie, że mamy sklep internetowy, który jest zintegrowany z bramką płatności PayU. W momencie kiedy klient klika przycisk "Zapłać", przenosimy go do strony PayU, na której dokonuje płatności. Po zrealizowaniu płatności, system PayU wykonuje zapytanie na nasz webhook z informacją o numerze zamówienia, oraz jego statusem (opłacone, nieopłacone itp.). Po otrzymaniu tych informacji webhook odszuka zamówienie w naszym systemie i zmieni jego status na ten, który przyszedł z PayU.

Jak widać na powyższych przykładach, dzięki architekturze headless jesteśmy w stanie korzystać z API, które niesie za sobą wiele korzyści, które nie byłyby możliwe w przypadku tradycyjnych rozwiązań monolit. Platformy headless oparte na API przejmują rynek sklepów internetowych i stają się rozwiązaniem przyszłości.

Słowniczek pojęć

• API (Application Programming Interface) - interfejs w aplikacji, służący do komunikacji między warstwą front i back.
• Backend - warstwa w aplikacji headless odpowiedzialna za operacje logiczne i komunikację z bazą danych.
• Cloud server - serwer, na którym utrzymuje się aplikację, dzięki czemu jest dostępna dla świata. Serwer ten zarządzany jest przez zewnętrznego providera (hostingodawcę), który odpowiada za jego stabilność, dostępność i bezpieczeństwo.
• Framework - "szkielet" aplikacji, zawierający zestaw narzędzi i funkcji, na podstawie których tworzy się nowe rozwiązania.
• Frontend - warstwa w aplikacji headless odpowiedzialna za wyświetlanie informacji i interakcję użytkownika z aplikacją. W największym stopniu wpływa na doświadczenia użytkownika.
• GraphQL - architektura komunikacji API mająca na celu otrzymywanie z góry określonych danych.
• Headless - architektura aplikacji rozdzielająca warstwę frontend od warstwy backend.
• Język programowania - zestaw zasad, wzorców i założeń, które dostarczone komputerowi instruują go, co ma zrobić.
• Mikroserwisy - architektura aplikacji, która zakłada rozbicie jej na wiele małych, niezależnych komponentów, które porozumiewają się ze sobą poprzez API i wspólnie tworzą całą aplikację.
• Monolit - architektura aplikacji, która ściśle wiąże ze sobą bazę danych, backend oraz frontend.
• Oprogramowanie - zestaw instrukcji, które działają na komputerze.
• Platforma - zestaw hardware (mechaniczne części komputera) i software (oprogramowanie), które są wymagane, aby działała na nich aplikacja.
• PaaS (Platform-as-a-Service) - zestaw usług, które za określoną cykliczną opłatą dostarczają platformę niezbędną do odpalenia aplikacji.
• Private VPS - serwer, na którym utrzymuje się aplikację, dzięki czemu jest dostępna dla świata. Serwer ten zarządzany jest przez nas samych, co oznacza, że aspekty stabilności, dostępności i bezpieczeństwa spadają na nas.
• REST (Representational State Transfer) - zbiór zasad przy tworzeniu API.
• SaaS (Software-as-Service) - usługa, która za określoną cykliczną opłatą daje dostęp do danego oprogramowania.
• Webhook - element API, przeznaczony do jednostronnego odbierania danych i wykonywania odpowiedniej akcji.

Podsumowanie

Jak można zauważyć, słownictwo i pojęcia stosowane w headless commerce potrafią być zawiłe i skomplikowane. Mam nadzieję, że po przeczytaniu tego tekstu całe zagadnienie headless stanie się dla Ciebie znacznie prostsze.