Należy podłączyć frontend do CMS Strapi

Integracja frontu Next.js z Strapi CMS + wielojęzyczność + edytowanie z panelu administracyjnego

1. Cel

Podłączyć istniejący frontend na Next.js do Strapi CMS tak, aby:

1. treść strony była edytowana z panelu administracyjnego Strapi;

2. istniała wielojęzyczność (minimum 2 lokalizacje);

3. istniejące “pokoje/wewnętrzne strony” (sekcje osobiste) nadal działały i poprawnie integrowały się z treścią CMS;

4. zmiany treści z Strapi były wyświetlane na stronie bez ręcznych przesyłek (przez ISR/webhook).

2. Dane wyjściowe (co już jest)

• Gotowy frontend na Next.js (strony, pokoje, UI, routing już zrealizowane).

• Wymagana konfiguracja Strapi i powiązanie go z frontendem.

• Stos: Next.js + Strapi + baza danych (PostgreSQL preferowane).

3. Zakres prac freelancera (Scope)

3.1. Strapi (CMS)

Freelancer powinien:

1. Rozwinąć Strapi (lokalnie i/lub na serwerze zgodnie z umową).

2. Skonfigurować bazę danych (PostgreSQL).

3. Włączyć i skonfigurować i18n (Internationalization):

   • lokalizacje minimum: en-CA i fr-CA (lub te, które wskazał klient).

4. Stworzyć modele treści (patrz sekcja 4).

5. Skonfigurować role i uprawnienia:

   • Public (publiczne API do odczytu potrzebnych encji);

   • Authenticated (jeśli będzie potrzebne dla wewnętrznych stron);

   • Admin (edycja).

6. Przygotować treść demo do weryfikacji (minimum: Global + Home + 1–2 strony + 2–3 bloki).

3.2. Next.js (Frontend)

Freelancer powinien:

1. Podłączyć Next.js do Strapi przez jednolity interfejs API (patrz sekcja 5).

2. Zrealizować pobieranie i wyświetlanie:

   • Globalnych danych (header/footer/menu/ogólne teksty);

   • stron po slug;

   • dynamically sections (Dynamic Zone) z renderowaniem komponentów na froncie.

3. Zrealizować wielojęzyczny routing i zapytania z parametrem locale.

4. Zrealizować mechanizm aktualizacji treści bez wdrożenia:

   • ISR revalidation i/lub Webhook z Strapi do endpointu Next.js.

5. Nie łamać istniejących pokoi/wewnętrznych stron:

   • pokoje pozostają w bieżącej architekturze;

   • w razie potrzeby — zamiana poszczególnych tekstów/SEO/menu przez CMS.

4. Model treści Strapi (minimalnie obowiązkowy)

Wszystkie encje muszą wspierać i18n, gdzie to logiczne.

4.1 Typy pojedyncze

A) Global

• siteName (tekst)

• headerMenu (powtarzalne: tytuł, url)

• footerMenu (powtarzalne: tytuł, url)

• contacts (telefon/email/adres)

• socialLinks (powtarzalne: typ, url)

• cta (tytuł, tekstPrzycisku, urlPrzycisku)

• defaultSeo (patrz poniżej)

B) Domyślne SEO
(można częścią Global)

• metaTitle

• metaDescription

• ogImage

• noindex/nofollow (boolean)

4.2 Typy kolekcji

A) Strona

• title (tekst)

• slug (UID)

• sections (Dynamic Zone — lista komponentów)

• seo (komponent: metaTitle/metaDescription/ogImage/noindex)

• publishedAt

B) (Opcjonalnie, jeśli potrzebne w ramach tego etapu) Produkt / Marka / Kategoria
Jeśli katalog już istnieje na froncie z innych źródeł — na tym etapie dopuszcza się nie wdrażać.
Jeśli wdrażane:

• Produkt: sku, slug, title, description, images, downloads, brand, category, specs, seo.

4.3 Komponenty dla Dynamic Zone (obowiązkowy minimum)

1. hero:

   • tytuł, podtytuł, obraz, tekstPrzycisku, urlPrzycisku

2. richText:

   • html/markdown rich text

3. imageText:

   • obraz, tytuł, tekst, layoutLeftRight (enum)

4. featuresGrid:

   • elementy (tytuł, tekst, ikona(opcjonalnie))

5. accordion:

   • elementy (pytanie, odpowiedź)

Freelancer powinien zrealizować render tych komponentów na froncie 1:1 według struktury.

5. Wymagania dotyczące integracji Next.js ↔ Strapi

5.1 Warstwa API

Stworzyć strukturę w Next.js:

• lib/strapi/strapiClient.(ts|js) — jednolity klient fetch

• lib/strapi/queries/* — funkcje zapytań (getGlobal, getPageBySlug, itd.)

• lib/strapi/mappers/* — przekształcenie odpowiedzi Strapi do typów frontu (aby komponenty nie zależały od raw-JSON)

Obowiązkowe wymagania:

• centralne przetwarzanie błędów/timeoutów;

• możliwość podłączenia tokena (jeśli wymagany dostęp prywatny);

• logowanie błędów w konsoli (dev) + zwrot fallback (jeśli uzgodnione z klientem).

5.2 Wielojęzyczność

• Routing: /{locale}/...

• Zapytania do Strapi muszą zawsze zawierać locale.

• Fallback: jeśli tłumaczenie jest niedostępne — zwrócić treść z domyślnej lokalizacji (lub pokazać 404 — po uzgodnieniu).

5.3 Wydajność

• Dla publicznych stron używać SSG/ISR (preferowane), lub SSR tam, gdzie to konieczne.

• Dodaj revalidation:

  • ISR interval (na przykład 60–300 sek) i/lub

  • webhook z Strapi dla natychmiastowej aktualizacji.

6. Webhook / Revalidate (obowiązkowa część)

1. W Strapi skonfigurować webhook na zdarzenia:

   • create/update/publish/unpublish dla Page/Global (i innych encji, jeśli wdrażane).

2. Na Next.js stworzyć endpoint:

   • weryfikacja sekretnego tokena (shared secret)

   • uruchomienie revalidate konkretnej ścieżki/tagów

Wynik: treść zmienia się w panelu administracyjnym → strona aktualizuje się bez ręcznych działań.

7. Bezpieczeństwo (minimalne wymagania)

• Wszystkie sekrety (token Strapi, sekret webhook) — tylko w .env, bez commitowania do repozytorium.

• Ograniczyć Public permissions w Strapi tylko do niezbędnych odczytów.

• Panel administracyjny Strapi:

  • zmienić domyślny URL (opcjonalnie),

  • włączyć podstawowe środki ochrony (CORS, limit szybkości przy dostępności middleware).

8. Wymagania dotyczące jakości kodu

• TypeScript preferowane.

• Kod nie powinien “rozmywać” logiki Strapi po komponentach; wszystkie zapytania przez lib/strapi/*.

• Reużywalne komponenty dynamic zone powinny być rozszerzalne (łatwo dodać nowy blok).

9. Dostawa (Deliverables)

Freelancer powinien p