Using Local API Operations with Server Functions

In Next.js, server functions (previously called server actions) are special functions that run exclusively on the server, enabling secure backend logic execution while being callable from the frontend. These functions bridge the gap between client and server, allowing frontend components to perform backend operations without exposing sensitive logic.

• Executing Backend Logic from the Frontend: The Local API is designed for server environments and cannot be directly accessed from client-side code. Server functions enable frontend components to trigger backend operations securely.
• Security Benefits: Instead of exposing a full REST or GraphQL API, server functions restrict access to only the necessary operations, reducing potential security risks.
• Performance Optimizations: Next.js handles server functions efficiently, offering benefits like caching, optimized database queries, and reduced network overhead compared to traditional API calls.
• Simplified Development Workflow: Rather than setting up full API routes with authentication and authorization checks, server functions allow for lightweight, direct execution of necessary operations.

Use server functions whenever you need to call Local API operations from the frontend. Since the Local API is only accessible from the backend, server functions act as a secure bridge, eliminating the need to expose additional API endpoints.

All Local API operations can be used within server functions, allowing you to interact with Payload's backend securely.

For a full list of available operations, see the Local API overview.

In the following examples, we'll cover some common use cases, including:

• Creating a document
• Updating a document
• Handling file uploads when creating or updating a document
• Authenticating a user

First, let's create our server function. Here are some key points for this process:

• Begin by adding 'use server' at the top of the file.
• You can still use utilities such as getPayload().
• Once the function structure is in place, call the Local API operation payload.create() and pass in the relevant data.
• It's good practice to wrap this in a try...catch block for error handling.
• Finally, make sure to return the created document (don't just run the operation).

Now, let's look at how to call the createPost function we just created from the frontend in a React component when a user clicks a button:

The key points from the previous example also apply here.

To update a document instead of creating one, you would use payload.update() with the relevant data and passing the document ID.

Here's how the server function would look:

Here is how you would call the updatePost function from a frontend React component:

In this example, we will check if a user is authenticated using Payload's authentication system. Here's how it works:

• First, we use the headers function from next/headers to retrieve the request headers.
• Next, we pass these headers to payload.auth() to fetch the user's authentication details.
• If the user is authenticated, their information is returned. If not, handle the unauthenticated case accordingly.

Here's the server function to authenticate a user:

Here's a basic example of how to call the authentication server function from the frontend to test it:

This example demonstrates how to write a server function that creates a document with a file upload. Here are the key steps:

• Pass two arguments: data for the document content and upload for the file
• Merge the upload file into the document data as the media field
• Use payload.create() to create a new post document with both the document data and file

Here is how you would use the server function we just created in a frontend component to allow users to submit a post along with a file upload:

• The user enters the post title and selects a file to upload.
• When the form is submitted, the handleSubmit function checks if a file has been chosen.
• If a file is selected, it passes both the title and the file to the createPostWithFile server function.
• And you are done!

Managing authentication with the Local API can be tricky as you have to handle cookies and tokens yourself, and there aren't built-in logout or refresh functions since these only modify cookies. To make this easier, we provide login, logout, and refresh as ready-to-use server functions. They take care of the underlying complexity so you don't have to.

Logs in a user by verifying credentials and setting the authentication cookie. This function allows login via username or email, depending on the collection auth configuration.

The login function needs your Payload config, which cannot be imported in a client component. To work around this, create a simple server function like the one below, and call it from your client.

Logs out the current user by clearing the authentication cookie and current sessions.

Similar to the login function, you now need to pass your Payload config to this function and this cannot be done in a client component. Use a helper server function as shown below. To ensure all sessions are cleared, set allSessions: true in the options, if you wish to logout but keep current sessions active, you can set this to false or leave it undefined.

Refreshes the authentication token and current session for the logged-in user.

As with login and logout, you need to pass your Payload config to this function. Create a helper server function like the one below. Passing the config directly to the client is not possible and will throw errors.

When using server functions, proper error handling is essential to prevent unhandled exceptions and provide meaningful feedback to the frontend.

• Wrap Local API calls in try/catch blocks to catch potential errors.
• Log errors on the server for debugging purposes.
• Return structured error responses instead of exposing raw errors to the frontend.

Example of good error handling:

Using server functions helps prevent direct exposure of Local API operations to the frontend, but additional security best practices should be followed:

• Restrict access: Ensure that sensitive actions (like user management) are only callable by authorized users.
• Avoid passing sensitive data: Do not return sensitive information such as user data, passwords, etc.
• Use authentication & authorization: Check user roles before performing actions.

Example of restricting access based on user role: