Product-ready adapters for generated API clients

Product architecture

TL;DR
  • Generated clients solved transport, but pages still needed product-shaped data.
  • I needed a place for mapping, query state, uploads, and reusable view behaviour.
  • I built a domain layer between the SDK and the route components.
  • The result was thinner pages and a clearer boundary between API contracts and interface needs.

Generated clients are useful, but product screens still need a place for product meaning. Raw API shapes are not always the right shape for an interface.

Where it started

SDK calls gave the frontend typed access to the API, but product screens still had to map raw shapes into view state. That mapping was at risk of spreading into every page.

What needed to change

The adapter layer sits between generated SDK calls and pages. It owns mapping, query state, upload helpers, billing adapters, and reusable list behaviour.

That keeps page components from becoming the place where every domain rule accumulates.

What I built

The SDK handles transport. The adapter layer turns transport shapes into product-facing helpers, view models, and hooks.

Pages import the domain-level API instead of assembling the same mapping and query details repeatedly.

What changed

This creates a stable seam between platform contracts and interface needs. It also gives tests a better target than full page rendering.

What I would watch

An adapter layer can become a second domain model if it is not kept honest. It needs clear ownership and regular pruning.