[philderbeast]

you can have seperation of data and UI and still send the whole page.

The vast majority of the time, the browswer is infact going to be the only client.

once you reach the point where its not, then build the api to suit the new client rather then trying to build one that does both.

[aatd86]

True, you could insert something in the middle, that generates a page depending on the user-agent. But then it requires extra SSR logic.

But on the other hand, you can have a iOS or Android based app that depends on the same data. So the browser is not the only client in general, especially nowadays, I think?

[regularfry]

That's the crux of the question. The BFF approach says that you remove logic from the client and put it in a server-side component. Not that you add extra logic. Then you might find that you need to copy that server-side component sideways for a new client, if the view layer in that client is sufficiently different to what you already have. The browser can be the only client of its BFF API; the mobile apps can either speak to the same API or have their own.

Dramatically more important than any theoretical, abstract consideration in deciding whether this can work is what your teams look like. The client team should almost certainly own the BFF API, which has implications for skillsets and maturity.

[aatd86]

That's only for a react type of application if I'm not mistaken?

If so, that doesn't handle the general case (native apps for instance)

[regularfry]

No, it's for everything.

[aatd86]

Could you explain further? I don't understand.