Need to connect the front end to CMS Strapi

Integration of Next.js Frontend with Strapi CMS + Multilingual Support + Admin Panel Editing

1. Objective

Connect the existing frontend on Next.js to Strapi CMS so that:

1. the website content can be edited from the Strapi admin panel;

2. there is multilingual support (at least 2 locales);

3. the existing “dashboards/internal pages” (personal sections) continue to work and integrate correctly with the CMS content;

4. content changes from Strapi are displayed on the site without manual re-uploading (via ISR/webhook).

2. Initial Data (what is already available)

• Ready frontend on Next.js (pages, dashboards, UI, routing are already implemented).

• It is required to set up Strapi and connect it to the frontend.

• Stack: Next.js + Strapi + database (PostgreSQL preferred).

3. Freelancer's Scope of Work

3.1. Strapi (CMS)

The freelancer must:

1. Deploy Strapi (locally and/or on a server as agreed).

2. Set up the database (PostgreSQL).

3. Enable and configure i18n (Internationalization):

   • locales at minimum: en-CA and fr-CA (or those specified by the client).

4. Create content models (see section 4).

5. Set up roles and permissions:

   • Public (public APIs for reading necessary entities);

   • Authenticated (if needed for internal pages);

   • Admin (editing).

6. Prepare demo content for testing (minimum: Global + Home + 1–2 pages + 2–3 blocks).

3.2. Next.js (Frontend)

The freelancer must:

1. Connect Next.js to Strapi through a unified API layer (see section 5).

2. Implement fetching and displaying:

   • Global data (header/footer/menu/general texts);

   • pages by slug;

   • dynamic sections (Dynamic Zone) with rendering components on the frontend.

3. Implement multilingual routing and requests with the locale parameter.

4. Implement a mechanism for content updates without deployment:

   • ISR revalidation and/or Webhook from Strapi to Next.js endpoint.

5. Not break existing dashboards/internal pages:

   • dashboards remain in the current architecture;

   • if necessary — replace individual texts/SEO/menu through CMS.

4. Strapi Content Model (minimum requirements)

All entities must support i18n where it makes sense.

4.1 Single Types

A) Global

• siteName (text)

• headerMenu (repeatable: title, url)

• footerMenu (repeatable: title, url)

• contacts (phone/email/address)

• socialLinks (repeatable: type, url)

• cta (title, buttonText, buttonUrl)

• defaultSeo (see below)

B) SEO Defaults
(can be part of Global)

• metaTitle

• metaDescription

• ogImage

• noindex/nofollow (boolean)

4.2 Collection Types

A) Page

• title (text)

• slug (UID)

• sections (Dynamic Zone — list of components)

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

• publishedAt

B) (Optional, if needed in this phase) Product / Brand / Category
If the catalog already exists on the frontend from other sources — it is allowed not to implement at this stage.
If implemented:

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

4.3 Components for Dynamic Zone (mandatory minimum)

1. hero:

   • title, subtitle, image, buttonText, buttonUrl

2. richText:

   • html/markdown rich text

3. imageText:

   • image, title, text, layoutLeftRight (enum)

4. featuresGrid:

   • items (title, text, icon(optional))

5. accordion:

   • items (question, answer)

The freelancer must implement the rendering of these components on the frontend 1:1 according to the structure.

5. Requirements for Next.js ↔ Strapi Integration

5.1 API Layer

Create a structure in Next.js:

• lib/strapi/strapiClient.(ts|js) — unified fetch client

• lib/strapi/queries/* — query functions (getGlobal, getPageBySlug, etc.)

• lib/strapi/mappers/* — transformation of Strapi responses to frontend types (so that components do not depend on raw JSON)

Mandatory requirements:

• centralized error/timeout handling;

• ability to connect a token (if private access is required);

• logging errors to the console (dev) + returning fallback (if agreed with the client).

5.2 Multilingual Support

• Routing: /{locale}/...

• Requests to Strapi must always include locale.

• Fallback: if the translation is missing — return content from the default locale (or show 404 — as agreed).

5.3 Performance

• For public pages use SSG/ISR (preferably), or SSR where necessary.

• Add revalidation:

  • ISR interval (e.g., 60–300 seconds) and/or

  • webhook from Strapi for instant updates.

6. Webhook / Revalidate (mandatory part)

1. In Strapi set up a webhook for events:

   • create/update/publish/unpublish for Page/Global (and other entities if implemented).

2. In Next.js create an endpoint:

   • check the secret token (shared secret)

   • trigger revalidation of a specific path/tags

Result: content changes in the admin panel → the site updates without manual actions.

7. Security (minimum requirements)

• All secrets (Strapi token, webhook secret) — only in .env, without committing to the repository.

• Limit Public permissions in Strapi only to necessary reads.

• Strapi admin panel:

  • change the default URL (optional),

  • enable basic security measures (CORS, rate limit if middleware is available).

8. Code Quality Requirements

• TypeScript preferred.

• The code should not “smear” Strapi logic across components; all requests through lib/strapi/*.

• Reusable components in the dynamic zone should be extensible (easy to add a new block).

9. Deliverables

The freelancer must p