How to do parallel server action calls? My server actions get executed sequentially

[aaronvg]

Summary

I need to send like 20 requests, one at a time using a server action. Any ideas on how to do this in parallel? I want to keep track of each request on a client-side component using the useTransition / isPending flag.

Additional information

No response

Example

No response

[pingustar]

I am interested in this as well

[chungnq253]

I am interested in this as well!!!

[VaDominikKienzler]

Please help

[Dog-Egg]

I'd like to know too.

[dlibis]

this guy has an answer: https://www.youtube.com/watch?v=CDZg3maL9q0

[mitchheddles]

This will work for a small number of requests, but it's not a bulletproof solution.

[jeroen-ultra]

This worked for me.

@mitchheddles Can you explain how what happens under the hood when you do this affects the limits for this solution?

[icflorescu]

Or this: https://github.com/icflorescu/next-server-actions-parallel 😊

[jordanpurinton]

Would love to see this functionality

[enricoros]

Agree, could definitely be a flag in next.config.js

[gmchad]

this guy has an answer: https://www.youtube.com/watch?v=CDZg3maL9q0

This works locally but in production (hosted on vercel) the requests are still sequential.

[nicnocquee]

weird, i tried this but still sequential even in dev local.

[yonatanlavy]

Please add this

[ZoranRavic]

Creating 20 parallel requests is a bad idea when using serverless functions, since they will likely all encounter cold starts.

Not to mention that it wont work if you have any noticeable number of concurrent users, due to the limit of 1000 active functions at the time.

Your best bet is to rewrite this as a single action.

If you really need to get responses for individual operations as soon as they are done then serverless functions simply aren't a good choice.
You'll have to setup a normal server or several servers with a load balancer.

[TanGrumser]

Give me the chance to do stupid decisions myself.

[aretrace]

@TanGrumser 🫡

[JeroenvdV]

I'm not sure I agree with the cold starts problem. A sudden burst of calls could all encounter cold starts (as with a single one) if the function is not continuously used, but they also might not if there are regularly a similar amount of concurrent calls.

I also don't really understand how "serverless functions simply aren't a good choice". I mean, yeah now they aren't for this, as concurrency is not supported, but I don't think there's anything about serverless as an execution model itself that goes against concurrent calls of the same or even different functions. Is this just a chicken and egg thing?

[ZoranRavic]

My assumption is that the thing you're primarily doing on the server side is reading from and writing to the database.

In this scenario the bulk of the load is on the database servers, with your server(less) functions mostly just waiting for responses. And if you are on a cheaper database plan, those responses are going to come in slower, since cheap db servers get slower when processing a lot of requests at the exact same time.

You can greatly reduce the load on the database by refactoring your 20 (or however many) requests to be a single api call which would allow you to avoiding duplicate database calls and performing bulk read/write operations, which can be executed more efficiently on the database side than many smaller operations.
This also greatly reduces your vercel bill, as you are only paying for one function call, instead of 20.

Now that we have a more efficient api we have to find a way to return responses for individual sub-functions as soon as they are done.
Sadly this can not be done with serverless functions and we have to go back to normal servers.

---

Same logic would apply if you are interacting with third-party apis, for example an api for sending emails or sms messages, since in those cases your function is again just waiting to see if the third-party api returns a 200 OK response.

---

And even in the case you don't care about optimizing your database calls and you are actually interesting in computing on 20 CPU cores you are still better off with a regular server since if you need a lot of compute time then vercel bill is going to put you out of business.

[DiAifU]

I'm actually wondering why server actions work like that too ?
I'm currently seeing some of my client-side queries finishing one after the other instead of coming all as fast as possible and I thought server actions would trigger them in parallel and display the results in the browser as soon as it is available.

Why is it implemented like this ? Is it likely to change or should I implement my requests differently ?

[aretrace]

See this last item from the react docs, I have yet to see an explanation from the react team as to why they behave this way (I'm sure it's some technical thing due to how react itself it implemented).

[ZoranRavic]

The react docs only say that "frameworks implementing Server Actions typically process one action at a time"

Meaning that this is something the frameworks (notably next.js) decided to do and it's not something that is necessary for react to function properly.

I don't see where did you get your conclusion that react itself couldn't handle parallel action calls.

[aretrace]

See this last item from the react docs, I have yet to see an explanation from the react vercel team as to why they behave this way (I'm sure guessing it's some technical thing due to how react next.js itself it implemented).

