Forem: Dearonski

Build a Type-Safe Next.js 15 + Strapi v5 Blog in 10 Minutes

Dearonski — Sun, 17 May 2026 23:17:46 +0000

Next.js + Strapi is one of the best stacks for content-driven sites in 2026. Server Components, ISR, app router, and Strapi v5's clean REST API just click together.

But there's one part that still hurts: typing the data.

You ship your Strapi schema, then sit down in Next.js and… you're back to writing interfaces by hand. Then you forget to populate a relation and your category.name access blows up at runtime in a Server Component, which means a full page error instead of a clean TS warning.

Today we'll fix all of that — end to end — with a small open-source package called strapi-typed-client. By the end of this tutorial you'll have:

A typed Strapi client with full autocomplete
Types that regenerate automatically on next dev and next build
Populate calls where TypeScript knows exactly which nested fields are available
A real working Next.js 15 app reading from Strapi v5

No manual interfaces. No as any. No GraphQL.

Let's build it.

What we'll build

A tiny blog. Two content types in Strapi:

Article — title, slug, body (rich text), cover (media), category (relation), author (relation)
Category — name, slug

And two pages in Next.js:

/ — list of latest articles with cover image and category
/articles/[slug] — full article with author bio

Standard stuff. The interesting part is everything in between.

Step 1 — Install the plugin on the Strapi side

In your Strapi v5 project:

npm install strapi-typed-client

Then enable it in config/plugins.ts:

// config/plugins.ts
export default {
  'strapi-typed-client': {
    enabled: true,
  },
}

Restart Strapi. The plugin exposes your schema at GET /api/strapi-typed-client/schema plus a live /schema-watch SSE endpoint we'll use later.

That's the whole server side.

Step 2 — Install the same package in your Next.js app

npm install strapi-typed-client

Yes, the same package. It contains both the Strapi plugin and the Next.js client — the right entry point gets used depending on where you import from.

Step 3 — Hook it into `next.config.ts`

This is the part that does the magic:

// next.config.ts
import type { NextConfig } from 'next'
import { withStrapiTypes } from 'strapi-typed-client/next'

const nextConfig: NextConfig = {
  // your existing Next.js config
}

export default withStrapiTypes({
  strapiUrl: process.env.NEXT_PUBLIC_STRAPI_URL ?? 'http://localhost:1337',
  token: process.env.STRAPI_TOKEN, // optional, only if your plugin requires auth
})(nextConfig)

What this does:

On next dev — connects to Strapi via SSE and regenerates types the moment your schema changes. Add a field in Strapi admin → TS knows about it before you tab back to your editor.
On next build — runs a one-time sync generation before the build kicks off.
On next start — does nothing (types are already in place).

No separate watcher process. No concurrently. No predev script. It just works as part of your normal Next.js lifecycle.

Step 4 — Generate types for the first time

You can let next dev do it automatically, or trigger it manually:

npx strapi-types generate --url http://localhost:1337

