Jamstack: co to jest i kiedy ma sens dla strony

Nazwa Jamstack pojawiła się w 2015 roku. Termin ukuł Mathias Biilmann, współzałożyciel Netlify. Początkowo tłumaczono go jako skrót od JavaScript, API oraz Markup, czyli trzech elementów opisujących sposób budowania nowoczesnych stron internetowych. Z czasem znaczenie tego określenia stało się jednak szersze i obecnie nie warto traktować go jak ścisłej listy technologii, które muszą znaleźć się w każdym projekcie.

To ważne, bo Jamstack nie jest pojedynczym frameworkiem, systemem CMS ani usługą hostingową. Jest sposobem organizacji strony i jej zaplecza. W takim modelu część tego, co użytkownik zobaczy w przeglądarce, może zostać przygotowana jeszcze przed jego wejściem na stronę. Elementy, które rzeczywiście wymagają działania po stronie serwera, można natomiast obsłużyć osobno przez API albo funkcje serverless.

Dlatego pytanie „Jamstack co to?” nie ma dziś odpowiedzi w rodzaju „to Next.js” albo „to strona statyczna”. Next.js może być jednym z narzędzi używanych w takim projekcie, podobnie jak Astro. Treść może pochodzić na przykład z Sanity albo Strapi, a wdrożenie może działać na Vercel. Sam dobór produktów nie przesądza jednak jeszcze o architekturze.

W praktyce istotny jest podział odpowiedzialności. Treść strony może być przygotowana wcześniej, interfejs działa po stronie użytkownika, a wybrane funkcje komunikują się z zewnętrznymi usługami lub własnym zapleczem. To właśnie ten sposób myślenia o stronie jest bardziej użyteczny niż próba dopasowania projektu do dawnego rozwinięcia skrótu.

Jeżeli interesuje Cię wdrożenie takiej architektury w konkretnym projekcie, szerzej opisuję też strony Jamstack.

Jednym z podstawowych pojęć związanych z Jamstack jest SSG, czyli Static Site Generation. Po polsku można mówić o generowaniu statycznym. W tym modelu pliki HTML i pozostałe zasoby strony są przygotowywane wcześniej, zamiast powstawać od zera na serwerze przy każdym wejściu użytkownika.

Nie oznacza to, że strona musi być pozbawiona interakcji. Gotowy HTML może stanowić podstawę widoku, a JavaScript może odpowiadać za zachowanie interfejsu w przeglądarce. Z kolei dane i funkcje wymagające komunikacji z zapleczem mogą być dostępne przez API.

Taki podział można rozumieć jako trzy warstwy. Pierwszą jest treść i struktura strony przygotowana przed wejściem użytkownika. Drugą jest kod uruchamiany w przeglądarce. Trzecią są usługi dynamiczne, które włączają się wtedy, gdy rzeczywiście są potrzebne.

Przykładem może być formularz. Sama podstrona kontaktowa nie musi być generowana na serwerze przy każdym wyświetleniu. Może istnieć jako wcześniej przygotowany dokument HTML. Dopiero wysłanie formularza wymaga operacji po stronie serwera. W architekturze Jamstack taką operację można obsłużyć przez dynamiczne API albo funkcję serverless.

Podobnie można podejść do płatności. Widok oferty, opis produktu czy inne elementy informacyjne mogą być przygotowane wcześniej, natomiast operacja wymagająca działania serwera zostaje oddzielona od warstwy strony. Dzięki temu nie trzeba utrzymywać całej witryny jako jednej aplikacji, w której każde wejście użytkownika uruchamia ten sam proces po stronie serwera.

Jeżeli chcesz dokładniej zrozumieć sam mechanizm budowania gotowych podstron, osobno opisuję static site generation.

W Jamstack istotną rolę odgrywa sposób dostarczania gotowych zasobów. Wstępnie zbudowane pliki statyczne mogą być rozprowadzane przez CDN, czyli Content Delivery Network. Jest to sieć, która pozwala serwować zasoby z lokalizacji znajdującej się bliżej użytkownika końcowego.