[nikshepsvn]

This is such a huge gripe when using server-actions, please fix

[icflorescu]

Actually, this is quite easy to do with icflorescu/next-server-actions-parallel, if you're looking for a ready-made solution.
Have a look at the repo, the idea simple enough that you can simply copy-paste it in your own projects if you don't want to add it as a dependency.

[yonatanlavy]

Is this parallelizing or running sequentially faster, but still waiting for an 'ok' from each one?
From my testing it takes a tiny bit more for this to run on server actions than on routes, so it might still not solve the base problem of actually serializing and on high network latencies will cause huge delays.

Will this work on all environments?

Will this work with existing error handling and payloads including forms, files, components, etc..?

[icflorescu]

It's definitely running the actions in parallel, not sequentially, so it's not waiting for an 'ok' from each one, that I can say for sure.

I'm currently using this approach in an average-size project running on Node.js, in the following scenario:

I've build a number of self-contained select components that pre-fetch data asynchronously with server actions when they get mounted. I know some people would say this is an API routes use-case, but since I'm coming from a tRPC background (being a contributor to the ecosystem and the author of tRPC-SvelteKit), I wasn't exactly keen on building lots of REST API endpoints for that. So naturally I looked at server-actions as a boilerplate-free alternative to tRPC.
But to my surprise and initial disappointment, I realized those requests were batched and therefore executed inefficiently during the first load. A bit of tinkering around led me to the aforementioned solution, and here's the result:

I've introduced and artificial 5 seconds delay to better illustrate the case and as you can see, the requests are indeed executed in parallel and not sequentially.
Yes, there's a slight delay (milliseconds, and it won't get multiplied with the number of actual requests) compared to calling REST API routes, but I'm perfectly OK with a few milliseconds trade-off if it spares me the effort of creating and maintaining some REST routes which make no sense outside the context of my front-end application.

Not to mention the huge advantage of being able to co-locate the loading logic with the actual components like so:

And here's how I'm actually using the server actions in components:

In fact, if you ask me, this would be a perfect common real-life example scenario of why we need to be able to call multiple server actions in parallel.

Projects like tRPC.io or Telefunc were built for solid reasons, and when I first saw Next.js server actions, I immediately thought "here's how we can do all that without the boilerplate". Being able to call them concurrently was, until now, the missing piece.

To answer your other questions, my main concern at the moment is to be able to apply this in a self-hosted Node.js environment.
There's no reason why this shouldn't work on Vercel or other environments, but I haven't tested it yet, so I'd be grateful if you or somebody else directly interested would help with that 😉

[yonatanlavy]

your help is here!
ran it in: https://github.com/yehonatanyosefi/test-parallel-actions
locally and on vercel
when on vercel, and simulated 3g network connection this is the difference:
timeRanAction: 4092
timeRanRoute: 2070

so takes twice as much to do the roundtrip with 2 actions that take 1 second each, rather than 2 routes that take 1 second each (using 3g network throttling).
it's enough for me to never use this.
cool idea though! will definitely keep this in mind if I have more leftover functions that I have to run and haven't yet converted to trpc/api routes.

[icflorescu]

Thanks a lot for taking the time, @yehonatanyosefi!

Meanwhile I played around and added a few scenarios in the repo test app and indeed I can see differences depending on where you're running:

Here's on Vercel:

Here's on a StackBlitz instance:

Here's on a local Node.js environment:

TBH, I would have expected it to perform better on Vercel.
But in my case - running on a custom VPS - there's just a few milliseconds trade-off (vs simple API routes) and I'm more than ok with that.

[omgcx1222]

Actually, this is quite easy to do with icflorescu/next-server-actions-parallel, if you're looking for a ready-made solution. Have a look at the repo, the idea simple enough that you can simply copy-paste it in your own projects if you don't want to add it as a dependency.

This library is great, it solved my problem perfectly, it successfully changed my server actions from sequential to parallel

But I saw

In a nutshell: a lot faster than default Next.js server actions, not as fast as REST API routes.
Check it in your specific deployment environment and decide if it makes sense for your project.

on https://github.com/icflorescu/next-server-actions-parallel?tab=readme-ov-file#how-does-it-perform
In the actual code I need to change sleep to fetch REST API，Is there anything wrong with my implementation?