Most slow pages aren't slow because of one bad API. They're slow because the calls were put in a line, and everyone waits for their turn.
Take a product page that needs customer reviews, recently purchased items, and a "you may also like" list. Three endpoints, the same SKU ID, the same API key, and one clean response at the end. Nothing about that needs to be a queue.
The easy version is slow
The obvious way to build this is one call after another. Call reviews, wait. Call recent purchases, wait. Call recommendations, wait. Merge the results. It's simple, and it works.
The trouble is the waiting. Imagine the three calls take 200, 300 and 250 milliseconds. In a line, the page waits 750 milliseconds. Nothing is wrong with any single call, but the total keeps growing with every service you add.
Run them together
None of those calls needs the answer from another. Reviews don't depend on recommendations. So they can all start at once, and the page waits only for the slowest one. With the same numbers, that's about 300 milliseconds instead of 750.
One rule decides whether this works: the calls have to be independent. If the second call needs data from the first, it has to wait. When they don't depend on each other, running them in parallel is free speed.
What the rest of the job looks like
Speed is only part of it. A good aggregation also needs:
- The same SKU ID passed into all three calls, without copying it three times by hand
- The API key kept out of your code, in a secrets store
- A final step that merges the three responses into one shape, such as reviews, recent and youMayAlsoLike
- A decision about failure: if one call fails, do you return an error, or return the other two?
That last one is easy to forget. Decide it up front, not after the first outage.
How we build it in Unmeshed
In Unmeshed, each call is an HTTP step. The SKU ID comes from the flow's input, and the key comes from a stored secret, so nothing sensitive lives in the flow itself. A small JavaScript step takes the three outputs and puts them into the final response.
At first the three steps run one after another. To switch to parallel, you add a Parallel step and drag the three calls into it. No backend changes are needed, because the services don't know or care how they're being called. After that, a visual timeline shows where the time goes, so you can see which call is the slowest one holding everything back.
If you're gluing several APIs together by hand today, try Unmeshed on a flow like this one. It's a small example, but the pattern of defining the calls, merging the output, and running independent work in parallel carries over to much bigger ones.
Top comments (0)