Frontend API Layer Design

The API layer is the contract between your frontend and the world. Get it wrong, and you'll pay in duplicated logic, brittle error handling, and endless refactoring. Get it right, and your UI components stay simple, your backend can evolve independently, and your team ships faster. This guide covers how to design that layer for production-grade frontends.

Designing the Abstraction Between UI and Backend

Single Responsibility: UI Doesn't Know About APIs

Components should request data by intent ("get current user's cart") not by mechanism ("GET /api/users/123/cart"). Create a dedicated API layer—often a set of functions or hooks—that encapsulates endpoints, request shapes, and response transformation. Components call getCart() or useCart(); they never import fetch or see a URL.

Layers of Abstraction

A well-structured API layer has three tiers:

1. Transport layer: HTTP client setup (base URL, headers, interceptors)
2. Endpoint layer: Functions that map to specific API operations (getUser, updateProfile)
3. Domain layer: Higher-level operations that may orchestrate multiple calls (checkout = validateCart + createOrder + clearCart)

Keep the transport layer thin and generic; push domain logic into the endpoint and domain layers where it's testable and reusable.

REST vs GraphQL From the Frontend Perspective

When REST Wins

REST excels when your UI maps cleanly to resources and you rarely need to aggregate or reshape data. Simple CRUD apps, dashboards with predefined views, and apps where over-fetching is acceptable often work better with REST. Caching is straightforward (HTTP semantics), tooling is universal, and backend teams can add endpoints incrementally.

When GraphQL Wins