Generate an architecture diagram from a Next.js project.
The interesting line in a Next.js app is the one between server and client, and it is invisible in the file tree.
What it reads
The app or pages directory to establish the route tree, the use client directives that mark where the client boundary falls, route handlers and server actions for the API surface, next.config for rewrites and redirects, and any database or service client to identify what the server talks to.
How Next.js becomes components
Routes become the client tier, grouped rather than listed one file per box. Server components and route handlers become the application tier. The client boundary is drawn explicitly, because it determines what ships to the browser and therefore what a user can read, which matters for both performance and for anything you assumed was server-only. Data access from server code becomes the data tier.
Why the layout can be trusted
The agent reads the files listed above and emits a semantic graph: components, the tier each belongs to, and the edges between them, with no coordinates anywhere. The ELK layout engine then computes positions and orthogonal edge routing. This is why the output cannot come back with boxes overlapping or arrows crossing through cards, which is the usual failure when a language model is asked to place things on a canvas itself.
The boundary is where the bugs are
Most confusing behaviour in an App Router codebase comes from a misplaced boundary: a component marked client that pulls a large dependency into the bundle, or a server component doing something that quietly runs on every request. Drawing the boundary rather than inferring it from directives scattered across files makes those obvious.
Your code stays on your machine
It runs on your machine. With a local Ollama model nothing leaves the laptop at all, and with your own API key the file contents go to the provider you chose and never through us. For a source that is your actual codebase, that distinction is usually the deciding one.
Next.js to diagram
| In the project | In the diagram |
|---|---|
| app/ or pages/ route tree | Client tier, grouped by area |
| use client directives | The client boundary, drawn explicitly |
| route.ts handlers | API surface |
| Server actions | Application tier operations |
| Server component data fetching | Edges to the data tier |
| next.config rewrites and redirects | Edge tier routing |
| middleware.ts | Edge tier |
| Database and service clients | Data and external tiers |
The prompt
Questions
App Router or Pages Router?
Both, including projects mid-migration with the two side by side, which is a case where the diagram is unusually useful because it shows how far the migration actually got.
Will it show which components are client versus server?
Yes, that boundary is drawn explicitly rather than left implicit in directives across many files.
Does it work for a static export?
Yes, and the diagram is naturally simpler, since there is no server tier to draw.
Can it diagram the API separately?
Yes. For an app with a substantial API surface, a separate diagram of route handlers and what they touch is more readable than one picture covering both.
Related
- Generate a Diagram from a Prisma SchemaA Prisma schema states relationships explicitly, which makes it one of the most reliable sources for an entity diagram that exists.
- Generate a Diagram from a CodebasePoint it at a repository and it surveys the code the way a new engineer would, then draws what it found.
- Generate a Diagram from TerraformTerraform already describes your infrastructure precisely. The diagram is a rendering of something you have written down, not a guess.
- Generate a Diagram from Kubernetes ManifestsKubernetes YAML contains the whole topology and presents it as several hundred lines in which none of it is visible.
Last updated