Nextjs Server Actions Were A Mistake

Quick Overview

The developer ultimately abandoned Next.js Server Actions in favor of tRPC and client-side data fetching for his multi-app experience because Server Actions led to slow performance, especially when navigating between pages or when dealing with large amounts of data, forcing constant manual revalidation and negating the developer experience benefits.

Key Points: The creator initially loved Next.js Server Actions for simplifying data fetching and mutations without needing explicit API endpoints. The primary issue encountered was poor performance, particularly when navigating between pages that required revalidation of large data sets. Calling revalidatePath('/') caused the entire page's data to be refetched, leading to slow transitions without built-in loading animations. The developer found the experience of managing data fetching and mutations across multiple client and server components cumbersome, leading to duplicated logic. He ultimately migrated the application to use tRPC combined with client-side data fetching (using TanStack React Query), which provided a much better developer experience, especially for type safety. The decision was partly driven by the realization that the default behavior of Server Actions was not optimized for high-performance applications with complex navigation and data requirements.

Context: The video details a developer's experience over three years using Next.js Server Actions, initially embracing them as a default for data operations. However, as the developer built more complex applications, including a multi-app experience for a social media marketing tool called Yorby, he encountered significant performance bottlenecks and developer friction, leading him to revert to older patterns like tRPC and client-side fetching.

Detailed Analysis

The speaker recounts his journey with Next.js Server Actions, starting with initial enthusiasm because they eliminated the need to write explicit API endpoints for data fetching and mutations (0:04). This simplicity was highly appealing for quickly building and launching applications like Yorby (0:15, 0:23). However, the honeymoon phase ended when dealing with complex, multi-app architectures. The major flaw identified was performance, specifically when using (0:34, 3:43). Calling this function forced a full re-fetch of all data for the entire page, leading to noticeable slowness during navigation between pages (0:37, 6:22). Since there were no default loading animations, the user experience felt jarring and slow (0:40, 6:21). Furthermore, maintaining shared logic for data fetching and mutations across both the client-side consumer app and the admin portal became redundant, requiring duplicated logic (2:40, 2:50). The developer ultimately migrated away from Server Actions to tRPC combined with TanStack React Query (11:14, 11:50), which offered superior end-to-end type safety and a better developer experience for managing complex data flows, despite the necessity of creating API endpoints again.