Separating Concerns in Next.js for Better Performance, Security, and Maintainability

I built an MVP version of AI journaling app using v0 about a month ago. Thanks to v0 the development speed was quite fast, but architecture-wise there were a lot of parts that needed improvement. That's why I decided to review the structure and transform it from "something that just works" to a design that's easier to scale and has better performance. This post is what I presented in the lightning talk that I held. It covers how I addressed key architectural challenges in my Next.js application by properly separating concerns between server-side and client-side components. Performance improvement MVP version "use client"; function EditJournalContent({ id }: { id: string }) { // Details omitted const supabase = createClient(); const [editedText, setEditedText] = useState(""); const [editedTitle, setEditedTitle] = useState(""); const [editedMood, setEditedMood] = useState(5); const [createdAt, setCreatedAt] = useState(""); useEffect(() => { // Data fetching and displaying data logic are coupled in the same component const fetchJournal = async () => { const { data: selectedData, error: dbError } = await supabase .from("journal_entries") .select("id, text_data, title, mood, created_at") .match({ id, }) .single(); if (dbError) { console.log({ dbError }); } setEditedText(selectedData?.text_data); setEditedTitle(selectedData?.title); setEditedMood(selectedData?.mood); setCreatedAt(selectedData?.created_at); }; fetchJournal(); }, [supabase, id]); } // UI logic is coming below This is a client component because "use client" directive is at the top. Quite a few components were handling both data fetching and UI rendering simultaneously in client components. This might causes slowing down communication between client and server and increase JavaScript bundle size. Improved version import React from "react"; import { QUERIES } from "@/app/server/db/queries"; import EditJournal from "@/app/journal/[id]/edit/edit-journal"; export default async function EditJournalPage(props: { params: Promise; }) { const { id } = await props.params; const parsedId = parseInt(id, 10); const journal = await QUERIES.getJournalById(parsedId); return ; } Created server components by deleting "use client" that handle data retrieval and pass only necessary data to client components. This creates a clear separation between data access and UI rendering. Better performance: this possibly speed up communication between client and server and reduce JavaScript bundle size. Security improvement MVP version "use client"; function EditJournalContent({ id }: { id: string }) { // Details omitted const supabase = createClient(); const [editedText, setEditedText] = useState(""); const [editedTitle, setEditedTitle] = useState(""); const [editedMood, setEditedMood] = useState(5); const [createdAt, setCreatedAt] = useState(""); useEffect(() => { // Database query is written directly in a client component const fetchJournal = async () => { const { data: selectedData, error: dbError } = await supabase .from("journal_entries") .select("id, text_data, title, mood, created_at") .match({ id, }) .single(); if (dbError) { console.log({ dbError }); } setEditedText(selectedData?.text_data); setEditedTitle(selectedData?.title); setEditedMood(selectedData?.mood); setCreatedAt(selectedData?.created_at); }; fetchJournal(); }, [supabase, id]); } Database credentials and queries were potentially exposed to client browsers, creating significant security vulnerabilities. Improved version import React from "react"; import { QUERIES } from "@/app/server/db/queries"; import EditJournal from "@/app/journal/[id]/edit/edit-journal"; export default async function EditJournalPage(props: { params: Promise; }) { const { id } = await props.params; const parsedId = parseInt(id, 10); // Database query is detached from UI logic const journal = await QUERIES.getJournalById(parsedId); return ; } // This directive ensures this component can be used only on server components. import "server-only"; import { createClient } from "@/utils/supabase/server"; import { JournalEntry } from "@/types/diary"; export const QUERIES = { getJournalEntries: async function () { const supabase = await createClient(); const { data: journalEntries, error: fetchError } = await supabase .from("journal_entries") .select("id, text_data, title, mood, created_at") .order("created_at", { ascending: false }); if (fetchError) throw Error("Error fetching diary entries"); return journalEntries as JournalEntry[]; }, getJournalById: async function (id: number) { const supabase

Mar 21, 2025 - 11:54

Separating Concerns in Next.js for Better Performance, Security, and Maintainability

I built an MVP version of AI journaling app using v0 about a month ago. Thanks to v0 the development speed was quite fast, but architecture-wise there were a lot of parts that needed improvement. That's why I decided to review the structure and transform it from "something that just works" to a design that's easier to scale and has better performance. This post is what I presented in the lightning talk that I held. It covers how I addressed key architectural challenges in my Next.js application by properly separating concerns between server-side and client-side components.

Performance improvement

MVP version

"use client";

function EditJournalContent({ id }: { id: string }) {
 // Details omitted
  const supabase = createClient();
  const [editedText, setEditedText] = useState("");
  const [editedTitle, setEditedTitle] = useState("");
  const [editedMood, setEditedMood] = useState(5);
  const [createdAt, setCreatedAt] = useState("");

  useEffect(() => {
    // Data fetching and displaying data logic are coupled in the same component
    const fetchJournal = async () => {
      const { data: selectedData, error: dbError } = await supabase
        .from("journal_entries")
        .select("id, text_data, title, mood, created_at")
        .match({
          id,
        })
        .single();

      if (dbError) {
        console.log({ dbError });
      }
      setEditedText(selectedData?.text_data);
      setEditedTitle(selectedData?.title);
      setEditedMood(selectedData?.mood);
      setCreatedAt(selectedData?.created_at);
    };

    fetchJournal();
  }, [supabase, id]);
}

// UI logic is coming below

This is a client component because "use client" directive is at the top.
Quite a few components were handling both data fetching and UI rendering simultaneously in client components.
This might causes slowing down communication between client and server and increase JavaScript bundle size.

Improved version

import React from "react";
import { QUERIES } from "@/app/server/db/queries";
import EditJournal from "@/app/journal/[id]/edit/edit-journal";

export default async function EditJournalPage(props: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await props.params;
  const parsedId = parseInt(id, 10);
  const journal = await QUERIES.getJournalById(parsedId);

  return <EditJournal id={parsedId} journal={journal} />;
}

Created server components by deleting "use client" that handle data retrieval and pass only necessary data to client components.
This creates a clear separation between data access and UI rendering.
Better performance: this possibly speed up communication between client and server and reduce JavaScript bundle size.

Security improvement

MVP version

"use client";

function EditJournalContent({ id }: { id: string }) {
 // Details omitted
  const supabase = createClient();
  const [editedText, setEditedText] = useState("");
  const [editedTitle, setEditedTitle] = useState("");
  const [editedMood, setEditedMood] = useState(5);
  const [createdAt, setCreatedAt] = useState("");

  useEffect(() => {
    // Database query is written directly in a client component
    const fetchJournal = async () => {
      const { data: selectedData, error: dbError } = await supabase
        .from("journal_entries")
        .select("id, text_data, title, mood, created_at")
        .match({
          id,
        })
        .single();

      if (dbError) {
        console.log({ dbError });
      }
      setEditedText(selectedData?.text_data);
      setEditedTitle(selectedData?.title);
      setEditedMood(selectedData?.mood);
      setCreatedAt(selectedData?.created_at);
    };

    fetchJournal();
  }, [supabase, id]);
}

Database credentials and queries were potentially exposed to client browsers, creating significant security vulnerabilities.

Improved version

import React from "react";
import { QUERIES } from "@/app/server/db/queries";
import EditJournal from "@/app/journal/[id]/edit/edit-journal";

export default async function EditJournalPage(props: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await props.params;
  const parsedId = parseInt(id, 10);
  // Database query is detached from UI logic
  const journal = await QUERIES.getJournalById(parsedId);

  return <EditJournal id={parsedId} journal={journal} />;
}

// This directive ensures this component can be used only on server components.
import "server-only";

import { createClient } from "@/utils/supabase/server";
import { JournalEntry } from "@/types/diary";

export const QUERIES = {
  getJournalEntries: async function () {
    const supabase = await createClient();
    const { data: journalEntries, error: fetchError } = await supabase
      .from("journal_entries")
      .select("id, text_data, title, mood, created_at")
      .order("created_at", { ascending: false });

    if (fetchError) throw Error("Error fetching diary entries");

    return journalEntries as JournalEntry[];
  },

  getJournalById: async function (id: number) {
    const supabase = await createClient();
    const { data: entry, error: fetchError } = await supabase
      .from("journal_entries")
      .select("id, text_data, title, mood, created_at, updated_at")
      .match({
        id,
      })
      .single();

    if (fetchError) throw new Error("Error fetching diary by id", fetchError);

    return entry as JournalEntry;
  }
};

Added 'server-only' import to files containing database queries.
This creates a boundary that prevents client components from importing server-only code.
Better security: Ensures all database operations and credentials stay strictly on the server.

Maintainability improvement

MVP version

Look at the MVP version of the code in Security improvement section.

Had identical database query code (fetchJournal) repeated across multiple components.

Improved version

Look at the MVP version of the code in Security improvement section.

Created a dedicated queries file with all database operations
Organized queries as methods of a single object (e.g., QUERIES.getJournalById())
Better maintainability: When changes are needed (like removing a field), I only need to update one place

Column: What's the difference between `import server-only` and `use server`?

This is the great question asked by one of the participants when I did lightning talk.

The main differences between import server-only and use server in Next.js are:

Purpose:
- import 'server-only' is a package that ensures code is never executed on the client.
  - Using server-only to prevent leaking secrets:this link on React document makes more sense to me.
- 'use server' marks server-side functions that can be imported and called from client components.
  - Explanation about use server in React document: this makes sense to me as well.
Usage:
- import 'server-only' is used as an import statement at the top of files containing server-only code.
  - Data fetching code contains sensitive credentials is a great use case.
- 'use server' is a directive placed at the top of a file or before individual functions to mark them as server actions.
  - Server Functions in forms are most common usage.
Behavior:
- server-only prevents the entire module from being imported on the client.
- use server allows client components to call specific server functions, facilitating client-server communication.
Scope:
- server-only affects the entire file.
- use server can be applied to the entire file or to specific functions.

Here's a simple example of each:

// database.js
import 'server-only';

export function fetchData() {
  // Database operations that should never run on client
}

// actions.js
'use server';

export async function submitForm(formData) {
  // Server-side form processing
  // Can be called from client components
}

Conclusion

Refactoring my AI journaling app from MVP to a robust architecture has delivered three key improvements:

Better Performance: Moving data fetching to server components reduced bundle size and eliminated unnecessary client-server communication.
Enhanced Security: Using server-only created a boundary that keeps database operations and credentials strictly on the server.
Improved Maintainability: Centralizing database queries in one file made the codebase easier to update and maintain.

This architectural shift shows how taking time to learn and implement Next.js best practices can transform an app from "something that just works" to "something that works well." Hope this article helps!