W większości stron internetowych rola CMS-a jest prosta. Marketing loguje się do panelu, edytuje ofertę, publikuje artykuł, zmienia zdjęcie albo przygotowuje landing page. Front-end pobiera treści z CMS-a i wyświetla je użytkownikowi.
W takim projekcie oddzielny headless CMS, na przykład Sanity, często sprawdza się świetnie. Problem zaczyna się wtedy, gdy rozwijany produkt przestaje być zwykłą stroną.
Do serwisu dochodzi portal klienta. Użytkownicy zaczynają mieć własne konta i role. Firma potrzebuje katalogów, dokumentów, plików, indywidualnych danych i panelu dla pracowników. Część treści ma być dostępna tylko dla określonych klientów. Pojawiają się procesy publikacji, zatwierdzania zmian, relacje między organizacjami, użytkownikami i zasobami.
Wtedy granica między CMS-em a aplikacją zaczyna się zacierać.
Payload jest ciekawy właśnie w takich projektach. Jego twórcy opisują go dziś szerzej niż headless CMS: jako open-source'owy backend i full-stack framework dla Next.js. Z jednej konfiguracji dostajesz panel administracyjny, modele danych, migracje bazy, REST API, GraphQL, autoryzację, kontrolę dostępu i obsługę plików.
Dla Twojej firmy to mniej pracy, którą przy klasycznej architekturze trzeba by wykonać od zera albo złożyć z kilku osobnych usług.
Czym Payload różni się od klasycznego headless CMS?
W typowym modelu headless CMS jest zewnętrznym źródłem treści. Front-end działa w jednym środowisku, CMS w drugim, a komunikacja odbywa się przez API.
To dobre rozwiązanie, jeśli głównym zadaniem systemu jest zarządzanie contentem. Artykuły, strony ofertowe, case studies, autorzy, kategorie czy materiały marketingowe idealnie pasują do takiego modelu.
Payload idzie dalej.
Jest rozwiązaniem code-first. Struktura danych, pola, relacje, uprawnienia i część zachowania systemu są definiowane w TypeScript. Na tej podstawie Payload buduje odpowiednią warstwę administracyjną i API.
Jeżeli aplikacja ma kolekcje organizations, users, products, documents czy orders, opisujesz je bezpośrednio w projekcie. Relacje między nimi również są częścią konfiguracji.
Zmiana modelu danych staje się więc normalną zmianą w kodzie. Może przejść przez Git, code review, testy i standardowy pipeline wdrożeniowy.
Zespół techniczny zyskuje w ten sposób dużo większą kontrolę. Dla firmy to mniej sytuacji, w których rozwój produktu blokuje to, czego nie przewidział dostawca zewnętrznego CMS-a.
Kiedy CMS zaczyna być częścią produktu?
Najłatwiej pokazać to na przykładzie platformy B2B.
Na początku firma ma stronę internetową. Marketing zarządza ofertą, artykułami i case studies. CMS przechowuje więc przede wszystkim treści publiczne.
Później powstaje portal klienta.
Po zalogowaniu użytkownik widzi dokumenty przypisane do swojej firmy, indywidualne materiały, ofertę, informacje o realizowanych usługach i dane dostępne wyłącznie dla jego organizacji. Administrator klienta ma większe uprawnienia niż zwykły pracownik. Zespół po stronie dostawcy potrzebuje jeszcze innego dostępu.
W takim systemie „content” przestaje oznaczać wyłącznie artykuł.
Dokument, produkt, użytkownik, organizacja, instrukcja, plik czy konfiguracja mogą być częścią jednego modelu danych. Panel administracyjny przestaje być zapleczem bloga i staje się miejscem, w którym zarządzasz częścią produktu.
To właśnie jest moment, w którym Payload zaczyna mieć większy sens niż klasyczny CMS działający obok aplikacji.
Dlaczego Payload dobrze pasuje do Next.js?
Dzisiejszy Payload może zostać zainstalowany bezpośrednio w aplikacji Next.js. Panel administracyjny i warstwa HTTP Payload znajdują się w tym samym projekcie, a reszta aplikacji może działać obok nich.
Ma to duże znaczenie architektoniczne.
W klasycznym rozwiązaniu front-end Next.js wykonuje zapytanie HTTP do zewnętrznego CMS-a. CMS odpowiada przez API. Trzeba utrzymywać konfigurację po obu stronach, obsługiwać autoryzację, synchronizację typów, błędy sieciowe i kolejne zależności.
Payload daje również Local API. Kod wykonywany po stronie serwera może korzystać bezpośrednio z operacji na danych bez dodatkowego połączenia HTTP. Ma to zastosowanie między innymi w React Server Components, route handlers, hookach czy skryptach serwerowych.
REST i GraphQL nadal mają swoje miejsce. Payload generuje oba interfejsy, więc używasz ich tam, gdzie system faktycznie potrzebuje komunikacji przez API.
Różnica polega na tym, że wewnątrz jednej aplikacji nie trzeba tworzyć sztucznej warstwy sieciowej tylko po to, żeby jeden fragment własnego systemu porozmawiał z drugim.
Mniej połączeń oznacza prostszą architekturę, mniej potencjalnych punktów awarii i łatwiejsze utrzymanie.
Payload jako panel administracyjny dedykowanej aplikacji
Jedną z droższych części własnego systemu często okazuje się zaplecze administracyjne.
Klient końcowy potrzebuje dobrego interfejsu produktu, ale ktoś po stronie firmy musi jeszcze zarządzać tym, co znajduje się pod spodem. Trzeba przeglądać użytkowników, edytować dane, dodawać dokumenty, zarządzać katalogami, zmieniać statusy i kontrolować dostęp.
Jeżeli wszystko powstaje od zera, trzeba zaprojektować panel, zbudować formularze i listy, wdrożyć uprawnienia, przygotować walidację, obsłużyć błędy i rozwijać całość razem z aplikacją.
Payload automatycznie generuje panel zgodnie ze zdefiniowanym modelem danych. Panel można przy tym rozszerzać własnymi komponentami React i dopasowywać do konkretnego procesu.
Każdy panel i tak wymaga pewnej pracy. W bardziej specjalistycznych systemach nadal projektujesz własne widoki i workflow.
Zmienia się jednak punkt startowy. Zespół nie zaczyna od pustej kartki.
Dla MVP, portalu B2B czy wewnętrznej aplikacji biznesowej może to wyraźnie skrócić czas developmentu. Budżet przesuwasz z powtarzalnego zaplecza na funkcje, które faktycznie odróżniają produkt.
Role, organizacje i dostęp do danych
W rozbudowanym systemie szybko przestaje wystarczać podział na administratora i zwykłego użytkownika.
Może istnieć administrator platformy, administrator klienta, pracownik jego firmy, handlowiec, support i operator systemu. Każda osoba powinna widzieć inny zakres danych i mieć możliwość wykonywania innych operacji.
Payload posiada mechanizm Access Control działający na poziomie kolekcji, operacji i pól. Reguły można opierać między innymi na użytkowniku, jego roli, właściwościach dokumentu albo organizacji, do której należy.
Można więc przygotować regułę, według której pracownik firmy A widzi zasoby swojej organizacji, ale nie może odczytać danych firmy B. Administrator platformy może mieć szerszy dostęp, a pracownik działu marketingu widzieć jedynie obszary potrzebne do jego pracy.
Payload ma też oficjalny mechanizm wspierający architekturę multi-tenant, co może być przydatne przy platformach obsługujących wiele organizacji w jednej aplikacji.
Nie zwalnia to zespołu z projektowania bezpieczeństwa. Uprawnienia nadal trzeba świadomie zaplanować, przetestować i monitorować.
Ważna pułapka Local API: dostęp trzeba projektować świadomie
Bliska integracja Payload z Next.js daje dużą wygodę, ale ma konsekwencję, którą zespół developerski musi znać.
Operacje wykonywane przez Payload Local API domyślnie mogą pomijać Access Control. Jest to przydatne przy zadaniach wykonywanych wewnętrznie przez zaufany kod serwerowy, ale byłoby niebezpieczne, gdyby programista założył, że prawa zalogowanego użytkownika zostaną sprawdzone automatycznie.
Jeżeli Local API wykonuje operację w imieniu konkretnego użytkownika, należy przekazać jego kontekst i wymusić respektowanie reguł dostępu.
To dobry przykład szerszej zasady. Payload daje dużą kontrolę, a wraz z nią rośnie odpowiedzialność zespołu.
Self-hosting czy własny kod same w sobie nie czynią systemu bezpieczniejszym od rozwiązania SaaS. Przewagą jest możliwość samodzielnego zaprojektowania bezpieczeństwa pod wymagania systemu.
Publikacja, wersje i własne procesy akceptacji
Payload może obsługiwać wersjonowanie dokumentów, drafty, podgląd zmian i planowanie publikacji. W projektach contentowych daje to podstawę do normalnej pracy redakcyjnej.
Jeżeli Twoja organizacja potrzebuje bardziej rozbudowanego procesu (przygotowanie treści, weryfikacja prawna, akceptacja managera, publikacja), taki workflow można zbudować na mechanizmach Payload.
Trzeba jednak rozróżnić dwie rzeczy.
Drafty, wersje i publikacja są gotowymi możliwościami systemu. Wieloetapowy proces akceptacji dopasowany do konkretnej organizacji wymaga zaprojektowania odpowiednich reguł, statusów i zachowania aplikacji.
Wciąż może to być prostsze niż budowanie całego zaplecza od początku. Taki proces nie pojawi się jednak sam po instalacji CMS-a.
Czy Payload zastępuje backend?
Nie. Takie stwierdzenie byłoby zbyt daleko idące.
Payload może przejąć sporą część typowego zaplecza aplikacji. Dostarcza fundament pod zarządzanie danymi, API, auth, access control, panel administracyjny, upload plików, migracje i mechanizmy wykonywania własnej logiki podczas cyklu życia danych.
Dla wielu portali klienta, systemów contentowych i MVP jest to duża część pracy, która w przeciwnym razie musiałaby zostać napisana osobno.
Całej logiki produktu nie warto jednak umieszczać w CMS-ie.
Jeżeli aplikacja realizuje skomplikowane obliczenia, rozbudowane procesy finansowe, intensywne przetwarzanie danych albo wymaga specjalistycznej architektury backendowej, nadal potrzebuje odpowiedniej warstwy aplikacyjnej.
W WebProfessor właśnie w taki sposób patrzymy na Payload. Wykorzystujemy go tam, gdzie redukuje powtarzalną pracę i upraszcza system. Nie próbujemy za jego pomocą na siłę rozwiązać problemów, do których lepiej nadaje się osobny backend.
Payload vs Sanity: oba są headless, ale rozwiązują trochę inny problem
Porównanie Payload z Sanity łatwo nadmiernie uprościć.
Sanity często trafia do szuflady z napisem „zewnętrzny CMS, którego nie da się połączyć z aplikacją”, co mija się z prawdą. Sanity Studio jest aplikacją React i może być hostowane samodzielnie lub osadzone w innym projekcie. Dane są jednak przechowywane w hostowanym przez Sanity Content Lake.
W Payload firma może utrzymywać sam system i bazę danych w swojej infrastrukturze. Payload jest też mocniej zintegrowany z samą architekturą Next.js.
Dlatego w WebProfessor patrzymy na te rozwiązania pod kątem zastosowania.
Jeżeli budujemy stronę marketingową, portal contentowy albo serwis, w którym redakcja treści jest główną rolą CMS-a, Sanity często będzie świetnym wyborem. Daje wygodne środowisko do pracy z contentem i nie ma sensu komplikować projektu bez potrzeby.
Payload zaczyna wyglądać atrakcyjniej wtedy, gdy CMS ma zarządzać fragmentem produktu. Użytkownicy, organizacje, role, dokumenty i dane aplikacyjne zaczynają tworzyć wspólny model, a panel administracyjny ma być częścią wewnętrznego procesu firmy.
Pytanie „który CMS jest lepszy?” niewiele tu wnosi. Ważniejsze jest, czy potrzebujesz przede wszystkim systemu do zarządzania contentem, czy warstwy administracyjnej rozwijanej razem z aplikacją.
Payload ma największy sens wtedy, gdy CMS wychodzi poza treści i zaczyna zarządzać użytkownikami, rolami i danymi produktu. Przy zwykłej stronie contentowej prostszy headless CMS zwykle wystarczy.
Całkowity koszt posiadania (TCO): gdzie model Payload może zacząć się opłacać
Koszt CMS-a jest jednym z obszarów, w których najłatwiej wyciągnąć zbyt szybkie wnioski.
Payload jest open source na licencji MIT i w wariancie self-hosted nie wymaga opłaty licencyjnej za sam CMS. Koszt jednak zostaje. Nadal potrzebujesz infrastruktury, bazy danych, trwałego storage plików, kopii zapasowych, monitoringu, często dostawcy poczty i ludzi odpowiedzialnych za aktualizacje systemu.
Zewnętrzny CMS SaaS ma inną strukturę kosztów. Płacisz za usługę, a cena może zależeć od planu, liczby użytkowników, danych, wykorzystania API, dodatkowych środowisk i bardziej zaawansowanych funkcji.
Dobrym punktem odniesienia jest Sanity, które dla wielu stron marketingowych i mniejszych zespołów ma korzystny model startowy. Możesz zacząć od planu bezpłatnego i dostać gotową infrastrukturę bez konieczności samodzielnego utrzymywania CMS-a, bazy danych czy środowiska produkcyjnego. Dlatego w typowych projektach contentowych często jest prostszym i bardziej ekonomicznym wyborem na start.
Ekonomia zaczyna wyglądać inaczej wraz ze wzrostem projektu. Większy zespół redakcyjny oznacza więcej użytkowników CMS-a, a duża ilość treści, danych i operacji może zwiększać wykorzystanie płatnych zasobów. W modelu SaaS część kosztów rośnie więc razem ze skalą wykorzystania platformy.
Self-hosted Payload działa inaczej. Nie płacisz za każdego kolejnego redaktora czy użytkownika panelu według cennika CMS-a, a większa ilość danych nie przenosi Cię automatycznie na wyższy plan SaaS. Płacisz natomiast za własną infrastrukturę oraz pracę potrzebną do jej utrzymania, aktualizacji, monitoringu i zabezpieczenia.
Dlatego nie traktujemy Payload jako sposobu na „uniknięcie abonamentu za CMS”. Przy mniejszym serwisie Sanity może być tańsze i dużo prostsze operacyjnie. Payload zaczyna zyskiwać ekonomiczną przewagę przy większych zespołach, dużej ilości danych oraz aplikacjach, w których CMS i tak staje się częścią własnego zaplecza technologicznego. W WebProfessor dobieramy ten model do skali projektu, sposobu pracy zespołu i przewidywanego TCO w kolejnych latach.
Jeżeli firma ma prostą stronę i mały zespół, gotowy SaaS może wyjść wyraźnie taniej niż utrzymywanie własnej infrastruktury.
Sytuacja zmienia się przy większym produkcie. Jeżeli CMS zaczyna obsługiwać dane aplikacyjne, wielu użytkowników, niestandardowe role i coraz więcej integracji, trzeba policzyć koszt całego systemu. Sam abonament to tylko jego fragment.
W TCO wchodzą wtedy opłaty za SaaS, development integracji, utrzymanie synchronizacji danych, dodatkowe usługi, koszt zmian oraz czas zespołu poświęcony na obchodzenie ograniczeń platformy.
Payload może w takim scenariuszu zmienić strukturę kosztów. Większa część wydatków przenosi się z abonamentów i integracji na własną infrastrukturę oraz rozwój kodu, który pozostaje pod kontrolą firmy.
Czy to będzie tańsze? Trzeba policzyć konkretny projekt.
Mniej zewnętrznych systemów to mniejszy koszt integracji
Cena licencji to tylko część TCO.
Wyobraź sobie aplikację, w której osobno działa CMS, system użytkowników, storage plików, własny backend i panel administracyjny. Każde połączenie między nimi wymaga API, konfiguracji, obsługi błędów i monitoringu.
Gdy zmienia się struktura danych w jednym systemie, może być potrzebna zmiana w kilku innych. Modyfikacja zewnętrznego API wymusza dostosowanie integracji. A przy problemie z synchronizacją zespół musi znaleźć, w której warstwie dane zaczęły się rozjeżdżać.
Payload pozwala część tych elementów zbliżyć do siebie. Integracji całkiem się nie pozbędziesz, bo współczesne aplikacje zawsze komunikują się z innymi usługami. Wyeliminujesz za to połączenia, które istnieją wyłącznie dlatego, że CMS został postawiony jako osobny system.
W kilkuletnim cyklu życia produktu waży to w kosztach utrzymania więcej niż kilkaset złotych różnicy w miesięcznym abonamencie.
Kontrola nad danymi i infrastrukturą
Przy prostej stronie marketingowej miejsce działania CMS-a rzadko jest głównym problemem biznesowym.
Sytuacja zmienia się w portalu klienta, aplikacji B2B albo wewnętrznym narzędziu.
System może przechowywać profile użytkowników, dokumenty klientów, konfiguracje kont, materiały dostępne dla określonych organizacji i inne dane związane z działaniem produktu.
Payload pozwala wdrożyć aplikację tam, gdzie może działać odpowiednie środowisko Next.js, a sposób hostowania i bazę danych wybierasz samodzielnie. Obecnie Payload wspiera między innymi PostgreSQL, MongoDB i SQLite przez odpowiednie adaptery.
Większa kontrola przydaje się szczególnie wtedy, gdy firma ma własne wymagania infrastrukturalne lub chce ograniczyć zależność od jednej platformy SaaS.
Bezpieczeństwo i koszt nadal zależą od tego, jak to zaplanujesz. Różnica polega na tym, że te decyzje zapadają po Twojej stronie.
Payload a MVP i time-to-market
Przy MVP szczególnie łatwo przepalić budżet na funkcje, które są konieczne technicznie, ale nie weryfikują żadnej hipotezy biznesowej.
Użytkownicy muszą się logować. Administrator musi mieć panel. Ktoś musi zarządzać danymi i plikami. Potrzebne są role i API.
Żaden z tych elementów nie musi być jednak tym, za co klient ostatecznie zapłaci.
Jeżeli Payload dostarcza znaczną część tego zaplecza, zespół może szybciej przejść do budowania właściwego produktu. Programiści poświęcają mniej czasu na tworzenie od podstaw panelu administracyjnego, systemu uprawnień czy podstawowej warstwy API, a więcej na funkcje, które wyróżniają produkt i tworzą wartość dla jego użytkowników.
W przypadku MVP przekłada się to na krótszy time-to-market i lepsze wykorzystanie budżetu developerskiego.
Kiedy Payload będzie przerostem formy nad treścią?
Payload ma dużo możliwości, ale nie powinien być domyślnym CMS-em dla każdego projektu.
W WebProfessor do prostych stron firmowych i projektów mocno opartych na content marketingu nadal częściej wybierzemy Sanity. Przy dobrze zaprojektowanej stronie w Astro połączenie lekkiego front-endu z wygodnym headless CMS-em jest prostsze i dobrze wspiera performance, SEO oraz pracę marketingu.
Payload zaczyna być ciekawszy, gdy wchodzimy w bardziej customowe rozwiązanie na Next.js.
Przed decyzją warto odpowiedzieć sobie na kilka pytań:
- Czy CMS będzie zarządzał wyłącznie publicznymi treściami, czy również danymi produktu?
- Czy użytkownicy i organizacje potrzebują różnych poziomów dostępu?
- Czy aplikacja wymaga własnego panelu administracyjnego?
- Czy część danych powinna być przechowywana i obsługiwana w naszej infrastrukturze?
- Czy obecny CMS wymaga coraz większej liczby integracji i obejść?
- Czy produkt będzie stale rozwijany przez zespół pracujący w Next.js i TypeScript?
- Czy po policzeniu 3-5 letniego TCO własne rozwiązanie zaczyna być ekonomicznie uzasadnione?
Jeżeli większość odpowiedzi brzmi „nie”, prostszy headless CMS prawdopodobnie będzie lepszym wyborem.
Jeżeli większość brzmi „tak”, sprawdź Payload, zanim zaczniesz budować od zera kolejny panel, system użytkowników i warstwę API.
Kiedy Payload naprawdę daje przewagę?
Największa przewaga Payload pojawia się wtedy, gdy CMS przestaje być miejscem do wpisywania tekstu i staje się elementem architektury produktu.
W portalu klienta może zarządzać użytkownikami, organizacjami, materiałami i dokumentami. W platformie B2B może obsługiwać katalog i dostęp do danych dla poszczególnych klientów. W MVP może dostarczyć panel administracyjny i znaczną część zaplecza, zanim zespół zacznie budować najbardziej indywidualne funkcje produktu.
W takim scenariuszu firma zyskuje większą kontrolę nad kodem, danymi i roadmapą. Zespół redukuje liczbę niepotrzebnych integracji, a budżet developerski trafia w te elementy, które faktycznie budują przewagę biznesową.
Nie jest to jednak argument za zastąpieniem każdego CMS-a Payloadem.
Technologia ma upraszczać projekt. Jeżeli Payload upraszcza architekturę, skraca development i poprawia TCO, jest dobrym kandydatem. Jeżeli dodaje złożoność do zwykłej strony contentowej, wybierz prostsze rozwiązanie.
Tak to wygląda u nas w WebProfessor. Sanity jest naszym naturalnym wyborem dla wielu projektów contentowych. Payload wykorzystujemy wtedy, gdy CMS musi wejść głębiej w produkt, a Next.js przestaje być wyłącznie front-endem strony i staje się podstawą dedykowanej aplikacji.