Z perspektywy właściciela strony oznacza to przede wszystkim, że wyświetlenie zwykłej podstrony nie musi za każdym razem wymagać pełnego przetwarzania jej na serwerze aplikacyjnym. Jeśli gotowy dokument już istnieje, może zostać po prostu dostarczony użytkownikowi.

To jedna z najważniejszych różnic między takim podejściem a modelem, w którym treść jest składana dynamicznie podczas każdego żądania. Nie oznacza jednak, że jeden model jest z definicji dobry, a drugi zły. Wybór zależy od tego, jakie dane znajdują się na stronie, jak często się zmieniają i co użytkownik może na niej robić.

W projekcie informacyjnym duża część widoków może istnieć w gotowej postaci. Jeśli masz stronę firmy, opis usług, artykuły, dokumentację albo portfolio, zawartość wielu podstron nie musi zmieniać się w momencie każdego wejścia. Można więc przygotować ją wcześniej i aktualizować wtedy, gdy zmieniasz treść.

Inaczej wygląda aplikacja, w której każda osoba po zalogowaniu widzi własne, stale zmieniające się dane. Wtedy większa część interfejsu może wymagać pobierania informacji na bieżąco. To nie wyklucza korzystania z części pomysłów znanych z Jamstack, ale sprawia, że samo generowanie statyczne przestaje być odpowiedzią na większość potrzeb projektu.

Dlatego przy planowaniu strony nie zaczynam od pytania, czy da się nazwać ją Jamstack. Najpierw patrzę na rodzaje treści, sposób ich aktualizacji i funkcje wymagające pracy serwera. Dopiero z tego wynika sensowna architektura.

Jamstack dobrze pasuje do stron, w których znaczną część zawartości można przygotować przed wejściem użytkownika. W obecnej wersji tego podejścia nie musi to być strona całkowicie statyczna. Ważniejsze jest to, że nie każda podstrona wymaga dynamicznego generowania przy każdym otwarciu.

Typowe zastosowania to strony marketingowe, blogi, dokumentacja, strony docelowe, portfolio i serwisy oparte głównie na treści. W takich projektach użytkownicy często oglądają te same informacje, a zmiany następują wtedy, gdy właściciel albo redakcja aktualizuje zawartość.

Takie podejście może mieć sens również wtedy, gdy strona zawiera pojedyncze elementy dynamiczne. Formularz, płatność czy inna operacja wykonywana po stronie serwera nie sprawia automatycznie, że cała witryna musi być generowana dynamicznie. Te funkcje można wydzielić i obsłużyć przez API lub funkcje serverless.

Dobrym przykładem architektury opartej na generowaniu wielu stron z jednej bazy jest mój projekt cojestpolskie.pl. Zbudowałem go w Astro. Serwis zawiera ponad 900 marek i ponad 1700 podstron generowanych z jednej bazy danych. Ten przykład pokazuje praktyczną stronę podejścia, w którym duża liczba widoków może powstawać na podstawie uporządkowanych danych.

W innych projektach używam również Next.js. Dobór między nim a Astro nie wynika z samej nazwy Jamstack. Patrzę na to, czy projekt jest głównie serwisem treściowym, czy potrzebuje bardziej rozbudowanych funkcji aplikacyjnych, uwierzytelniania, panelu użytkownika albo pracy z danymi zmieniającymi się w czasie.

Ten model ma więc sens, gdy większość strony można zbudować z przewidywalnej treści, a dynamika jest dodatkiem albo dotyczy tylko wybranych fragmentów. Jeśli natomiast serwis opiera się niemal w całości na informacjach tworzonych na bieżąco dla konkretnego użytkownika, punkt ciężkości przesuwa się gdzie indziej.

Sam fakt, że Jamstack pozwala wcześniej przygotować część strony, nie oznacza, że powinien być stosowany wszędzie. Są projekty, w których najważniejsza jest właśnie ciągła praca z aktualnymi danymi, a nie dostarczanie gotowej treści.

