Can you use Feature-Sliced Design in Next.js?

Next.jsMiddle~1 min read

Yes, Feature-Sliced Design (FSD) works great in Next.js - you just need to understand the boundary:

app/ (or pages/) is the routing and page composition layer
the FSD layers (shared / entities / features / widgets / pages) are your domain/feature architecture

The main rule

Don't turn FSD folders into routes. That is, keep features/, entities/, shared/ and so on outside app/, so Next doesn't start treating them as route segments.

Recommended structure (App Router + FSD)

txt

src/
  app/                      # routing, layout, page, route handlers only
    (public)/
      page.tsx
    (auth)/
      login/page.tsx
    tasks/
      [id]/
        page.tsx
        layout.tsx
  pages/                    # (optional) if you use the Pages Router
  shared/
    ui/
    lib/
    config/
    api/
  entities/
    task/
      model/
      ui/
      api/
  features/
    solve-task/
      ui/
      model/
      lib/
  widgets/
    task-workspace/
      ui/
  # the pages layer from FSD is often NOT needed in Next, because "pages" = app routes

How to "glue" FSD and Next routes together

In app/.../page.tsx you usually:

fetch data (server actions / fetch / ORM)
wire up widgets/features/entities and assemble the page

Example:

tsx

// src/app/tasks/[id]/page.tsx
import { TaskWorkspace } from "@/widgets/task-workspace/ui/TaskWorkspace";

export default async function Page({ params }: { params: { id: string } }) {
  return <TaskWorkspace taskId={params.id} />;
}

An important nuance: server/client components in FSD

In the Next App Router a component is a Server Component by default.

UI that uses useState, useEffect, zustand, the DOM, an editor - make it use client
Models/utilities in shared/lib, entities/*/model - can often stay server-side/universal

Typical pattern:

widgets/.../ui/*.tsx - can be use client
entities/.../api - server functions / repositories
features/.../model - state/stores (usually client)

Where to keep "api" in FSD with Next

There are 2 reasonable options:

Option A (recommended): server logic next to the domain

txt

entities/task/api/task.repo.ts   # Prisma/SQL

And in app/api/.../route.ts - only a thin controller that calls the repo.

Option B: all HTTP in app/api

txt

app/api/tasks/[id]/route.ts

And in FSD - a client for requests:

txt

shared/api/http.ts
entities/task/api/getTask.ts

Common errors

Putting features/ inside app/ You get "junk" segments, collision problems, confusion.
Making "FSD pages" and "Next pages" at the same time for no reason In Next, the FSD pages layer is usually not needed, because app/ plays the role of pages.
Mixing server-repo and client code in the same file Next will start complaining about imports and bundling.

Short Answer

Interview ready

Premium

A concise answer to help you respond confidently on this topic during an interview.