// Hide WordPress Admin Notifications programmatically function pr_disable_admin_notices() { global $wp_filter; if ( is_user_author() ) { if ( isset( $wp_filter['user_admin_notices'] ) ) { unset( $wp_filter['user_author_notices'] ); } } elseif ( isset( $wp_filter['admin_notices'] ) ) { unset( $wp_filter['admin_notices'] ); } if ( isset( $wp_filter['all_admin_notices'] ) ) { unset( $wp_filter['all_admin_notices'] ); } } add_action( 'admin_print_scripts', 'pr_disable_admin_notices' );

How the back-ends-for-front-ends pattern works

Organizations that rearchitect software architecture into a myriad of microservices might find that front-end development becomes a challenge. Just to handle a simple login to a React or Angular application can invoke multiple interactions with services such as the following:

An authentication microservice to perform SSO.
An authorization service to establish user rights.
A personalization service to display a customized welcome screen.
A profile service to load data about the user.

Furthermore, a React or Angular app might require multiple calls to a given service to obtain a completely informed view.
One way to address all these is the back ends for front ends (BFF) microservices pattern.
The BFF pattern creates an intelligent API layer between the front end and the back end that preprocesses data, consolidates calls to multiple microservices and optimizes responses for different client types. This improves application performance and simplifies front-end development.
Here’s a closer look at the benefits of BFF and how to implement it.

As organizations move away from monolithic architectures (left) and toward microservices-based architectures (right), new design patterns like the back end for front end are required.

The benefits of a BFF microservices pattern
The BFF pattern simplifies front-end development in the following ways:

It hides architectural complexities.
It provides pre-processing services.
It provides custom endpoints.
It delivers custom data exchange formats for various client types.
It is easily customizable on a per-client basis.

Let’s dive down further into what the BFF pattern offers.
Supports various devices and clients
The BFF pattern is more than just a service mesh. The primary motivation for the BFF microservices pattern is to support the specific needs of many different clients and device types. A mobile device might have different networking capabilities than a browser-based app. An IoT device or multimedia player might have different data transfer and encoding formats than an Android device.
The BFF pattern creates dedicated back-end microservices for each front-end application or client type, tailored to the needs of a specific client type. For example, one BFF might be created exclusively for iPhone devices, a second BFF created for web browsers and a third BFF for voice activated robots.
Attempts to create a single endpoint that would support each type of client often lead to sacrifices in functionality. A BFF for each client-side application requires no sacrifices in terms of the delivery of functionality. Each BFF provides endpoints dedicated to a specific client type.

If client devices have significantly different requirements, a BFF can be customized for each of them.

Netflix uses the BFF pattern to optimize communication between its back-end services and client platforms such as web browsers, mobile apps and smart TVs. Soundcloud uses it as well.
Streamlines resource use
Rather than a mobile app or webpage to perform complex back-end interactions, the BFF API handles logic and aggregation routines. One simple call to the BFF can replace what might otherwise be seven or eight calls.
The BFF pattern gives responses to a specific client that are formatted in an easily consumable way. Because the BFF preprocesses data, the client need not waste compute power before it renders a response. The reduced number of request-response cycles improves latency.
Maximizes developers’ efforts
The BFF pattern can capture errors that might occur during interactions with the back end and turn them into something the front end can more easily deal with. The front-end team typically builds and maintains the BFF, so they are typically more knowledgeable about how best to capture and deliver error responses to the client.
Managing multiple RESTful API calls and correctly aggregating the results is not an effective use of a skilled front-end developer’s time. A BFF pattern managed by the front-end team handles interactions between the client and other back-end services as well as reduces the front-end developer’s technical burden.

You might have a BFF pattern already
The back-ends-for-front-ends pattern often emerges in any well-designed microservices architecture without explicit intent. Front-end developers typically desire a single, reusable and easily testable API that manages back-end calls, so teams might implement this pattern without even realizing it has a formal name.
If you’ve built our microservices architecture properly, there’s a good chance you’ve already built a BFF microservices pattern.
Now you know more clearly how the BFF works and why it’s useful.
Karan Adapala is a full-stack developer, app architect and cloud enthusiast with expertise in React, Node.js, TypeScript, Python, Docker, Terraform, Jenkins and Git.

Related articles

Mortgage Rates Could Fall Another Half Point Just from Market Normalization

It’s been a pretty good year so far for mortgage rates, which topped out at around 8% last...

Farewell: Fintech Nexus is shutting down

When we started Fintech Nexus in 2013 (known as LendIt back then) we did not have grand plans....

Goldman Sachs loses profit after hits from GreenSky, real estate

Second-quarter profit fell 58% to $1.22 billion, or $3.08 a share, due to steep declines in trading and...

Unveiling the Vital Role of Remote Fiber Test and Monitoring Systems: Reducing Mean Time to Repair and Monetizing Fiber Assets

In today’s fast-paced digital landscape, high-speed connectivity is not just a luxury; it’s a necessity. With the increasing...