No, I don’t mean “Best Friends Forever.” We in the tech community are fond of clever if unoriginal acronyms, and so the tech community has hijacked BFF for an increasingly recognized pattern for high performance web apps: “Backend For Frontend.” We feel the reuse is justified. A backend for frontend can truly be your front-end’s best friend, especially if it is an eCommerce progressive web app.

What is a Backend For Frontend (BFF)?

Originally coined at SoundCloud, a BFF is discrete layer in your application stack that allows a single client, like a React Progressive Web App (PWA) or native mobile app to efficiently use shared APIs without the need to optimize those APIs for each client. In the ideal eCommerce architecture both PWAs and native mobile apps utilize the same core APIs. On the surface the two clients might seem so similar that it’s tempting to simply allow both to connect to the core APIs directly. Do so and you’ll find each client making its own specific demands of the APIs.

For example, consider the differences between a web app client and a native app. React PWAs have URLs and need descriptions and page titles for SEO purposes. Mobile apps do not. All those little demands add up. Soon you’ll be finding a lot of these in your API code:

if (isMobileApp) {
  doThis();
} else if (isWebApp) {
  doThat();
}

Backend for frontends allow you to share APIs among clients without tweaking them to the specific demands of each client. The BFF essentially manages the flow of information between APIs and clients and comes with a number of operational and technical benefits, including increased developmental velocity, website speed, security, and more.

Increased team velocity

Having separate BFFs for native and web apps allows each team to freely iterate on their app without changing core APIs. Need to add or remove data from a particular web page to increase page load speed, or add new functionality? If you need to change the core APIs, you risk breaking the mobile app in the process. If the web app has its own BFF, this risk is eliminated and the web and mobile teams can work independently.

A/B testing

Want to try out a new experience that requires changes to the API? Without a backend for frontend, you’ll need to A/B test both the front-end and the API concurrently. What if mobile and web teams are both running A/B tests? What state does that leave the API in? Will one team need to wait for the other?  

A BFF eliminates this problem by giving each team a separate space to experiment with the data that each client consumes. You’ll also likely find that it’s more expedient to implement an experimental API change in a BFF first, and then migrate it into the core API if that experiment wins the A/B test.

SEO

eCommerce businesses depend on SEO. Crawlers and bots don’t reliably index content that’s rendered by JavaScript. Good luck convincing your SEO consultants that a JavaScript heavy site will be good for your SEO. The only way to be 100% sure that your site will be indexed properly by search and social bots and crawlers is to deliver good old-fashioned HTML. If you’re building a JavaScript-heavy eCommerce progressive web app on any of the major frameworks- React, Vue, or Angular- you’ll need to render your pages on the server. The BFF is a perfect place to do this.

Building a backend for frontend that handles both server-side rendering (SSR) and API shimming and orchestration is difficult, so some choose to use a separate pre-rendering service. Server-side rendering, even when done right, can be slow and CPU intensive (and therefore costly). Having a completely separate service that uses headless chrome to prerender pages will be even slower and more resource-intensive due to the extra network hop between headless chrome and the BFF, as well as the additional resources needed to run headless chrome. Fortunately, the Moovweb XDN handles all of this for you in a performant, scalable way that requires no DevOps or maintenance.

Site speed

React PWAs are fast… when navigating from page to page. But without some significant optimization, they can be slower than an old fashioned multi-page app when measuring the first-page load. Unfortunately this is the metric that matters most for minimizing bounce rate and improving search ranking. Google’s ‘Speed Update’ prioritizes faster loading mobile sites over slower loading sites in their ranking algorithm. Sadly, the specific metrics use all relate to first-page load times, which isn’t a PWA strength, unless you employ SSR.

Without server-side rendering, the browser needs to download, parse, and run all of the JavaScript before a single pixel can be rendered on the screen. PWAs without SSR struggle to achieve a time to first meaningful paint (TTFMP) below 2.5s on simulated 3g. With a good CDN, a site that uses SSR can achieve sub-second TTFMP times, around 0.9s or less.

