How do I avoid writing custom Backend for Frontend code?

To avoid writing custom Backend for Frontend (BFF) code, the main strategy is to reduce the need for a frontend-specific aggregation layer by designing your APIs and frontend architecture more intentionally.

Here are the most effective options:

1. Use a well-designed API gateway or GraphQL layer

• API Gateway: Can centralize routing, auth, rate limiting, and sometimes response shaping.
• GraphQL: Lets the frontend request exactly the data it needs, often eliminating the need for custom BFF endpoints.
• If your main BFF work is “combine data from multiple services,” GraphQL can reduce or remove that need.

2. Make backend APIs more frontend-friendly

Design APIs so the frontend can use them directly:

• Return UI-ready resources rather than very granular objects.
• Include commonly needed related data in one response.
• Avoid overly chatty endpoints.
• Use endpoints aligned with user actions and screens, not only internal domain entities.

3. Prefer shared reusable client logic over server-side composition

If the logic is simple and not security-sensitive:

• Fetch data from multiple APIs directly in the frontend.
• Use client-side state/query libraries like:
  • React Query / TanStack Query
  • SWR
  • Apollo Client These can handle caching, retries, and orchestration without needing a BFF.

4. Standardize on a single backend contract

If possible:

• Use a single service or a unified domain API.
• Publish a stable contract that multiple frontends can use.
• This avoids creating one-off backend code for each frontend.

5. Use generated clients and contract-first APIs

• Define APIs with OpenAPI/Swagger or GraphQL schema.
• Generate typed clients for the frontend.
• This reduces custom adaptation code and keeps backend/frontend aligned.

6. Push non-UI-specific logic deeper into services

If the BFF is mostly handling:

• validation
• authorization
• business rules
• transformations

…consider moving that into shared backend services or domain layer instead of the BFF.

---

When you probably still need a BFF

A BFF is often worth it when you have:

• multiple frontends with different needs
• complex data composition from many services
• security-sensitive calls that shouldn’t happen in the browser
• performance needs that require server-side aggregation
• per-device optimization (mobile vs web vs partner API)

In those cases, the question isn’t “how do I avoid BFF code entirely?” but “how do I minimize it?”

---

Practical rule of thumb

If your frontend is mostly:

• combining a few APIs,
• reshaping JSON,
• or orchestrating simple calls,

then try:

• GraphQL, or
• better backend endpoints, or
• client-side data fetching libraries

before building a custom BFF.

If you want, I can also give you:

1. a decision tree for when to use BFF vs GraphQL vs direct frontend calls, or
2. a reference architecture that avoids BFF code in most cases.