Generated files land in node_modules/strapi-typed-client/dist. (If you'd rather commit the generated files into your repo, use --format ts --output ./src/strapi — handy for monorepos.)

Step 5 — Build the home page

Here's the entire app/page.tsx:

// app/page.tsx
import Image from 'next/image'
import Link from 'next/link'
import { StrapiClient } from 'strapi-typed-client'

const strapi = new StrapiClient({
  baseURL: process.env.NEXT_PUBLIC_STRAPI_URL ?? 'http://localhost:1337',
})

export default async function HomePage() {
  const { data: articles } = await strapi.articles.find({
    sort: ['publishedAt:desc'],
    pagination: { page: 1, pageSize: 10 },
    populate: {
      cover: true,
      category: true,
    },
  })

  return (
    <main>
      <h1>Latest articles</h1>
      <ul>
        {articles.map((article) => (
          <li key={article.documentId}>
            <Link href={`/articles/${article.slug}`}>
              {article.cover && (
                <Image
                  src={article.cover.url}
                  alt={article.cover.alternativeText ?? ''}
                  width={400}
                  height={200}
                />
              )}
              <h2>{article.title}</h2>
              <span>{article.category.name}</span>
            </Link>
          </li>
        ))}
      </ul>
    </main>
  )
}

Pause and look at article.category.name. Try it in your editor. Hover over category — TypeScript knows it's the populated Category entity, not number | Category | undefined. Hover over cover — typed as Media, with url and alternativeText.

Now delete category: true from the populate object. TypeScript immediately marks article.category.name as an error: Property 'name' does not exist on type 'number'.

This is the part nobody else does. The whole point of Strapi's populate API is that the response shape depends on what you asked for. Most clients just type it as a union and shrug. This one infers the actual returned shape from your populate input.

Step 6 — Build the article detail page

// app/articles/[slug]/page.tsx
import { notFound } from 'next/navigation'
import { StrapiClient } from 'strapi-typed-client'

const strapi = new StrapiClient({
  baseURL: process.env.NEXT_PUBLIC_STRAPI_URL ?? 'http://localhost:1337',
})

export default async function ArticlePage({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params

  const { data: articles } = await strapi.articles.find({
    filters: { slug: { $eq: slug } },
    populate: {
      cover: true,
      category: true,
      author: {
        populate: { avatar: true },
      },
    },
  })

  const article = articles[0]
  if (!article) notFound()

  return (
    <article>
      <h1>{article.title}</h1>
      <div>
        <img src={article.author.avatar.url} alt={article.author.name} />
        <span>by {article.author.name}</span>
      </div>
      <p>{article.body}</p>
    </article>
  )
}

Note the nested populate for author.avatar. The returned type is inferred all the way down — article.author.avatar.url is fully typed, but if you remove the inner populate: { avatar: true }, accessing .url becomes a TS error.

Step 7 — Filters and operators (also typed)

Strapi's filter operators ($eq, $contains, $gte, $or, etc.) are typed per field:

const { data } = await strapi.articles.find({
  filters: {
    title: { $contains: 'typescript' },
    publishedAt: { $gte: '2026-01-01' },
    $or: [
      { featured: { $eq: true } },
      { category: { slug: { $eq: 'editors-pick' } } },
    ],
  },
})

Try writing views: { $contains: 'foo' } on a numeric field — TypeScript stops you. No more Invalid filter operator runtime errors from Strapi.

Step 8 — Caching and revalidation

Since the client uses the global fetch, all of Next.js's caching mechanics apply automatically. Pass a second argument to opt in:

// Always fresh
await strapi.articles.find({ /* params */ }, { cache: 'no-store' })

// ISR — revalidate every 60 seconds
await strapi.articles.find({ /* params */ }, { next: { revalidate: 60 } })

// Tag-based revalidation
await strapi.articles.find(
  { /* params */ },
  { next: { tags: ['articles'] } },
)

// Then somewhere in a Server Action:
import { revalidateTag } from 'next/cache'
revalidateTag('articles')

These options are fully typed — same shape Next.js's fetch accepts.

Step 9 — The "rename a field" moment

This is the moment that sells the whole thing.

Keep next dev running.
Open Strapi admin in another tab. Rename title to headline on the Article content type. Save.
Tab back to VS Code.

Within a second or two, every article.title in your codebase lights up red. The watcher caught the schema change, regenerated types, and TypeScript re-checked your project.

No restart. No manual command. No "wait, what did the field used to be called?" archaeology.

This is what withStrapiTypes buys you, and it's the single biggest DX win in the whole package.

Step 10 — Handling errors properly

Server Components fail loudly when fetches throw. The client exports typed errors so you can handle them gracefully:

import { StrapiClient, StrapiError, StrapiConnectionError } from 'strapi-typed-client'

try {
  const { data } = await strapi.articles.find()
  return <ArticleList articles={data} />
} catch (error) {
  if (error instanceof StrapiConnectionError) {
    // Strapi is down — show a friendly fallback
    return <BackendOffline />
  }
  if (error instanceof StrapiError && error.status === 401) {
    // Token expired
    return <NeedAuth />
  }
  throw error
}

Quick gotcha: `as const` for populate objects

If you extract a populate object to a variable, annotate it with as const — otherwise TS widens the literal trues to boolean, and the inference breaks:

// ❌ Wrong — inference breaks
const populate = { category: true, cover: true }

// ✅ Correct
const populate = { category: true, cover: true } as const

await strapi.articles.find({ populate })

Same pattern as satisfies for config objects. Once you know it, it's invisible.

What you got

Recap of what this 10-step tutorial set up:

One package, two install points (Strapi + Next.js)
Zero-config type generation tied to next dev and next build
Live regeneration on schema changes via SSE
Populate calls where the returned type follows the populate input
Typed filters, sorting, pagination
First-class Next.js caching options
Typed error classes for failure handling

No manual interfaces. No GraphQL. No second watcher process. Your Strapi schema is the single source of truth, and your Next.js code knows about it without you doing anything.

Try it

npm install strapi-typed-client

That's the only command you need on either side — the same package powers both the Strapi plugin and the Next.js client.

Full docs live at boxlab-ltd.github.io/strapi-typed-client, source is on GitHub. If you run into anything weird, open an issue — I read all of them.

Now go rename a field in Strapi and watch TypeScript catch it. That part doesn't get old.

Stop Writing Strapi Types by Hand — Auto-Generate a Fully Typed Client in Seconds

Dearonski — Fri, 13 Feb 2026 00:47:16 +0000

If you're using Strapi v5 with TypeScript, you've probably spent hours writing interfaces to match your content types. And every time you change a field in Strapi — you update the types manually. Again.

I built strapi-typed-client to solve this. It's a Strapi plugin + CLI that reads your schema and generates clean TypeScript types and a fully typed API client. One command, full autocomplete.

The problem

Strapi generates contentTypes.d.ts internally, but it's full of Schema.Attribute.* generics that are unusable on the frontend. You end up writing something like:

// Writing this by hand for every content type...
interface Article {
  id: number
  title: string
  content: string
  category?: Category
  // did I forget a field? who knows
}

And then building fetch wrappers with zero type safety:

const res = await fetch(`${STRAPI_URL}/api/articles?populate=*`)
const data = await res.json()
// data is `any` — good luck

The solution

Install the package in your Strapi project:

npm install strapi-typed-client

Enable the plugin:

// config/plugins.ts
export default {
  'strapi-typed-client': { enabled: true },
}

Generate types from your running Strapi instance:

npx strapi-types generate --url http://localhost:1337

That's it. You get two generated files:

Clean TypeScript interfaces

export interface Article {
  id: number
  documentId: string
  title: string
  slug: string
  content: BlocksContent
  excerpt: string | null
  cover: MediaFile | null
  category: Category | null
  author: Author | null
  tags: Tag[]
  publishedDate: string | null
  featured: boolean
  seo: Seo | null
  createdAt: string
  updatedAt: string
}

export interface ArticleInput {
  title: string
  slug?: string
  content?: BlocksContent
  excerpt?: string | null
  cover?: number | null  // relations as IDs for create/update
  category?: number | null
  author?: number | null
  tags?: number[]
  publishedDate?: string | null
  featured?: boolean
}

No generics, no Schema.Attribute.* wrappers. Just plain TypeScript that your editor understands.

A typed API client

import { StrapiClient } from 'strapi-typed-client'

const strapi = new StrapiClient({
  baseURL: 'http://localhost:1337',
})

// Full autocomplete on collection names, filter fields, sort options
const articles = await strapi.articles.find({
  filters: { title: { $contains: 'hello' } },
  populate: { category: true, author: true, tags: true },
  sort: ['publishedDate:desc'],
  pagination: { page: 1, pageSize: 10 },
})

// articles[0].category.name — fully typed, no casting

Type-safe populate

This is where it gets interesting. The generated types include Prisma-style GetPayload helpers:

// Without populate — relations are { id, documentId }
const article = await strapi.articles.findOne('abc123')
article.category // { id: number, documentId: string } | null

// With populate — relations expand to full types
const article = await strapi.articles.findOne('abc123', {
  populate: { category: true, author: true },
})
article.category // Category | null (with all fields)
article.author   // Author | null

Nested populate works too, with unlimited depth:

const article = await strapi.articles.findOne('abc123', {
  populate: {
    category: {
      populate: { articles: true },
    },
    author: {
      fields: ['name', 'email'],
    },
  },
})

Components & Dynamic Zones

Components generate as separate interfaces:

export interface Seo {
  id: number
  metaTitle: string
  metaDescription: string
  ogImage: MediaFile | null
  canonicalUrl: string | null
}

Dynamic Zones become union types:

export type PageContentDynamicZone = HeroSection | FeatureGrid | Testimonial

RichText blocks — typed, no React dependency

Strapi's Blocks editor fields get proper types instead of plain string:

export type BlocksContent = Block[]

export type Block =
  | ParagraphBlock
  | HeadingBlock
  | QuoteBlock
  | CodeBlock
  | ListBlock
  | ImageBlock

Framework-agnostic — use with Vue, Svelte, Astro, anything.

Next.js integration

The client uses native fetch, so Next.js caching, deduplication, and ISR work out of the box:

const articles = await strapi.articles.find(
  { populate: { category: true } },
  { revalidate: 3600, tags: ['articles'] }
)

There's also a withStrapiTypes wrapper that makes type generation fully automatic:

// next.config.ts
import { withStrapiTypes } from 'strapi-typed-client/next'

export default withStrapiTypes()(nextConfig)

next dev — polls Strapi for schema changes, regenerates types on the fly
next build — one-time generation before build
Zero manual steps

Entity-specific filters

Every collection gets typed filter operators scoped to its field types:

// Only valid filter operators for each field type
await strapi.articles.find({
  filters: {
    title: { $contains: 'hello' },       // string operators
    readTime: { $gte: 5 },               // number operators
    featured: { $eq: true },             // boolean
    publishedDate: { $gte: '2025-01-01' }, // date as string
    category: { name: { $eq: 'Tech' } }, // nested relation filters
    $or: [
      { featured: { $eq: true } },
      { readTime: { $gte: 10 } },
    ],
  },
})

Custom API endpoints

If you have custom controllers (not just CRUD), the plugin detects them and generates typed methods:

// Generated from your custom routes
await strapi.newsletter.subscribe({ email: 'user@example.com' })
await strapi.search.find({ q: 'typescript' })

Schema hashing

The CLI computes a SHA-256 hash of your schema. If nothing changed since last run — generation is skipped. Fast CI, no unnecessary rebuilds.

# Check if types are up to date (useful in CI)
npx strapi-types check --url http://localhost:1337

Try it

npm install strapi-typed-client
npx strapi-types generate --url http://localhost:1337

GitHub: BoxLab-Ltd/strapi-typed-client
Docs: boxlab-ltd.github.io/strapi-typed-client
npm: strapi-typed-client

The package is already powering a large production project and is actively maintained. Feedback and contributions welcome!

Forem: Dearonski

Build a Type-Safe Next.js 15 + Strapi v5 Blog in 10 Minutes

What we'll build

Step 1 — Install the plugin on the Strapi side

Step 2 — Install the same package in your Next.js app

Step 3 — Hook it into next.config.ts

Step 4 — Generate types for the first time

Step 5 — Build the home page

Step 6 — Build the article detail page

Step 7 — Filters and operators (also typed)

Step 8 — Caching and revalidation

Step 9 — The "rename a field" moment

Step 10 — Handling errors properly

Quick gotcha: as const for populate objects

What you got

Try it

Stop Writing Strapi Types by Hand — Auto-Generate a Fully Typed Client in Seconds

The problem

The solution

Clean TypeScript interfaces

A typed API client

Type-safe populate

Components & Dynamic Zones

RichText blocks — typed, no React dependency

Next.js integration

Entity-specific filters

Custom API endpoints

Schema hashing

Try it

Step 3 — Hook it into `next.config.ts`

Quick gotcha: `as const` for populate objects