App Router w/ a separate REST API? Does it even make sense?
Unanswered
Ocicat posted this in #help-forum
OcicatOP
Hi all,
Next.js 14 looks amazing to me for a standalone web app, but I'm a bit confused how it fits with products that have multiple interfaces besides just web (e.g. mobile app). All of the examples I see focus on calling the database directly in your server component / server actions, but -- if we have other platforms -- we need a central API to keep everything consistent.
Core question: Does it make sense to use the app router w/ server actions if the server action is basically forwarding this info to another external API?
Below are my concerns:
Data has to travel through more servers?
For the initial request, if we fetch some data via an external REST API in a server component and pass it down to client components, this isn't a cause for concern as this is basically how the pages router already worked. Ideally, the REST server and the Next.js server are close to each other.
However, the part that's confusing me is what happens when we need to fetch data from the client? Examples I've seen look something like this:
* Fetch initial data in server component using some server function (e.g. getPosts) and pass to client
* Set up react query (or something similar) in the client and initialize with the data from the server
* Refetch with react query using the same "getPosts" server function
Code example:
Notice, when react query needs to refetch, it will fetch using the "getPosts" server function. This means, the client will hit the next js server, then the next.js server will go and hit our API. This seems like far too much, but it's the best DX I've seen for initializing client query functions and keeping it in sync with how the server is processing data.
The same idea applies to basic server actions. Why should I be POSTing to the next.js server if it's just going to forward info over to my external API? This feels like it would be far too slow. I feel like I'm missing out on most of the great app router features becuase I'm using an external API, which begs the question:
Is Next.js App Router worth using if we need an external API (not using route handlers)?
Next.js 14 looks amazing to me for a standalone web app, but I'm a bit confused how it fits with products that have multiple interfaces besides just web (e.g. mobile app). All of the examples I see focus on calling the database directly in your server component / server actions, but -- if we have other platforms -- we need a central API to keep everything consistent.
Core question: Does it make sense to use the app router w/ server actions if the server action is basically forwarding this info to another external API?
Below are my concerns:
Data has to travel through more servers?
For the initial request, if we fetch some data via an external REST API in a server component and pass it down to client components, this isn't a cause for concern as this is basically how the pages router already worked. Ideally, the REST server and the Next.js server are close to each other.
However, the part that's confusing me is what happens when we need to fetch data from the client? Examples I've seen look something like this:
* Fetch initial data in server component using some server function (e.g. getPosts) and pass to client
* Set up react query (or something similar) in the client and initialize with the data from the server
* Refetch with react query using the same "getPosts" server function
Code example:
// File: server-code.ts
"use server"
export async function getPosts() {
// make some fetch request here to the external API and return the data.
}
// File: page.tsx
export default async function HomePage() {
const posts = await getPosts();
return <PostsView posts={posts} />
}
// File: posts-view
"use client"
export default async function PostsView {
const {data, isLoading, refetch} = useQuery({
queryKey: ["posts"],
queryFn: () => getPosts(), // NOTICE THIS IS THE SERVER FUNCTION
}Notice, when react query needs to refetch, it will fetch using the "getPosts" server function. This means, the client will hit the next js server, then the next.js server will go and hit our API. This seems like far too much, but it's the best DX I've seen for initializing client query functions and keeping it in sync with how the server is processing data.
The same idea applies to basic server actions. Why should I be POSTing to the next.js server if it's just going to forward info over to my external API? This feels like it would be far too slow. I feel like I'm missing out on most of the great app router features becuase I'm using an external API, which begs the question:
Is Next.js App Router worth using if we need an external API (not using route handlers)?
19 Replies
Standard Chinchilla
You could put your external api in react query. That would theoretically be faster as you are not using next.js as a middle man. Howevery you may want to use next.js for authentication about the user
OcicatOP
Yes, agreed. Was thinking that any client side queries should just go to the external API instead of going through next.js, but what about server actions?
So much of next seems to be focused on server actions now, and they don't seem to be a good fit if you have to hit another API
So much of next seems to be focused on server actions now, and they don't seem to be a good fit if you have to hit another API
Standard Chinchilla
server actions are great for things such as authentication and it's a better user experience. Instead of having to make an api call using the fetch api you can use server actions
OcicatOP
I think server actions are far more integrated into the data flow though from server components though. For example, calling revalidate() in the server action automatically invalidates the data from the corresponding server components.
I don't get these benefits if I reach out to my API directly
I don't get these benefits if I reach out to my API directly
But going through server actions isn't as performant because the request will go client -> next.js server (server action) -> my API server
Standard Chinchilla
Yes that is true
It depends on your needs
OcicatOP
I think my issue is that server actions seem like such a vital part of the app router flow
And they don't make sense if you have an external API (i.e. most companies that are actually large)
Standard Chinchilla
It really isn't though. You don't have to use server components if you don't want to
OcicatOP
True
Standard Chinchilla
You can use the fetch api like in traditional react apps
OcicatOP
Lots of pros to server components though that I would like to utilize, but revalidating that info seems a bit more tedious without server actions
Standard Chinchilla
But at least now you have the option to use server componets which in my opinion is a better developer experience
OcicatOP
Agreed
I think my main question is: did next.js need to tie this all into server actions or was it possible to work on this data revalidation strategy without them?
The next team is smart, so I'm sure they have some valid solution to this that makes sense where I can still utilize all the great features of server components, but just not seeing anything about it
If it's really not possible with an external API that seems like a major oversight, as most companies become large enough to need multiple interfaces besides their web app
Standard Chinchilla
esentially a server action just wraps the fetch api around a function in the server. If you want to access someone else's server (like hitting an external server) then you would have to just use the fetch api in the client component