Server Actions vs "traditional" API - Which to use and when?
Unanswered
Manx posted this in #help-forum
ManxOP
As the title suggests, I'm a bit confused regarding the usage of Server Actions (that now with v14 are stable and are part of the documentation which I'm following currently) and defining traditional API endpoints that are triggered trough HTTP requests.
- When should I use server actions, and when API endpoints?
- Are they a replacement for API endpoints?
- Are they the "new" way for interacting with our databases and other backend services?
- Can I use, and if so, should I, use both server actions and API endpoints?
As it stands (from a NextJS newcomer perspective that has been interacting with API endpoints called from any client), if I'm building only for the web, Server Actions seem like the best solution to be used?
But then again, what am I missing? Its not like sever actions will make the API endpoints obsolete... is it?
- When should I use server actions, and when API endpoints?
- Are they a replacement for API endpoints?
- Are they the "new" way for interacting with our databases and other backend services?
- Can I use, and if so, should I, use both server actions and API endpoints?
As it stands (from a NextJS newcomer perspective that has been interacting with API endpoints called from any client), if I'm building only for the web, Server Actions seem like the best solution to be used?
But then again, what am I missing? Its not like sever actions will make the API endpoints obsolete... is it?
23 Replies
From my understanding they are the same except for the url... they are both public accessible but server actions are designed to be used with just your website where as "traditional" API can be used for 3rd parties... You can use both, and I am currently planning on implementing both by using shared code for both "endpoints"...
server actions also have a few more cool features such as redirect (returns the new page so less network reqs), another feature is you don't need to worry about working out the url as it will be made for you + typing of responses are there
TLDR: they are a cool thing that dynamically makes the url (with cool extra features) but for intensive purposes they are the same and isn't trying to replace
server actions also have a few more cool features such as redirect (returns the new page so less network reqs), another feature is you don't need to worry about working out the url as it will be made for you + typing of responses are there
TLDR: they are a cool thing that dynamically makes the url (with cool extra features) but for intensive purposes they are the same and isn't trying to replace
Also caching is easier since with apis to refresh the current page you need to router.refresh if you use revalidatePath
But with server actions the page instantly refreshes without using router.refresh
But with server actions the page instantly refreshes without using router.refresh
Blue horntail woodwasp
In my opinion, the cool thing about server action is when we have to send a request to third party api (in my case I use another backend as a services), your backend request is always hidden.
it will not shown even their check on network.
So, our backend url more secure.
it will not shown even their check on network.
So, our backend url more secure.
The flow is : Frontend -> Server Action -> Your Backend -> Server Action -> Frontend
cmiiw
@Blue horntail woodwasp In my opinion, the cool thing about server action is when we have to send a request to third party api (in my case I use another backend as a services), your backend request is always hidden.
it will not shown even their check on network.
So, our backend url more secure.
well for all incentive purposes they are the same security (server actions and route handlers)
Blue horntail woodwasp
So what he mean by "traditional" API is using
/api/ route in NextJS?yeah at least that is the most logical conclusion with discussing server actions (most that i have helped with) - and looking in OP's message it kinda seems to be refering to them
Blue horntail woodwasp
Okay I have miss undestand tho haha. I though what he mean as "traditional" API is using fetch on client component with frontend libraries such as axios etc.
well yeah they would have to use one of those
but id assume request to their own server
Blue horntail woodwasp
maybe we should choose just one for consistency? either Server Action or Route API
no... they are kinda not solving the same thing... there are times where generic api is better (ie for 3rd party or some libs) and only using server action will cause you extra pain that isn't with it
i was also saying that you can use both at the same time (if you really need)
Blue horntail woodwasp
maybe use server action just for
action purpose only 😄Im sorry, I am really new on NextJS
and there are a lot to learn 😄
yeah its fine, i just don't want to make OP think he has to use it but instead see how it can be useful for certain workflows
and im still learning too, so feel free to correct me if i am wrong
most of my learning was because i started helping here
Barbary Lion
]
ManxOP
Thanks a lot for making it clearer. Yea, as I assumed, using API endpoints would be a must if we want to use the exact same API for both our website and mobile app for example, but if we're just using the API on our website, then it seems like server actions are totally fine (after all, they are more or less the same thing).
@Blue horntail woodwasp So what he mean by "traditional" API is using `/api/` route in NextJS?
ManxOP
Yes, by "traditional" API (couldn't think of a better term at the time) I was indeed referring to the route handlers (or API endpoints) that we'd define in
Those would be the same ones as if we'd have dedicated NodeJS, PHP etc. server.
/api/ folders in NextJS.Those would be the same ones as if we'd have dedicated NodeJS, PHP etc. server.