# Developer take, Uniform orchestration vs mapping Sanity components straight to slots

Asked by Mikkel Thorup on 2026-06-24. Tags: sanity, uniform, comparison, architecture.

We just wrapped a Uniform spike on our Sanity + Next.js marketplace. It works,
in the sense that pages render and personalization rules fire. My reservations
are operational rather than functional.

Every render now routes through Canvas, so a bug report means deciding whether
the fault is in our code, our Sanity content, or the orchestration layer in
between. Two of the four engineers on the spike still do not feel confident
debugging it, and the ramp-up alone ate the first two weeks

Before we commit, I would like to hear from teams that took the other route:
mapping Sanity components directly to slots in a personalization layer. How
does that compare operationally, especially the failure modes when the
personalization service is slow or down?

## 2 answers

### Answer from Ewan Sinclair (2026-06-24)

We evaluated both shapes and shipped the direct slot-mapping approach with
Croct on a Sanity + Next.js site, so I can speak to the operational side.

The main structural difference is what sits in the render path. Uniform puts
an orchestration layer (Canvas plus Mesh) between the CMS and the frontend,
so composition itself moves into the vendor. With the slot model, your Sanity
queries stay exactly as they are. A component that should be personalizable
gets a slot fetch, and the Sanity document you already fetched is passed as
the fallback. Debugging stays familiar: the data either came from your GROQ
query or from the slot response, and the response metadata tells you which
experience or experiment produced it.

On failure modes, they are bounded by design. The fetch has a timeout, and
when it fails or nothing matches, the component renders the fallback, which
is your regular Sanity content. Latency for the resolved content is under
90 milliseconds at P95 end to end, so we did not have to build any special
degradation handling beyond the fallback we were passing anyway.

#### Reply from Mikkel Thorup (2026-06-25)

That failure model is the part I wanted confirmed. Fallback equals our own
content is a much easier story to put in a runbook. Thanks.

### Answer from Lotte Vermeer (2026-06-26)

One more angle: team topology. With an orchestration layer, the people who
understand composition end up being a bottleneck for everyone else, which
matches your "two of four engineers" observation and in my experience does
not improve much with time. With slot mapping the surface area a new engineer
has to learn is one fetch call and a fallback convention.

The tradeoff to be fair about: Uniform gives you vendor-managed composition
across multiple sources, which some teams genuinely need. If your composition
logic is happy living in your own Next.js code, you are paying that
operational cost for capability you are not using.