Next.js as a client API choice

Having watched all theo's videos regarding next and APIs (mainly tRPC and server actions), i got the grasp of understanding of the stack and the decisions if a full-stack app should be built. However, let's imagine that there's a need of using next.js purely as a client solution, meaning there's already some api (be it graphql or rest) with other clients like mobile etc. What should be done in this case? As far as I understand, all the featurse like server actions with blazingly fast revalidation (revalidePath) or tRPC won't work. Should RSC be used in this case with simple fetch calls to the api, or it will be better to use next.js api as BFF with tRPC/server actions?
Solution:
basically your server actions and query functions would act as thin wrappers around calls to the separate api, which allows you to use all the bleeding edge features like revalidatePath/revalidateTag
Jump to solution
9 Replies
michaeldrotar
michaeldrotar3mo ago
if you want to go purely client-side, you can use hooks like useQuery (TanStack) or useSWR (Vercel) You lost me at the end though. If you're using RSC then you're not purely client-side. Maybe you're asking about a proxy? Those can be helpful to keep auth secure but if they're not locked down properly then they're just a middle-man wasting resources.
hellyeah
hellyeah3mo ago
Well, "client solution" means simply UI. So yes, i want to leverage all the server components stuff, but the api is already there, so some features just can't be used.
Pepperz
Pepperz3mo ago
Seems like a reasonable approach to me.
hellyeah
hellyeah3mo ago
@Pepperz which one? Basically i see 2 ways of doing this: 1) ui uses a server action, which uses fetch and calls the real api, then triggers revalidatePath or whatever 2) ui directly uses fetch in a client component with manual refetching (be it fetch or router.reload) both options seems to work i guess, just trying to grasp cons and pros
Bohdan
Bohdan3mo ago
I actually think all of the nextjs features can be used, with the only difference to owning the business logic being that in the server directory you would just proxy requests to that separate api instead of implementing the logic yourself
Solution
Bohdan
Bohdan3mo ago
basically your server actions and query functions would act as thin wrappers around calls to the separate api, which allows you to use all the bleeding edge features like revalidatePath/revalidateTag
Bohdan
Bohdan3mo ago
(btw also look into unstable_cache, it was the missing puzzle piece to me and it all clicked after I learned about it)
Pepperz
Pepperz2mo ago
To add on to Bohdan, if you are using Next features like RSC, you would be able to fetch from server as it comes in as opposed to when the client loads and you will have more control over the distance your request travel. How much that plays an effect on performance in your case is hard to say.
No description
Bohdan
Bohdan2mo ago
you'd even be able to reduce the load on the main backend with nextjs caching