Just read Sam Newman’s Backends For Frontends. It’s a very insightful piece and a worthwhile read. I’ve encountered the pattern several times, but I didn’t have a name for it and I feel so glad to see it more formally defined.
In the article, Sam focused on how BFFs are used with an emphasis to mobile apps. But I think in webapps they are equally useful. While a webapp can be relied upon to do all sorts of API calls and processing and merging of data itself, it’s still better to offload that to the server-side component. Speed is still a virtue in webapps, even if processing power and network bandwidth is more abundant.
Furthermore, a web app has a lot of “integration points” with the outside internet and search engines in particular. You want to provide a robots.txt, a humans.txt, a sitemap.xml, RSS/Atom feeds etc. Similarly, auth flows are generally dependent on redirects even when done in house. If you’re using an OAuth provider, Facebook login or Auth0 logins, you’re definitely going to have to handle a redirect. And again, the BFF is the place to handle this properly and securely.
Finally, even when coding a SPA I think it’s a good idea to own the hosting of “static” assets like the compiled js and CSS, favicons etc. Serving these is done from memory so it should be quite fast regardless of tools used. Furthermore, you should have some sort of CDN in front of it and long caches for the static assets, so you won’t hit the the system that often. Finally, at least for your public & indexable views, server-side rendering is a must. And once again, the BFF is a good place to handle all this work.
PS. As an extra, if the BFF is developed by the client team (which it should!), it can give that team some insights and experience with server-side development. In most organizations, the client teams tend to be much smaller than the non-client ones, and their tech stack and processes are quite different from the teams working on backend services or data munging etc. So there might be a certain sense of isolation. By having these teams also manage a service, you at least include them in the larger tech environment.