Next.js has become the default choice for new React projects. But here's the problem: most developers treat it like React with a fancy router. They spin up a Next.js app, slap 'use client' on every component, fetch data in useEffect, and wonder why when they face problems.
If that sounds familiar, you're shipping bloat for no reason.
Next.js is not React
React is a UI library. It renders components and manages state. Routing, data fetching, and server logic are your problems.
Next.js is a full-stack framework that uses React for its UI layer. It gives you server-side rendering, static generation, API routes, and server components out of the box. These features exist for specific reasons, and if you're not using them, you're just adding complexity without benefit.
Does SEO matter?
This is the deciding factor. If search engines need to index your content, you need server-side rendering. Client-rendered pages ship JavaScript that builds the DOM after load. Search crawlers can technically execute JavaScript, but they're inconsistent at it. Your e-commerce product pages, blog posts, and landing pages should render on the server or should be statically pre-rendered.
If you're building an internal dashboard or admin panel that lives behind a login, SEO is irrelevant. Client-side rendering is fine. You could use plain React with Vite and skip the Next.js overhead entirely.
What server components actually solve
Server components aren't just about SEO. They solve three problems:
Initial page load
Client components ship JavaScript to the browser, which then fetches data and renders. Users see a loading spinner. Server components fetch data and render HTML before anything reaches the browser. Users see content immediately.
Bundle size
Every library you import in a client component ends up in your JavaScript bundle. Server components run on the server only. That heavy markdown parser or date library never touches the browser.
Security
Server components can access databases and secrets directly. They are also capable of accessing environment variables without the NEXT_PUBLIC_ prefix, since these components are run exclusively on the server.
Converting a client component to a server component
Here's a typical client-side pattern:
"use client";
import { useState, useEffect } from "react";
import { tablesDB } from "@/lib/appwrite";
export default function Products() {
const [products, setProducts] = useState([]);
const [loading, setLoading] = useState(true);
useEffect(() => {
tablesDB
.listRows({
databaseId: DATABASE_ID,
tableId: TABLE_ID,
queries: [Query.equal("status", "active")],
})
.then((res) => setProducts(res.rows))
.finally(() => setLoading(false));
}, []);
if (loading) return <div>Loading...</div>;
return <ProductGrid products={products} />;
}
Here's the server component equivalent (without 'use client'):
import { createAdminClient } from "@/lib/appwrite/server";
export default async function Products() {
const { tablesDB } = await createAdminClient();
const { rows } = await tablesDB.listRows({
databaseId: DATABASE_ID,
tableId: TABLE_ID,
queries: [Query.equal("status", "active")],
});
return <ProductGrid products={rows} />;
}
Build fast, scale faster
Backend infrastructure and web hosting built for developers who ship.
Start for free- Open source
- Support for over 13 SDKs
- Managed cloud solution
Setting up Appwrite for server-side rendering
The Appwrite Web SDK runs in browsers. For server components, you need the Node SDK:
npm install node-appwrite
Create two client factories. The admin client uses an API key for public data:
// lib/appwrite/server.ts
import { Client, TablesDB, Account } from "node-appwrite";
export async function createAdminClient() {
const client = new Client()
.setEndpoint(process.env.APPWRITE_ENDPOINT)
.setProject(process.env.APPWRITE_PROJECT_ID)
.setKey(process.env.APPWRITE_API_KEY);
return {
tablesDB: new TablesDB(client),
account: new Account(client),
};
}
The session client uses the logged-in user's session for protected data:
import { Client, TablesDB, Account } from "node-appwrite";
import { cookies } from "next/headers";
export async function createSessionClient() {
const client = new Client()
.setEndpoint(process.env.APPWRITE_ENDPOINT)
.setProject(process.env.APPWRITE_PROJECT_ID);
const session = (await cookies()).get("session");
if (session) {
client.setSession(session.value);
}
return {
tablesDB: new TablesDB(client),
account: new Account(client),
};
}
The difference matters. Admin client queries return all rows matching your query. Session client queries return only rows the user has permission to access.
Handling authentication
Login with a server action:
// app/login/page.tsx
import { cookies } from "next/headers";
import { redirect } from "next/navigation";
import { createAdminClient } from "@/lib/appwrite/server";
export default function LoginPage() {
async function login(formData: FormData) {
"use server";
const { account } = await createAdminClient();
const session = await account.createEmailPasswordSession(
formData.get("email") as string,
formData.get("password") as string
);
(await cookies()).set("session", session.secret, {
httpOnly: true,
secure: true,
sameSite: "strict",
expires: new Date(session.expire),
});
redirect("/");
}
return (
<form action={login}>
<input name="email" type="email" required />
<input name="password" type="password" required />
<button type="submit">Log in</button>
</form>
);
}
Protect routes with a layout:
// app/(protected)/layout.tsx
import { redirect } from "next/navigation";
import { createSessionClient } from "@/lib/appwrite/server";
export default async function ProtectedLayout({ children }) {
try {
const { account } = await createSessionClient();
await account.get();
} catch {
redirect("/login");
}
return children;
}
When to skip all of this
Use plain React when:
- Your app lives behind authentication
- Search engines don't need to index it
- You prefer client-side data fetching patterns
- You're building a very simple app that doesn't need server-capabilities
There's nothing wrong with client-side rendering. The mistake is using Next.js and not leveraging what makes it useful.
