Dlaczego prawie każdy projekt w Astro paruję z Sanity

Kiedy szkoła albo fundacja dzwoni i prosi o „coś takiego jak WordPress, tylko nie WordPress“, co najczęściej mają na myśli: wygodny panel dla redakcji, szybką stronę publiczną i koniec z chaosem wtyczek. Kombinacja, do której wciąż dochodzę, to Astro na froncie + Sanity na backu.

To uczciwe uzasadnienie dla Sanity — co robi dobrze, gdzie kąsa i kiedy mimo wszystko wybiorę coś innego.

Czym Sanity tak naprawdę jest

Sanity to dwie rzeczy w jednym produkcie:

1. Baza treści w czasie rzeczywistym — dokumenty JSON, w pełni queryable, hostowane u Sanity.
2. Konfigurowalny edytor (Sanity Studio) — aplikacja Reactowa, którą wdrażasz jako część projektu, ze schematami zdefiniowanymi w kodzie.

Piszesz schemat w TypeScripcie. Sanity Studio czyta go i renderuje edytor. Twoja strona w Astro pyta API i renderuje podstrony. Obie strony zostają zsynchronizowane, bo schemat to jedno źródło prawdy.

Co mnie kupuje, projekt po projekcie

Edytor jest najlepszy w tej kategorii. Sanity Studio wygląda i zachowuje się jak prawdziwe narzędzie redakcyjne — nie jak panel ustawień. Live preview, ustrukturyzowana nawigacja, custom komponenty inputów, undo z porządną historią. Dla nietechnicznego redaktora wrażenie jest bliższe Notiona niż WP-Admina, a to ma znaczenie codziennie.

Schematy w TypeScripcie. Piszę model danych raz, w kodzie, i zarówno edytor, jak i front-end używają tych samych typów. Brak rozjazdów między „co edytor może zrobić“ a „co strona oczekuje“ — najczęstsze źródło bugów w projektach CMS-owych, wyeliminowane przez sam stos.

Obrazki, które po prostu działają. Pipeline obrazów jest świetny. Responsywne warianty on-the-fly, AVIF/WebP, automatyczne kadrowanie z hotspotami ustawianymi przez redaktora. Dla galerii szkolnej albo biblioteki obrazów muzeum samo to oszczędza tydzień integracji.

Wielojęzyczność bez podatku od wtyczek. Pola lokalizowane to pierwszoklasowa koncepcja. Portal szkoły, który zbudowaliśmy w EN + PL + UA, użył jednego schematu, jednego zestawu komponentów, trzech pól językowych na tekst — a redakcja nigdy nie musiała się nad tym zastanawiać.

Hojny darmowy próg. Mała organizacja z jednym lub dwoma redaktorami i kilkoma tysiącami dokumentów wygodnie mieści się w darmowym tier. To nie jest pułapka „trial za miesiąc“.

Gdzie Sanity kąsa

Pierwszy projekt zajmuje jakiś dzień na podpięcie. Uczysz się schematów, GROQ-a (język zapytań Sanity), konfigu Studia. Kiedy raz to zrobisz, jest szybko na zawsze. Pierwszy raz — dzień.

Pricing skaluje się z liczbą wywołań API. Dla typowej strony treściowej to nie problem — generacja statyczna oznacza, że CMS jest pytany w czasie buildu, nie przy każdej wizycie. Dla aplikacji, która woła CMS na każde wyświetlenie, trzeba to przemyśleć. (Astro + ISR albo zapytania w czasie buildu rozwiązuje to elegancko dla rodzaju stron, które buduję.)

GROQ to nie GraphQL. To własny język zapytań. Mały i da się go nauczyć, ale na początku będziesz czytać docsy. Jeśli mocno inwestujesz w narzędzia GraphQL-owe, może wyglądać jak krok w bok.

Dla kogo Sanity jest słuszne

• Szkoły, przedszkola, fundacje. Redaktorzy są nietechniczni, treść ma znaczenie, a panel wchodzący w drogę to deal-breaker. Sanity jest tu wyjątkowo dobry.
• Strony marketingowe z poważnym workflowem redakcyjnym. Aktualności, wydarzenia, galerie, biblioteki dokumentów, wielojęzyczność — wszystko, co buduje się w CMS-ie, zrobione dobrze.
• Studia i agencje obsługujące powyższych. Twój zespół wypuszcza schemat w jeden ranek, a klient publikuje po południu.

Kiedy nie wybieram Sanity

• Strona jest mała i rzadko się zmienia. Trzystronicowa agroturystyka bez zespołu redakcyjnego — użyłabym plików Markdown w repo albo Keystatica. Sanity to overkill.
• Klient chce treści w Gicie z twardą własnością. Keystatic, Markdown, cokolwiek opartego o Gita. Treść w Sanity siedzi w ich chmurze — eksportowalna, ale nie w folderze na Twoim laptopie domyślnie.
• Workflow jest tak specyficzny, że żaden gotowy CMS nie pasuje. Kiedy klient ma łańcuch akceptacji, trzy role redaktorskie, okna scheduled publishing i krok review prawnego, buduję mały custom admin w Next.js. Sanity próbuje być wystarczająco elastyczne dla wszystkiego, ale na krawędziach wygrywa bespoke.

Jak to wdrażam

W typowym projekcie:

1. Strona w Astro generowana statycznie, hostowana na edge (Cloudflare Pages, Netlify, Vercel — wybierz).
2. Sanity Studio w tym samym monorepo, deploy na własnej subdomenie — studio.domena-klienta.pl.
3. Webhook z Sanity triggerujący rebuild Astro, gdy redaktor naciśnie „Publikuj“.
4. Live preview dla redakcji przez preview deploye Astro plus draft mode Sanity.

Efekt dla klienta: publikuje, strona przebudowuje się w sekundy, widzi zmianę na żywo. Efekt dla mnie: jeden stack, jeden schemat, jeden zestaw typów, zero plugin hell.

Uczciwe podsumowanie

Sanity to CMS, po który sięgam pierwszy, bo dziewięć projektów z rzędu okazało się słuszną odpowiedzią na doświadczenie redaktora, prędkość frontu i moją zdrowie psychiczne w przyszłości. To nie jedyna dobra odpowiedź — ale ta, do której wracam domyślnie, dopóki brief nie da mi powodu, żeby skręcić.

Dla szkoły, fundacji albo każdej organizacji, która regularnie publikuje aktualności, wydarzenia, galerie i dokumenty: Sanity plus Astro to kombinacja, na którą stawiam za każdym razem.