Next.js 14 Server Actions: The Patterns Junior Devs Always Get Wrong

Next.js 14 introduced Server Actions, a powerful feature that allows developers to execute server-side logic directly from client components. While this opens up incredible possibilities for building dynamic and interactive web applications, it also comes with pitfalls, especially for junior developers. In this article, I’ll walk through the common mistakes I’ve seen developers make when using Server Actions, how to avoid them, and the best practices to ensure your code is robust, maintainable, and secure.

---

Why Server Actions Are Tricky

Server Actions blur the line between client and server-side logic. While this is convenient, it can lead to confusion, especially for developers who are still getting comfortable with Next.js’s architecture. Common issues include poor validation, lack of error handling, and misuse of state management. Let’s dive into the specifics.

---

Mistake #1: Skipping Input Validation

One of the most common mistakes I’ve seen is failing to validate user input before processing it on the server. Without proper validation, your application becomes vulnerable to malicious input, SQL injection, and other security risks.

Bad Example: No Validation

// actions.js
export async function createPost(formData) {
  const title = formData.get("title");
  const content = formData.get("content");

  // Directly insert into the database
  await db.post.create({ data: { title, content } });
}

In this example, the code blindly accepts user input without checking if it’s valid. If a user submits a 10,000-character title or empty content, the database will still process the request.

Good Example: Validating Inputs

// actions.js
export async function createPost(formData) {
  const title = formData.get("title");
  const content = formData.get("content");

  // Validate inputs
  if (!title || title.length > 100) {
    throw new Error("Title must be between 1 and 100 characters.");
  }
  if (!content || content.length > 1000) {
    throw new Error("Content must be between 1 and 1000 characters.");
  }

  await db.post.create({ data: { title, content } });
}

Here, I’ve added basic validation to ensure the title and content meet specific criteria. This prevents invalid data from reaching the database and improves the user experience by providing clear error messages.

---

Mistake #2: Ignoring Error Boundaries

Server Actions can fail for various reasons: database errors, network issues, or invalid input. Without proper error handling, these failures can crash your application or leave users confused.

Bad Example: No Error Handling

// page.js
export default function CreatePostPage() {
  async function handleSubmit(formData) {
    "use server";
    await createPost(formData);
  }

  return (
    <form action={handleSubmit}>
      <input name="title" placeholder="Title" />
      <textarea name="content" placeholder="Content"></textarea>
      <button type="submit">Create Post</button>
    </form>
  );
}

In this example, if the createPost action fails, the user won’t receive any feedback. The form submission will simply hang or silently fail.

Good Example: Handling Errors Gracefully

// page.js
export default function CreatePostPage() {
  const [error, setError] = useState(null);

  async function handleSubmit(formData) {
    "use server";
    try {
      await createPost(formData);
    } catch (err) {
      setError(err.message);
    }
  }

  return (
    <>
      {error && <div className="error">{error}</div>}
      <form action={handleSubmit}>
        <input name="title" placeholder="Title" />
        <textarea name="content" placeholder="Content"></textarea>
        <button type="submit">Create Post</button>
      </form>
    </>
  );
}

In this improved version, I catch errors from the createPost action and display them to the user. This provides clear feedback and helps users understand what went wrong.

---

Mistake #3: Overusing Server Actions

Another common mistake is treating Server Actions as a replacement for traditional API routes. While Server Actions are convenient, they aren’t always the best choice. Overusing them can lead to tightly coupled code and reduced flexibility.

Bad Example: Using Server Actions for Everything

// page.js
export default function ProfilePage() {
  async function updateProfile(formData) {
    "use server";
    const name = formData.get("name");
    await db.user.update({ where: { id: 1 }, data: { name } });
  }

  return (
    <form action={updateProfile}>
      <input name="name" placeholder="Name" />
      <button type="submit">Update Profile</button>
    </form>
  );
}

Here, the updateProfile action is tightly coupled to the ProfilePage component. If you need to reuse this logic elsewhere, you’ll have to duplicate the code or refactor it.

Good Example: Separating Concerns

// actions.js
export async function updateProfile(userId, name) {
  await db.user.update({ where: { id: userId }, data: { name } });
}

// page.js
export default function ProfilePage() {
  async function handleSubmit(formData) {
    "use server";
    const name = formData.get("name");
    await updateProfile(1, name);
  }

  return (
    <form action={handleSubmit}>
      <input name="name" placeholder="Name" />
      <button type="submit">Update Profile</button>
    </form>
  );
}

By separating the updateProfile action into its own function, I’ve made it reusable and easier to test. This approach follows the principle of separation of concerns and improves code maintainability.

---

Mistake #4: Failing to Optimize Performance

Server Actions run on the server, which means every call incurs latency. If you’re making too many calls or handling large payloads, your application’s performance will suffer.

Bad Example: Making Unnecessary Calls

// page.js
export default function ProductPage() {
  async function addToCart(productId) {
    "use server";
    await db.cart.add({ productId, quantity: 1 });
  }

  return (
    <>
      <button onClick={() => addToCart(1)}>Add to Cart</button>
      <button onClick={() => addToCart(2)}>Add to Cart</button>
      <button onClick={() => addToCart(3)}>Add to Cart</button>
    </>
  );
}

Here, clicking each button triggers a separate Server Action, resulting in multiple server calls. This can slow down the application and overwhelm the server.

Good Example: Batching Actions

// page.js
export default function ProductPage() {
  async function addToCart(productIds) {
    "use server";
    await Promise.all(productIds.map((id) => db.cart.add({ productId: id, quantity: 1 })));
  }

  return (
    <button onClick={() => addToCart([1, 2, 3])}>Add All to Cart</button>
  );
}

In this optimized version, I batch the addToCart actions into a single call. This reduces latency and improves performance.

---

Conclusion

Server Actions are a powerful tool in Next.js 14, but they require careful handling to avoid common pitfalls. By validating inputs, handling errors, separating concerns, and optimizing performance, you can build robust and efficient applications. As a junior developer, mastering these patterns will not only improve your code but also deepen your understanding of Next.js and modern web development. Happy coding!

---

⚡ Want the Full Prompt Library?

I compiled all of these patterns (plus 40+ more) into the Senior React Developer AI Cookbook — $19, instant download. Covers Server Actions, hydration debugging, component architecture, and real production prompts.

Browse all developer tools at apolloagmanager.github.io/apollo-ai-store