Exploring Next.js 13: App Router and Best Practices
Exploring Next.js 13: App Router and Best Practices
Next.js has been my go-to React framework for applications where SEO, server-side rendering, and performance matter. Next.js 13 introduced one of the biggest changes to the framework with the App Router, React Server Components, and a much clearer separation between server and client-side code.
When I originally started working with the App Router, though, it still felt fairly early. The architecture made a lot of sense, but there were definitely rough edges—especially around third-party libraries, serverless deployments, and figuring out where the server/client boundary should live.
After working with it, here are a few things I learned and some practices I found useful.
Proceed with Caution
1. Prisma and Serverless
If you're using Prisma with a serverless Next.js application, it's worth understanding how your database connections are being managed.
Traditional database connection pooling doesn't always map cleanly to serverless environments. When functions scale horizontally, it's possible to create significantly more database connections than expected.
This isn't necessarily a Next.js-specific problem, but the App Router makes it very easy to perform database operations directly inside server components, route handlers, and server-side functions, so it's something you need to think about early.
For production applications, make sure your database architecture is designed for the environment you're deploying into rather than assuming the same configuration you would use on a long-running Node.js server.
2. Cloudflare Pages Compatibility
Another issue I ran into early was deployment compatibility with Cloudflare Pages.
Next.js tends to move quickly and historically many hosting platforms haven't supported every Next.js feature at exactly the same time. Features that work seamlessly on Vercel may require additional configuration—or may not immediately be supported—on other platforms.
If you're deploying Next.js outside of Vercel, I recommend verifying support for the specific features you're using, especially:
- Server Components
- Route Handlers
- Middleware
- Edge Runtime
- Server-side rendering
- Image optimization
The framework may support something, but that doesn't automatically mean every hosting environment supports it in exactly the same way.
Handling CSS Frameworks and React Libraries
One of the bigger mental shifts with the App Router is understanding the separation between Server Components and Client Components.
A lot of existing React libraries were originally designed around the assumption that everything runs in the browser. That assumption doesn't always work with Server Components.
1. Using "use client"
Certain component libraries require the "use client" directive because they depend on browser APIs, React state, context, or other client-side functionality.
For example:
```tsx "use client";
import { Button } from "@mui/material";
export default function MyButton() {
return ;
}