Frontend/Backend argument for more tailored BFF UI response
Hi people!
A question about api design:
I have an api gateway for a web SPA app, specific to this UI so we can say BFF.
For a product's detail view, I want to show the product's name, products that are accessories for the main product (list with names), customers for reviews, and which product categories it belongs to (list with names).
Backend developers want to run as minimalist a design as possible and provide this model:
{
name: "foo",
id: 123
categories: [123, 234, 345],
accessories: [123, 234, 345]
}
The result is that on the client we need to make 4 different calls to collect the data for this detail view.
1.
Downloading customer reviews related to the product provides a list of IDs:
[
123, 234, 345
]
2.
Get details for these reviews, with ID's from the first call.
3.
Get the categories details to get the names.
4.
Get the accessory details to get the names.
So there will be many calls to show this view, and it feels a bit pointless to have such a minimalist detail endpoint, which when reused most likely needs to make these 4 calls every time to be able to show a product elsewhere in the application. instead of collecting the data needed for the view, thus moving these calls to the server.
The suggestion is that for categories and accessories you also have the name, so 2 of these 4 calls can be moved to the server.
It feels a bit counterintuitive to have a BFF, but then basically an extra layer is needed on the client to put together data that is actually useful to the view.
Note that categories and accessories are not heavy endpoints, that is, we will not have to wait for one of them for a noticeably longer time, in this case it feels reasonable to break out to be able to load into the detail view separately.
Advantages/Disadvantages of more calls in this case? Isn't the point of an api-gateway (or even more so a BFF) to be precisely adapted for an interface?6 Replies
which calls do you want to move to the server
I was thinking categories and accessories. But maybe even reviews.
It would then be just 1 call to have the information needed for this view, instead of 4 (between client and api-gateway)
Moving aggregation of data to server.
Benefits I could think of is reduced latency, gateway to microservice is quicker, always closer.
Less noise on client, also in code I guess.
Caching on server?
as we know that the categories and accessories data doesn't change, i think it's better to get it server rendered
doesn't nextjs cache the data by default
nextjs does cache data reqs
We don’t have server rendering possibilities unfortunately, it’s an older react app from before next was a thing 😀 so the bff/api gateway is in Java and written by backend developers
i think what you are suggesting is better
server render the data that doesn't change
caching can be benifical also
Thanks for input @shivam 🙏