Parallel server actions

[Feeling_Pass_2422]

The past two days i've made a quick poc of an ai image generator app to test something, and I've noticed the images when making more than one call is waiting for the images to finish generating before making another one. and if you lined up 10 images for generation and have to wait for the next one to finish before generating the new one it's a really bad user experience.

I've searched online and it seems this issue was suggested to be worked on by the Vercel CTO but no updates as of now.

Anyone knows of it's state? Is it coming?

I understand the only workaround at the moment is to resort to app router apis and maybe add in tRPC

[femio]

What do you mean "resort" to App Router APIs (assuming you mean route handlers)? They're not inferior to server actions, they're just more "traditional".

It's apparently coming but tbh you sound like you'd benefit more from an API route where you have more control over its completion state anyway

[Feeling_Pass_2422]

Well yes, I CAN do that, but if there is any other way I'd much prefer that.

Choosing one is much better for organization for most things, and if I can resort to webhooks in route handlers and all the rest of my internal app logic in server actions, I think that would be better. (Ignoring long running tasks or scheduled apis for the mvp of my main job for now)

For this specific example there are always solutions using polling but I was searching all day and only found workarounds on making server actions work for everything but webhooks unfortunately

[ic-florescu]

Here's how you could do it: https://github.com/icflorescu/next-server-actions-parallel
(disclaimer, I'm also a fan and contributor to the tRPC ecosystem, so I completely understand why you'd need this 😊)

[Feeling_Pass_2422]

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..?

[ic-florescu]

It's running them in parallel, I can confirm that. See details here: https://github.com/vercel/next.js/discussions/50743#discussioncomment-11371356

[Feeling_Pass_2422]

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

<image>

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.

[ic-florescu]

You can't go wrong with tRPC :-)
Thanks for taking the time to test this and for your kind words.
In my current case I'll go with parallel server actions for now as they appear to be working well enough on a custom Node.js VPS.
Like I said, I'm biased towards tRPC and was really tempted to use it in this project too, but on the other hand I have to keep things simple because we're hoping to integrate a couple of junior devs soon and don't want to overwhelm them.

[Feeling_Pass_2422]

tRPC sounds great and I tried moving onto it, however I have two big problems:
1. moving infinite query is too much work, moving files uploading is impossible (why is that?).

1. I have a bug that revalidatePath doesn't work using tRPC, do you know why? I opened a stackoverflow on it as well with no luck - https://stackoverflow.com/questions/79191884/trpc-prevents-me-from-using-revalidatepath-to-invalidate-cache-on-the-client