It’s a simple surface-level question that has made a home in every developer’s mind, probably even YOU.

Let me be clear: Server actions are not universal solutions, and neither is a serverless backend or anything else.

The use of any feature, library, framework, or technology depends on YOUR requirements, not on other people’s opinions of what is best.

When to use Server Actions

Here are some scenarios where using Server Actions is particularly advantageous:

1. Form Submissions

   Server Actions excel at handling form submissions, especially when you need to perform server-side validation or database operations.

2. Data Mutations

   When you need to update data on the server and immediately reflect those changes in the UI, Server Actions provide an efficient way to do this in a single round trip.

3. Authentication Operations

   For tasks like user log in, logout, or password resets, Server Actions can provide a secure and seamless way to handle these operations.

4. Real-time Data Updates

   When you need to fetch and display real-time data updates without full page reloads, Server Actions can be very effective.

5. Progressive Enhancement

   If you want your forms to work even when JavaScript is disabled or hasn't loaded yet, Server Actions support this out of the box.

6. Optimistic Updates

   For scenarios where you want to update the UI immediately while the server processes the request, Server Actions integrate well with React's concurrent features.

7. Complex Calculations

   When you need to perform resource-intensive calculations that are better suited for the server, Server Actions allow you to do this seamlessly.

8. Secure Operations

   For operations that require access to sensitive data or APIs that shouldn't be exposed to the client, Server Actions keep these secure on the server.

If you think about it, Server Actions offer many key benefits, such as improved performance by updating the server-side cache and React tree in one roundtrip, enhanced security by keeping sensitive operations on the server, reduced boilerplate by eliminating the need for separate API routes, and a better developer experience with streamlined server-side logic integration.

While they’re most likely just trying to clickbait you, there are some actual reasons why you should rethink using server actions in your app.

When not to use Server Actions

Let's explore when it might not be appropriate to use Server Actions

1. Public API Endpoints

   If you're building a public API that needs to be consumed by various clients (mobile or desktop applications) or third-party services, traditional API routes are more suitable. Server Actions are designed for internal use within your Next.js application.

2. Complex Authentication Flows

   For sophisticated authentication systems that require multiple steps or third-party integrations, traditional API routes or dedicated authentication services might offer more flexibility.

3. Long-Running Operations

   Server Actions are designed for quick, request-response cycles. For long-running tasks or background jobs (like CRON jobs or workflows), you might want to use a dedicated job queue or serverless functions with longer timeout limits.

4. Stateful Operations

   While Server Actions can work with server-side state, they're primarily designed for stateless operations. For complex stateful operations, you might need a different architecture.

5. Cross-Origin Requests

   If you need to handle CORS (Cross-Origin Resource Sharing) for requests from different domains, traditional API routes offer more control over headers and preflight requests.

6. Streaming Responses

   For scenarios requiring server-sent events or WebSocket connections, Server Actions are not suitable. You'd need to use specialized APIs or libraries for real-time communication.

7. File Uploads

   While it's possible to handle file uploads with Server Actions, for large files or complex upload scenarios, you might want more control over the upload process, which traditional API routes or specialized upload services can provide.

8. Separate Frontend and Backend Teams

   In organizations where frontend and backend development are strictly separated, traditional API development might align better with team structures and workflows.

Did you get that? Can you now tell in which apps or which specific features you will or will not use server actions?

Simple: Server Actions are ideal for apps that require real-time updates, secure operations, and frequent data mutations (e.g., e-commerce and financial apps). They’re also suited for complex server-side calculations.

However, they aren't suitable for public APIs, long-running tasks, video processing, chats, cross-origin requests, stateful operations, or large file uploads.

Always choose based on your specific requirements, not trending Twitter opinions.