4 ms·
> Imagine if you could just send it the whole “page” Could have stopped here
by shaftoe444 3y ago
> Imagine if you could just send it the whole “page”
Could have stopped here
- aatd86 3y agoMaybe for separation of concerns between data and UI? The browser is not going to be the only client?
- philderbeast 3y agoyou 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 3y agoTrue, 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 3y agoThat'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 3y agoThat'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 3y agoNo, it's for everything.
- aatd86 3y agoCould you explain further? I don't understand.
- CharlieDigital 3y agoThat'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).
- aatd86 3y agoYes 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.
- nonethewiser 3y agoWell now you’re building a general purpose API
- aatd86 3y agoI think there is a middle-ground concern here: avoiding request waterfalls.