It’s worth noting that while this kind of performance has always been a critical component of the user experience and conversion rates, now it’s vital for SEO as well. In other words, not only does a faster site convert better, it also convinces Google to rank it higher and send you more traffic than to slower sites for the same keywords.

Better performance  

Your APIs should be built with the general case in mind, not tailored to specific clients. Doing so helps keep core APIs maintainable and maximize their value to the business. The more general your APIs are, though, the more code you’ll need in your front-end to shim them for your particular use cases.

For any given page on your site, your front-end may need to orchestrate calls to multiple services and/or reformat response data to best suit the page design. This code needs to run somewhere. A BFF lets you keep this code out of the front-end bundle, keeping it small and fast. In most cases, responses are cacheable, so rather than running this shim code in every user’s device on every request, it’s run in the cloud which can scale to meet demand, and only when there’s a cache miss.

A small JavaScript bundle is essential in keeping time-to-interactive (TTI) low, which in turn is a major component of how Google ranks your site based on speed. Using a backend for frontend to fit response data to the specific purpose of your front-end also keeps JS execution times low, giving the website a snappier feel.

Security

When you give the front-end access to your APIs you give the entire internet access to your APIs, and even the API keys you use for third-party services. There’s no way around that. On the web there’s no such thing as a trusted client. A BFF allows you to only expose the specific functionality needed for your front-end. This can greatly reduce the surface area that needs to be secured.

Ease of deployment

A BFF is a great place to implement feature flags. Feature flags increases ease of development and agility by decoupling feature management from code deployment. Feature flags give your administrators and non-technical stakeholders a lever to turn functionality on and off in real time, without having to wait for a code deploy.

For example, when Facebook rolled out their Usernames feature they had feature flags that enabled them to turn the feature on or off when product management was ready (i.e. pending press releases, public announcements, etc.). In addition, they also had flags that let them manipulate various site parameters, such as how frequently clients would fetch information from their servers. This gave them ways to mitigate a demand spike that would have otherwise have brought down the site.

Implementing a feature flag client-side is insecure. Like putting an API key in your client, client side restrictions can easily be ignored by a motivated attacker, or even a determined “power user.” As a result, you need to go a layer deeper into the stack to the server. Because the BFF sits between the clients and the rest of the infrastructure, it is one of the logical places to implement and enforce feature flags.

Headless eCommerce

Headless eCommerce is the practice of decoupling the front-end presentation layer from the backend logic and data. This trend is gaining traction within eCommerce, as it frees companies to adopt a best-of-breed approach, choosing the best solution for their front-end and their backend logic separately to provide an optimal experience for their customers and business.

Most eCommerce platforms are built with a data-first and inventory-centric approach, not a customer-centric approach. They focus on SKUs, and dynamic inventory, not the customer experience. And while their front-end offerings go through massive overhauls every couple of years, they seem to always be behind the open-source options that are available. By going headless, you also free yourself from the limitations of your eCommerce platform.

The BFF has a keystone role to play in this trend. In a headless eCommerce, or microservice based architecture you need something to stitch myriad of services into a holistic, unified experience. It’s possible to do this on the client, but this results in a maintenance nightmare as you duplicate code and effort across all the different client end-points. Imagine if you change how the service for product recommendations is stitched into the user experience, and then need to propagate that change out to your website, native apps, kiosks, etc. A BFF eliminates this headache as it functions as a central server where these changes can be coordinated.

Conclusion

A BFF manages the flow of information between APIs and clients and comes with several benefits, including increased developmental velocity, website speed, security, and SEO to name a few.

Having separate BFFs for each client and API allows each team to freely iterate on their app without changing core APIs, while limiting bundle sizes. A BFF is also the perfect place to add feature flags or API keys, while limiting the surface area that needs to be secured. And it is also where you should render pages on the server for SEO and site speed optimization.

Lastly, backend for frontends are critical for headless eCommerce, or microservices based architecture, as they enable developers to combine multiple services into a holistic experience.

Join industry leaders, including Amazon, Netlfix, Walmart, Nike, that are using a BFF to increase developmental velocity, improve site speed, increase security, and ease the deployment process.