There are some functionalities in server side that are necessary to be exposed to mobile and desktop interface What should we do?
Should we create a new operation in the API with more data that we can use in both interfaces?
No, it is not a good idea.
Because of the nature of this interface is different, the experience to mobile user and web user is different.
In mobile interfaces there is less space in screen, so we should expose less data.
Opening lots of connections to server-side resources can drain battery life and limit data plans.
Therefore, our mobile devices will want to do different calls, less calls, and maybe show different data summarized those desktop devices.
Another problem is that just one backend API, can become a bottleneck to release new versions, because it can have many changes in the same API to many consumers and to detect possible bugs or errors could be a problem.
The tendency to API in general is to have multiples responsibilities, so it required much work, and sometimes is necessary creating teams to care this base code.
This can become a problem worse, front-end team and back-end team have to interact with different team to get changes, to expose operations and to consume operations, now there are three different teams to align the same priorities.
Backend for Frontend Pattern definition:
The application should be returned to user with two different components, one to mobile device other to desktop devices, and should be keeping with specific team, mobile team should keep their API and desktop should keep their API.
If this way is easier adjust to kind of client.
Release time can be diferent:
It was created to care to several consumers that we have nowadays to the same system, where each one have a requirement.
BFF is focused in a just only user interface, and that it.This allows that to be exclusive consequently will be less.
When it is delivered the same user experience to different platforms, there are two ways.
it can be utilized with call aggregator to parallelize calls, and it could reduce battery and band to mobile interfaces.
Working with failures on services:
In this example if inventory is down, it is not necessary interrupt the user actions, when service is available again, the users can consult the product inventory that was selected.
BFF reuse:
The same possibilities in above BFFs diferentes, in this case we can use an aggregator to call the common services
Where do we want to go? Evolution of the BFF
We can limit the numbers of consumers according to the device.
This can work with changes.
Helping development teams to become more focused to his costumer, giving more autonomy to each team.
Each team can control their future, providing specialty for your type of consumer.
Move the system to a less coupled design.
Reference:
Nenhum comentário:
Postar um comentário
Observação: somente um membro deste blog pode postar um comentário.