How do I avoid writing custom Backend for Frontend code?

You can avoid a custom Backend for Frontend (BFF) by choosing an architecture where the frontend can talk to existing services directly, or by using existing platform features that cover the same needs. The main idea is: don’t add a BFF unless the frontend truly needs backend-specific aggregation, shaping, or security boundaries.

Ways to avoid a custom BFF

1. Use a single API that is already frontend-friendly

If your backend can expose an API shaped around UI needs, the frontend may not need an extra layer.

• Design endpoints that return exactly what the UI needs
• Avoid overly generic REST endpoints that force many round trips
• Consider GraphQL if clients need flexible querying

Good when: your product has a stable UI and one primary frontend.

---

2. Let the frontend call multiple backend services directly

If authentication, CORS, and network topology allow it, the frontend can call services directly.

To make this workable:

• Use consistent auth across services
• Put an API gateway in front if needed
• Keep service APIs simple and stable
• Use shared DTOs or OpenAPI contracts

Tradeoff: the frontend may need to orchestrate multiple calls, which can get messy.

---

3. Use an API gateway instead of a BFF

An API gateway can handle:

• Authentication/authorization
• Rate limiting
• Routing
• TLS termination
• Logging/monitoring

This can remove the need for a custom BFF if your main reason was edge concerns rather than response shaping.

But: gateways usually don’t do UI-specific composition as well as a BFF.

---

4. Use GraphQL or similar query layers

GraphQL can reduce the need for a BFF because the client can ask for the exact data it needs.

Benefits:

• Fewer round trips
• Less overfetching/underfetching
• Client-driven queries

Caveats:

• You still need resolver logic
• Complexity can shift from BFF to GraphQL server
• Caching and authorization need careful handling

---

5. Push orchestration into the backend services

If multiple pieces of data are always needed together, consider composing them in a service boundary closer to the domain rather than in a frontend-specific layer.

Examples:

• A “profile service” aggregates user, preferences, and settings
• A “checkout service” orchestrates cart, pricing, and inventory

This avoids a frontend-only backend and keeps composition reusable.

---

6. Use shared backend-for-multiple-clients APIs

Instead of a BFF per frontend, expose backend APIs that serve web, mobile, and other clients adequately.

To support this:

• Use versioned contracts
• Keep representations flexible
• Provide optional fields rather than separate endpoints per UI

This reduces duplication and avoids per-client backend code.

---

7. Use server-side rendering or framework data fetching features

If you’re using frameworks like Next.js, Remix, Nuxt, or similar, some of the “BFF” work may be handled by the framework itself.

Examples:

• Server components
• Route loaders
• Middleware
• Server actions

This can eliminate the need for a separate custom BFF service, even though the logic still exists in the app layer.

---

When you probably should not avoid a BFF

A BFF is often justified if you need:

• Different APIs for web vs mobile vs desktop
• Backend aggregation tailored to one UI
• Security isolation from many internal services
• Simplified auth/session handling for browsers
• Response transformation optimized for page rendering
• Fast UI changes without affecting core services

If those are strong requirements, a BFF is usually the cleanest solution.

---

Practical rule of thumb

Ask:

1. Can the frontend consume existing APIs directly without awkward orchestration?
2. Can an API gateway, GraphQL, or framework layer cover the need?
3. Is the composition logic reusable by multiple clients or only this one UI?
4. Is the added BFF complexity worth the reduction in frontend complexity?

If the answer to 1 or 2 is yes, you can often avoid a custom BFF.

If you want, I can also give you:

• a decision tree for “BFF vs no BFF”
• an architecture comparison table
• or examples for React/Next.js, mobile, or microservices.