Przykładami są czat działający w czasie rzeczywistym, strumień aktywności w serwisie społecznościowym i panele z dynamicznymi danymi przypisanymi do konkretnego użytkownika. W takich przypadkach aplikacja musi regularnie pobierać albo przetwarzać informacje zależne od bieżącego stanu systemu.

To zmienia rolę generowania statycznego. Nadal można wykorzystać je dla wybranych publicznych podstron, dokumentacji czy części marketingowej, ale główny obszar aplikacji potrzebuje innego sposobu obsługi danych. Nie ma wtedy sensu naginać całego projektu do jednej etykiety architektonicznej.

Podobny problem pojawia się wtedy, gdy zawartość zmienia się bardzo często i każda osoba powinna natychmiast zobaczyć nowy stan. Jeżeli aktualność danych jest ważniejsza niż możliwość przygotowania strony wcześniej, trzeba zaplanować odpowiednie pobieranie informacji i pracę zaplecza.

Dlatego przy wyborze rozwiązania rozdzielam dwie rzeczy: publiczne treści, które można wygenerować wcześniej, oraz funkcje zależne od użytkownika lub aktualnego stanu danych. Czasem oba obszary mieszczą się w jednym projekcie. Nie oznacza to jednak, że każdy z nich musi działać w identyczny sposób.

Jamstack jest więc użytecznym modelem wtedy, gdy wynika z charakteru strony. Traktowanie go jako obowiązkowego punktu wyjścia odwraca kolejność decyzji. Najpierw powinieneś wiedzieć, co strona ma robić, skąd pobiera dane i które elementy muszą być dynamiczne.

Strona zbudowana w tym modelu nie musi oznaczać ręcznej edycji plików przez programistę. Treścią nadal można zarządzać w systemie CMS. Różnica polega na tym, że panel do edycji i frontend strony mogą być osobnymi elementami.

W takim układzie CMS przechowuje treści, a frontend pobiera je przez API i wykorzystuje do zbudowania odpowiednich podstron. W moim stosie mogą to być między innymi Sanity albo Strapi. Sam frontend może powstać w Next.js albo Astro, zależnie od wymagań projektu.

Takie rozwiązanie określa się jako headless CMS. System zarządzania treścią zajmuje się wtedy treścią i udostępnia ją innym częściom projektu, ale nie musi samodzielnie odpowiadać za wygląd strony, którą widzi użytkownik. Więcej o tej różnicy wyjaśniam we wpisie o headless CMS.

Oddzielenie CMS od frontendu ma również znaczenie przy myśleniu o istniejącej stronie. Migracja nie zawsze musi oznaczać usunięcie dotychczasowego zaplecza do edycji treści. Przy stronie na WordPressie można zostawić go jako backend i zbudować osobną warstwę frontendową, która pobiera treści przez API.

Przy samej migracji trzeba jednak patrzeć szerzej niż na zmianę technologii. Jeżeli zmieniają się adresy podstron, należy zaplanować przekierowania 301 ze starych adresów. Nie należy przy tym obiecywać zachowania konkretnych pozycji w Google tylko dlatego, że wdrożenie zostało technicznie przygotowane poprawnie.

W nowym projekcie wybór CMS również powinien wynikać ze sposobu pracy z treścią. Jeśli strona ma wiele powtarzalnych typów danych i podstron, uporządkowany model treści może dobrze współpracować z generowaniem stron. Jeśli zarządzanie zawartością jest prostsze, dokładanie rozbudowanej architektury tylko po to, żeby projekt mieścił się w definicji Jamstack, nie daje samo w sobie wartości.

Termin Jamstack jest dziś mniej precyzyjny niż na początku jego historii, ale sama idea pozostaje praktyczna: nie wykonywać dynamicznie tego, co można przygotować wcześniej, i oddzielać funkcje wymagające pracy serwera od treści, która jej nie potrzebuje. Przy wyborze technologii właśnie ten podział jest dla mnie ważniejszy niż nazwa architektury.