Scenario (Reactive Web):
I need to call a REST GET API 69 times (one per ID) and append results to a list shown on the screen. After the GETs, I must call a REST POST API 69 times (one per ID) to create requests on an external system. The external API doesn’t support bulk payloads, only single-request parameters.
Current behavior:
GET loop (For Each) → UI reflects all data in ~30 seconds.
POST loop (For Each) → 69 creates take ~3 minutes.
Goal:
Show the GET data in a few seconds (ideally <5s).
Kick off the POST creates without blocking the UI (finish later, with progress), or complete significantly faster if possible.
Any suggestion/recommendation much appreciated.
A bit of math:
70 requests at 1 second each, means 70 seconds. If you are doing half of that, it is great. The back and forth is the main issue. The client shouldn't be the one doing the connection.
This is a common scenario and you will see many suggestions. The simplest one:
I would send all the Ids to the server and process them there.
The client would refresh the list every second to read what the server has, but not directly waiting for the service.
The POST is a bit slower, so you can have a BPT processing each completed GET and making the corresponding POST. They are independent.
I think it is the same approach that I recommend, to save the process data on server and let server do it asynchronously by timer / BPT
Yes, but timers always take a few seconds to start, so the 5 seconds goal would be impossible. GET on server action, POST on BPT is the fastest for this scenario.
With different amounts I would ignore the users wishes and move it to a timer for sure. If this is a 30 seconds run, it can be in the server action.
In this situation, limitation from external API side. You can consider the background asynchronous approach, which means that
Hope this workaround help
Hi @Shingo Lam , @Nuno Reis ,
Thanks for the suggestions! I implemented a similar pattern: I store request creation details in a single entity and trigger a background process on entity creation. The UI renders the GET results quickly, and the POSTs run asynchronously in parallel with controlled concurrency and retries. This decoupling improved responsiveness and reduced overall time, while progress and error states are visible in the UI. Appreciate the pointers that helped shape this solution!
Great to hear that you can solve your issue