The BFF is strongly tied to a specific user experience and is generally maintained by the same team as the user interface, making it easier to design and change the API as the UI demands, as well as simplifying the process of aligning client and server component releases.
What is UI/BFF?
We’re seeing more use of UI/BFF shared types as TypeScript becomes a mainstream language for front-end development and Node.js becomes the favoured BFF technology.
A single set of type definitions is used in this method to describe both the data objects produced by front-end queries and the data served by the back-end server to satisfy those requests. We would normally be wary of this technique since it generates an overly tight connection across process boundaries.
An agreement between a back-end service and a front-end consumer is generally all that is required to connect the two worlds. That contract may be a REST API definition, a GraphQL endpoint, or anything else as long as it tells both parties what to anticipate from the other.
When creating a back-end microservice that is used by numerous client apps, the API must be standard, i.e., the same API for all clients. In principle, this streamlines adoption and makes learning how to use your service easier for new developers.
That being said, there will be occasions when your client apps are unable or unwilling to fulfil the terms of your API contract for whatever reason. This necessitates the addition of additional logic on the front end to interpret and turn your response into something they can really utilise.
And this is where the BFF comes in: instead of client apps communicating directly with the microservice, they will communicate via a proxy service, which will handle sending the request to the proper service and translating the answer into something the front-end can comprehend.
The client application stays dumb, which is something we like for security and ease of use. The simpler the client app, the faster other teams will be able to develop client apps. Furthermore, the essential business logic and data wrangling required are all kept hidden on the back end.
The incremental delay from the additional back-end connection is expected to be less than the impact from the additional resource consumption on the front-end.
BFF is responsible for doing the following:
- Use the applicable microservices APIs to get the information you need.
- Data should be formatted according to the frontend representation.
- Send the data to the frontend in a prepared way.
As a result, the frontend will have very little logic. As a result, a BFF aids in data representation and has responsibility for creating a frontend interface that is well-focused.
What are Shared types?
Shared types are a TypeScript-specific variant of the BFF pattern that allows you to share the same type definition between front-end and back-end code.
When should you utilise a BFF to help you with your applications?
The usage of the BFF in your application is determined by the context and architecture that you wish to utilise. A BFF, for example, is unneeded if your application is a plain monolithic programme.It will be of little or no service to you.
APIs are designed to connect easily to other services, both internal and external, in order to function efficiently and fulfil the goals for which they were created. While this is undoubtedly advantageous to users, developers frequently discover that the end product of this style of development contains some negative components.
If your application is dependent on microservices and uses a large number of external APIs and other services, it is preferable to use a BFF to simplify the data flow and add a lot of efficiency into your programme.
If your application requires an optimised backend for a certain frontend interface, or if your clients want data that requires considerable aggregation on the backend, BFF is a viable solution.
Advantages of using BFF
APIs are easier to maintain and alter.
The client application will know less about the structure of your APIs, making it more resistant to changes in those APIs.
The backend can be accessed by several device kinds at the same time.
Mobile devices can make requests to the browser BFF when the browser is doing so. It will aid in obtaining faster replies from the services.
Certain sensitive information can be concealed, and superfluous data to the frontend can be omitted while responding to the frontend.
The BFF pattern not only aids development, but it also significantly improves user experience.
Furthermore, if you haven’t used the BFF pattern previously, now is the time to start. After that, please share your thoughts and experiences.