Why Your eCommerce PWA Needs a BFF

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 a 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 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 allows 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 many 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? You risk breaking the mobile app if you need to change the core APIs. 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 front end, 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

eCommerce businesses depend on SEO. Crawlers and bots don’t reliably index content that JavaScript renders. 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 are to deliver good old-fashioned HTML. If you’re building a JavaScript-heavy eCommerce progressive web app on any 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. Even when done right, server-side rendering can be slow and CPU intensive (and therefore costly). A 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.

Schedule a consultative conversation

Layer0 can help simplify the process of building, testing, running, and optimizing large-scale sites deliver, and increase developer velocity by at least 20% in just a few weeks!

Improve site speed with the right web tech

React PWAs are fast… when navigating from page to page. But without significant optimization, they can be slower than an old-fashioned multi-page app when measuring the first-page load. Unfortunately, this metric 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 relate to first-page load times, which isn’t a PWA strength unless you employ SSR.

Without server-side rendering, the browser must 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.

How BFFs keep JS execution times low and performance high 

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

For any 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 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.

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 increase 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 waiting for code deployment.

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 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 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 available open-source options. 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 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 endpoints. Imagine if you change how the service for product recommendations is stitched into the user experience and then need to propagate that change 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 is 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, Netflix, Walmart, and Nike, using a BFF to increase developmental velocity, improve site speed, increase security, and ease deployment.