Strapi development

Headless CMS oddziela zarządzanie treścią od jej prezentacji: redakcja pracuje w panelu, a treść trafia przez API do dowolnej liczby odbiorców — strony, aplikacji mobilnej, ekranu w salonie. W klasycznym CMS-ie treść i wygląd są zrośnięte, więc każda zmiana wyglądu dotyka warstwy treści i odwrotnie.

Strapi ma sens wtedy, gdy potrzebujesz własnego modelu treści, a nie modelu narzuconego przez szablon: własnych typów, relacji między nimi i uprawnień dopasowanych do tego, jak faktycznie pracuje redakcja. Jest rozwiązaniem otwartym, więc stoi na Twojej infrastrukturze i nie ma opłat od liczby wpisów ani wywołań API.

Nie jest właściwym wyborem, gdy potrzebujesz prostej strony wizytówkowej, którą ktoś ma raz na kwartał zaktualizować — wtedy gotowa platforma będzie tańsza w utrzymaniu. Nie jest też magicznym rozwiązaniem problemu chaosu w treści: headless CMS wymaga wcześniejszego przemyślenia modelu, bo źle zaprojektowany schemat jest trudniejszy do naprawienia niż źle wypełniona strona.

Encja czy pole. Autor, kategoria czy technologia wpisana jako tekst w polu wygląda tak samo jak relacja — do momentu, w którym trzeba zmienić nazwę w stu wpisach albo pokazać listę wszystkiego, co jest z nią powiązane. Relacje kosztują trochę więcej pracy na starcie i zwracają się przy pierwszej większej zmianie.

Jak głęboko dzielić treść na bloki. Strona zbudowana z elastycznych bloków daje redakcji swobodę i pozwala zbudować układy, których nikt nie przewidział — także takie, które psują spójność. Sztywny szablon jest przewidywalny i ciasny. Wybór zależy od tego, czy redakcja ma projektować strony, czy je wypełniać.

Kto może publikować. Obieg z akceptacją ma sens przy większej redakcji, a przeszkadza przy dwóch osobach. Uprawnienia lepiej zacząć od prostych i zacieśniać, gdy pojawi się potrzeba.

Czego nie robić. Nie migruj treści bez wcześniejszego przeglądu — migracja jest najlepszym momentem, żeby nie przenosić tego, co i tak jest martwe. Nie trzymaj konfiguracji wyłącznie w panelu produkcyjnym: zmiany schematu mają iść przez repozytorium i wdrożenie, inaczej środowiska się rozjadą. I nie zakładaj, że aktualizacje same się zrobią — otwarte oprogramowanie wymaga świadomego utrzymania.

Projektujemy strukturę CMS tak, żeby można ją było rozwijać bez ciągłej przebudowy istniejących treści. Wykorzystujemy współdzielone komponenty, relacje oraz Dynamic Zones tam, gdzie faktycznie pomagają redakcji. Konfigurujemy również role, uprawnienia, publikację i podgląd treści.

Efekt ma być prosty: zespół powinien móc samodzielnie publikować i aktualizować treści bez angażowania developera przy każdej zmianie.