Is it best practice to do client side fetching (no data mutation) with server action?

[Michahide]

Summary

I have a use case where I need to do some client-side data fetching using TanStack Query — for example:

• Infinite queries (pagination)
• Async options for a select component (e.g. using react-select-async-paginate)

The issue is:
My backend API requires an access token that is only available on the server side (e.g., retrieved via auth() from auth.js).
To work around this, I’ve been using a trick: placing 'use server' at the top of a function inside my Data Access Layer (DAL), which allows me to get the token from the server, then pass it to the client.

However, I noticed in the docs that Server Actions are intended for mutations, and it doesn't mention anything about using them just to fetch data.

My questions:

1. Is it still safe and acceptable (best practice) to use 'use server' just to fetch data (to retrieve tokens, etc)?
2. Are there better alternatives to support this pattern — especially ones that allow parallel fetches?

Thanks in advance!

Additional information

dal/getSomeData.ts

'use server';

import 'server-only';
import type { ResponseType } from '@/types/response/ResponseType';
import { responseHandler } from '@/lib/ResponseHandler';
import { getAccessToken } from '@/lib/getAccessToken';

export async function getSomeData(
  userId: number,
  page?: string | number,
  perPage?: string | number,
  queryString?: string,
) {
  const token = await getAccessToken();
  const queryParams = new URLSearchParams({
    userId: userId.toString(),
  });
  if (page) queryParams.append('page', page.toString());
  if (perPage) queryParams.append('per_page', perPage.toString());
  if (queryString) {
    const [key, value] = queryString.split('=');
    if (key && value) {
      queryParams.append(key, value);
    }
  }

  const response = await fetch(
    `https://www.example.com?${queryParams.toString()}`,
    {
      method: 'GET',
      headers: {
        Authorization: token ? `Bearer ${token}` : '',
        'Content-Type': 'application/json',
      },
    },
  );

  const transformedResponse = (await responseHandler(
    response,
  )) as ResponseType<SomeData>;

  return transformedResponse;
}

hooks/useInfiniteGetSomeData.ts

'use client';

import { useInfiniteQuery } from '@tanstack/react-query';
import { getSomeData } from '../GetSomeData';

export default function useInfiniteGetSomeData(userId: number) {
  const dataInfiniteQuery = useInfiniteQuery({
    queryKey: ['some_data', userId],
    queryFn: async ({ pageParam }) => getSomeData(userId, pageParam),
    initialPageParam: 0,
    getNextPageParam: (lastPage) => {
      if ('pagination' in lastPage && lastPage.pagination) {
        if (
          lastPage.pagination.meta.current_page <
          lastPage.pagination.meta.last_page
        ) {
          return (lastPage.pagination?.meta.current_page ?? 0) + 1;
        }
      }
      return undefined;
    },
  });

  return dataInfiniteQuery;
}

Example

No response

[icyJoseph]

The React docs talk about this, https://react.dev/reference/rsc/use-server:

Server Functions are designed for mutations that update server-side state; they are not recommended for data fetching. Accordingly, frameworks implementing Server Functions typically process one action at a time and do not have a way to cache the return value.

And while, it is just fine, like, clearly it works for you, it is not necessarily ideal.

You could make a Route Handler, that does this. One could argue, that the route would be publicly reachable, but so is your data when used, let's say, through react-query. You probably want to still limit access to same origin and such in your Route Handler though.

Also, that these are processed in a queue is probably not ideal. Like, if you have many server actions queued, and your fetching data action is enqueued, it'd have to wait for its turn.

I guess, you could move into a pattern where each page is a url search param, like /?page=10 or so, and then you could move everything to server components, but that's not always the case.