Backend for Frontend (BFF), I Ignored It… Until My System Forced Me

I'll be honest.

For a long time, I thought BFF is just another "system design buzzword".

Something people use in interviews to sound smart.

In real work?
Didn't feel needed.

Then system grew… and things started breaking in ways I didn't expect.

How It Actually Starts

At beginning, everything is simple:

• One frontend (React / Next.js)
• One backend
• APIs look clean
• Life is good

Then product evolves:

• Web app
• Mobile app
• Admin panel

Still same backend.

That's where slow problems start.

Real Problem (Not Theoretical)

Single backend -> multiple frontends = compromise everywhere

Example API: /user/profile
Response:

{
  name,
  email,
  address,
  preferences,
  orderHistory,
  notifications,
  featureFlags
}

Reality:
Mobile → needs only name + notifications
Web → needs most of it
Admin → needs different subset

What we do?

• Send everything
• Filter in frontend
• Add conditions in UI
• Duplicate logic

Now frontend is doing backend work.
And code starts feeling heavy.

Where BFF Comes In

Not one backend for all.

[ Web ]    --> [ Web BFF ] 
[ Mobile ] --> [ Mobile BFF ] --> [ Core APIs ]
[ Admin ]  --> [ Admin BFF ]

Each frontend talks to it's own layer.

Simple idea, big impact.

What Changed For Me

After using BFF, few things became very clear.

1. No More Over-fetching
2. Frontend Became Cleaner
3. Fewer API Calls
4. Teams Stop Blocking Each Other

Important Part (Most People Skip)

BFF is useful, but not always.
Don't use it if:

• Only one frontend exists
• APIs are already simple
• No performance issue
• Small team Otherwise, you're just adding extra layer for no reason.

Final Thought

You don't start with BFF.

You reach a point where:

• Frontend is messy
• APIs don't fit use-cases
• Teams are blocked And then BFF stops being "optional".

It becomes obvious.

Curious how others are solving this - feel free to share your approach in the comments.