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:
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.
BFFs increase 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.
Expedite A/B testing with a backend for frontend
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.
BFF + SSR = SEO improvement
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, Layer0 handles all of this for you in a performant, scalable way that requires no DevOps or maintenance.
Improve site speed with the right web tech
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.
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.
How BFFs keep JS execution times low and performance high
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.
Provide better 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.
Increase ease of deployment with a BFF
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.
Why your headless eCommerce site needs a BFF
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.
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.