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:Jump to 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
9 Replies
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.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.
Seems like a reasonable approach to me.
@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
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
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
(btw also look into unstable_cache, it was the missing puzzle piece to me and it all clicked after I learned about it)
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.
you'd even be able to reduce the load on the main backend with nextjs caching