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.

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?

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.

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)

No, it's for everything.

Could you explain further? I don't understand.

That's what the database is, isn't it? The separation layer between the raw data and how it's projected into some interface (user or otherwise).

Yes in a way. There are a bit more layers in-between.

In fact, you can see it as 2 decoupled kinds of database:

- the storage database

- the working in-memory UI database that holds the data represented (e.g. on your screen (GUI)).

The goal in general is to modify the data contained in this UI database and then to push the changes to storage.

Well now you’re building a general purpose API

I think there is a middle-ground concern here: avoiding request waterfalls.