Payload 3.0 i Next.js: rewolucja w budowaniu aplikacji fullstack

Czym jest monolit 2.0 w Payload 3.0 i Next.js

Przez lata standardem był podział, w którym backend był osobno (CMS z własnym API), osobno frontend (aplikacja konsumująca to API przez HTTP). Dwa repozytoria albo dwa serwisy, dwa deploye, dwie rzeczy do utrzymania, a między nimi sieć.

Od wersji 3.0 Payload działa wprost jako część aplikacji Next.js w App Routerze. Instalujesz go jednym poleceniem do folderu app, a on integruje się z routingiem, dzieli ten sam proces i serwer co Twój front. Panel administracyjny Payload to po prostu trasa w Twojej aplikacji Next.js. CMS i frontend żyją w jednym codebase.

Wracamy do zalet monolitu — jeden projekt, jeden deploy, brak sieci między warstwami — ale na nowoczesnych fundamentach: pełny TypeScript, React Server Components, ESM, gotowość pod Turbopack i serverless deploy na Vercelu.

Payload ma dziś ponad 40 tysięcy gwiazdek na GitHubie, działa na produkcji w firmach takich jak Microsoft, ASICS czy Blue Origin, a w czerwcu 2025 roku został przejęty przez Figmę (pozostając open-source na licencji MIT). Wersja 3.x jest aktualną, produkcyjną gałęzią wydań, więc to na niej warto oprzeć decyzje dla realnych projektów.

Payload 3.0 i Next.js: eliminacja warstwy HTTP przez RSC i Server Actions

W klasycznym headless CMS-ie, żeby pobrać dane, Twój front wysyła zapytanie HTTP do API CMS-a, czeka na odpowiedź przez sieć, parsuje JSON. Nawet jeśli oba serwery stoją obok siebie, to zawsze jest round-trip przez sieć — z narzutem czasowym i kolejnym miejscem, gdzie coś może pójść nie tak.

Payload 3.0 daje lokalne API, które rozmawia z bazą danych bezpośrednio, w tym samym procesie. A ponieważ React Server Components (RSC) wykonują się na serwerze, możesz wywołać lokalne API Payload wprost w komponencie — bez żadnego fetch(), bez endpointu, bez sieci pomiędzy:

// app/blog/page.tsx — React Server Component
import { getPayload } from 'payload'
import config from '@payload-config'
 
export default async function BlogPage() {
  const payload = await getPayload({ config })
 
  // bezpośrednie zapytanie do bazy — żadnego HTTP
  const { docs: posts } = await payload.find({
    collection: 'posts',
    sort: '-publishedAt',
    limit: 100,
  })
 
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>
          <a href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
            <p>{post.excerpt}</p>
          </a>
        </li>
      ))}
    </ul>
  )
}

Co tu zyskujesz:

• Wydajność — odpadł narzut sieciowy i serializacja/deserializacja JSON przez HTTP. Zapytanie idzie wprost do bazy.
• Bezpieczeństwo — kod wykonuje się wyłącznie na serwerze, więc żadne tokeny, klucze ani logika dostępu nie trafiają do przeglądarki. Chroni to m.in. przed XSS.
• Type-safety — payload.find() jest w pełni otypowane na podstawie Twojego schematu, więc edytor podpowiada pola, a literówkę wyłapiesz na etapie kompilacji.

A gdy potrzebujesz zapisu danych — używasz Server Actions. To funkcje wykonywane na serwerze, które możesz wywołać prosto z komponentu, znów bez budowania osobnego endpointu API:

// app/actions.ts
'use server'
 
import { getPayload } from 'payload'
import config from '@payload-config'
 
export async function createPost(formData: FormData) {
  const payload = await getPayload({ config })
 
  await payload.create({
    collection: 'posts',
    data: {
      title: formData.get('title') as string,
    },
  })
}

Payload 3.0 i Next.js dla SaaS, e-commerce i portali z logowaniem

Do tej całej układanki Payload dorzuca jeszcze jeden mocny element: świetną, wbudowaną autentykację.

Payload ma authentication out of the box — z bezpiecznymi ciasteczkami HTTP-only, ochroną CSRF i bardzo dokładną kontrolą dostępu na poziomie kolekcji, dokumentu oraz pojedynczego pola. Logikę "kto może widzieć i edytować co" definiujesz raz, w schemacie, w TypeScript — i obowiązuje ona wszędzie, także przy zapytaniach z RSC.

Dla pewnych typów projektów to dokładnie ten brakujący klocek:

• Zaawansowane SaaS-y — masz aplikację z użytkownikami, rolami i danymi per-konto, a Payload daje Ci model danych, panel admina i auth w jednym, wewnątrz tej samej aplikacji Next.js.
• E-commerce — produkty, zamówienia, konta klientów i panel zarządzania bez stawiania osobnego backendu; do tego RSC dla szybkich, dobrze indeksowanych stron produktowych.
• Portale z logowaniem — bazy wiedzy, panele klienta, treści za paywallem; kontrola dostępu na poziomie pola pozwala precyzyjnie sterować, kto co widzi.

W każdym z tych przypadków alternatywą jest sklejanie osobnego CMS-a, osobnej autentykacji i osobnego API. Payload 3.0 z Next.js daje to wszystko w jednym procesie, z bezpieczeństwem typów end-to-end.

Payload 3.0, Next.js i ekosystem AI

W kwietniu 2026 Payload dorzucił wbudowany zestaw ewaluacji, który mierzy, jak dobrze narzędzia AI (Cursor, Claude Code, Copilot) rozumieją i generują kod Payload. Jeśli wspierasz się AI przy pisaniu konfiguracji CMS-a, Payload jest dziś jednym z narzędzi, które najczęściej daje działający kod za pierwszym razem. Dla zespołów pracujących w workflow ze wsparciem narzędzi AI, jest to realna oszczędność czasu.