Merging many backend calls into one response is easy. Deciding what belongs in the same response — and so the same cache — is the real work.
"Make one call from the frontend, and let the middleware call everything else." It's one of the most reasonable things a frontend architect can ask for — fewer round trips, smaller payloads, less disambiguation in the browser. And the answer is unambiguous: yes. The Alokai Middleware is a BFF; fanning out to several backends and returning a single, shaped response is a few lines in a custom method.
So why doesn't a careful engineer just say "yes, do that" and move on?
Because "one call" describes the client. It says nothing about what happens to caching on the server — and the moment you merge several sources into one response, you merge their cache policies too. Federation and caching aren't two topics. They're the same decision seen from two sides.
This piece is about that coupling: why combining calls is trivial in theory and nuanced in practice, and how to tell, for any given pair of calls, which one you're looking at.
Let's get this out of the way, because it's true and it matters: the orchestration capability is there, it's first-class, and it does exactly what a BFF should. A custom middleware method can call any number of backends server-to-server — never leaving the network — chain or parallelize them, shape the result, and hand the browser a single payload.
And it really is a few lines. A custom middleware method receives a context, calls whatever backends it needs server-to-server, and returns one shaped payload:
// storefront-middleware/api/custom-methods/getProductBundle.ts
export async function getProductBundle(context, { sku }) {
const commerce = await context.getApiClient('commerce');
const reviews = await context.getApiClient('reviews');
// call both backends server-side, then return a single response
const [product, productReviews] = await Promise.all([
commerce.api.getProduct({ sku }),
reviews.api.list({ sku }),
]);
return { product, reviews: productReviews.items };
}Illustrative — register it as a custom method and the frontend gets a typed, single-call SDK endpoint for it.
The benefit is genuine. A chatty page that would otherwise fire a handful of requests from the browser — each with its own latency, its own payload, its own waterfall risk — becomes one request to one endpoint that returns exactly the shape the page needs. Nobody disputes that this is useful, or that the platform supports it. So the interesting question was never can you. It's should you, for these particular calls.
Here's the whole article in a sentence: a merged response is a single cache object — one key, one policy, one fate. Everything you fold into it now shares one TTL, one cache-key cardinality, one invalidation trigger, and one failure domain. That's not a downside, exactly. It's just the thing you're signing up for, and it's worth signing up for on purpose.
When the calls stay separate, each response gets to be cached on its own terms — the CMS content at the edge for minutes, the product behind its own cache, search not cached at all. Merge them, and all of that collapses into the properties of the most demanding ingredient. The rest of this page is just the four ways that collapse shows up.
A cache entry can only be as fresh as its most volatile field. Fold slow-changing CMS content together with fast-changing stock, and the whole blob is only cacheable for as long as the stock is valid. You've taken content that could have sat warm at the edge for minutes and capped it at seconds.
The companion piece frames cacheability as cache-key cardinality: anonymous content is one key, a segment is N keys, per-user is one key per visitor. Merging respects the worst case. Combine three shared ingredients with one per-user one — a customer-specific contract price, say — and the entire merged response becomes per-user. It can no longer be shared-cached at all, even though three-quarters of it is identical for everyone.
Kept separate, each source is invalidated by its own trigger: the CMS purges on publish, the catalog on a price change, search on re-index. Each is a precise, tagged purge of exactly what changed. Merge them and there's one key holding all of it — so any change to any ingredient means purging the whole entry, and you lose the surgical, tag-based invalidation that made the cache cheap to keep fresh in the first place.
Independent calls fail independently: the CMS being down doesn't take products with it, and the page can degrade gracefully. A single merged endpoint is one failure domain — if one upstream times out, the whole response is in question — unless you explicitly write partial-failure handling for every ingredient. That's doable, and sometimes worth it, but it's real work that the "just merge them" framing quietly hides.
It's worth seeing the contrast directly, because "fewer client calls" is a real win and "worse cacheability" is a real cost, and the right answer depends on which one dominates for a given page.
The latency article showed the fetch-ordering side of this — why fetching the CMS before commerce is a waterfall. This is the caching side of the same coin: merging trades the browser's round trips for the server's cache granularity. Neither column is free.
This isn't an argument against orchestration — it's an argument for doing it where it pays. There are clear cases where the BFF is precisely the right place to merge:
The cleanest case is the genuine dependency. A search index hands back a list of SKUs but not the full product data your tiles need; the only way to render them is to take that list and fetch the products — call B literally consumes call A's output. You wouldn't want the browser doing search-then-a-dozen-product-calls, so the chain belongs server-side. That's the BFF earning its keep.
It's worth retiring one example that often gets used here: the PDP that merges product data with stock from a separate inventory system. It feels like the poster child for orchestration, but it's neither a dependency nor a clean merge. You already have the SKU from the route, so product and stock are independent, parallel calls — not a chain. And their cache profiles clash: product is stable, stock is volatile. So the honest move, straight from the TTL coupling above, is usually to cache the product and fetch stock late or on a short TTL — not fuse them into one cached response. It's a keep-them-separate case dressed up as a merge — a good reminder that "they render together" is not the same as "they belong in the same cache entry."
Let's consider another scenario. On a single PLP screen: Coveo returns the search results; the third slot in the grid is a CMS content block instead of a product; and every product tile shows a live in-stock count from the commerce backend. Three sources, one screen. The natural question is "can the middleware just orchestrate all three into one response?" — and the reason that doesn't get a reflexive yes is that those three ingredients have three different cache lives.
Fuse all three into one PLP endpoint and the response inherits the worst of each: it's keyed per query and filter set (from search), capped at seconds (from stock), can't be purged precisely when marketing edits the slot (it's buried in a per-query blob), and goes dark entirely if Coveo hiccups — taking the static promo and the product grid down with it. The merge didn't reduce the problem; it pooled four of them.
The composition that respects each ingredient's cache life looks like this:
| Ingredient | Its cache life | What to do with it |
|---|---|---|
| Coveo search results | Per-query, per-filter, often personalized ranking — high cardinality, barely shareable. | Take it on its own terms — direct from the client, or via middleware — cached briefly per query at most. (This is also why "go straight to Coveo" can be the right call for search.) |
| CMS block in slot 3 | Shared, changes a few times a week — long-lived, tag-invalidated. | It doesn't depend on the search results — its slot is a layout rule, its content is merchandising. Resolve it from the category/CMS layout, cache it independently, and compose it into position 3. Don't route it through search. |
| Live stock per tile | Changes by the second — the most volatile thing on the page. | Fetch it late (client-side, after the grid renders), or merge it server-side but on a very short TTL. Never bake live counts into a long-cached grid — that's how you show "in stock" on a sold-out item. |
Notice what this doesn't do: it doesn't refuse to use the BFF. You still cut the round trips worth cutting — product plus stock can be a single short-lived server response, for instance. It just declines to fuse the independently-cacheable CMS slot or to pretend search is shared-cacheable. Each piece keeps the cache life it wants. That's the precise answer the example deserves — and why it takes a paragraph instead of a word.
Often the cleanest answer to "how do I avoid N client calls?" isn't a runtime merge at all — it's shaping the data so the merge was never needed.
If a content page needs specific products, put the SKUs in the CMS payload. Now one call to the CMS already tells the page what to fetch — there's no runtime chain of "call SAP, then call the CMS" to orchestrate, and each source still caches on its own terms. The dependency is resolved in the content model instead of in a request.
Keep the calls separate, let each cache at its optimal layer and TTL, and compose them on the page. You spend a little more coordination to keep the cheap, independent caching the merge would have thrown away.
The most cache-friendly storefront is a stable, shared shell with a few volatile or per-user holes punched in it — stock, cart, customer pricing — fetched separately after load. The shell caches hard; the holes never touch the shared cache. (This is the same "don't federate per-user data into the cached page" rule from the caching piece.)
Before you fold two calls into one, the useful question is never "can the BFF merge these?" — it always can. It's "do these belong in the same cache entry?" Which comes down to whether they agree on four things:
| Do the calls share… | ✅ Merge freely if | ⚠️ Keep separate if |
|---|---|---|
| Volatility (TTL) | They change on similar timescales. | One is content-stable, another is stock/price-volatile. |
| Cardinality | All shared, or all the same segment. | Any ingredient is per-user / per-customer. |
| Invalidation trigger | They go stale on the same event. | Each has its own publish/re-index/price event you'd want to purge precisely. |
| Failure tolerance | All-or-nothing is acceptable for the page. | One source should degrade gracefully without the others. |
Four "merge freely" and it's an easy yes — combine them and enjoy the round-trip savings. A genuine dependency is also an easy yes regardless, because the chain has to live somewhere. But a single "keep separate" is the moment a precise answer takes longer than "sure, merge them" — not because the platform can't, but because the merge would quietly hand a property of the worst ingredient to all the others.
Built on the Alokai Middleware. The capability is the easy part — it's there, it's first-class, and the example above is a few lines of code. The judgment is the rest. Pair this with Data Federation Tradeoffs for the caching model it leans on.