Backend for Frontends at SoundCloud Quotes

In this article (BFF @ SoundCloud), Lukasz Plotnicki outlines the process SoundCloud used to implement backend-for-frontends in their infrastructure. Below are some quotes from the article that I thought were excellent.

• "After a while, it started to get problematic, both in regards to the time needed for adding new features, and also due to the different needs of the platforms. For a mobile API, it's sensible to have a smaller payload footprint and request frequency than a web API, for example. The existing monolith API didn't take this into consideration and was developed by another team, unaware of the mobile needs. So every time the apps needed a new endpoint, first the frontend team needed to convince the backend team that this was truly the case, then a story needed to be written, prioritized, picked, developed and communicated to the frontend team."
• "You can see the problem here: unnecessary friction, communication overhead, delay. At the same time, the backend team started to have issues with the monolithic application, as adding new features became harder, whilst fire-fighting got more prominent."
• "To tackle these issues, SoundCloud decided that whenever implementing a feature needed a specific, fine-tuned API, the team driving this is also able to implement the API endpoint and therefore decides where to get the data from and how to aggregate it, what payload needs to be transmitted etc. This API endpoint is to be created outside of the monolithic app and acts as a feature specific facade. The frontend team is the owner of this new layer."
• "One can see a similarity to the strangler pattern, where the BFF is strangling the public API offered by the monolith. And so, a BFF called public-api-strangler was introduced to hide the monolith API from the consumers. It was initially just a proxy forwarding the requests to the monolith. Over time, parts from the monolith got extracted and the public-api-strangler just re-routed the requests to the new microservices. Eliminating direct consumer calls to the monolith API, simplified the migration process towards the microservice-based system."
• "Okay, so how many BFFs should you go for? In the case of mobile platforms, due to limited time and resources, SoundCloud started with one BFF for iOS and Android. In hindsight, it would have been more beneficial to provide one BFF per platform, as the Android and iOS apps are different enough that they expose different API needs. You could also think about providing one BFF per feature, and if a particular feature is present on both platforms, they can use the same BFF. SoundCloud users can be divided into creators and listeners; therefore, it also makes sense to provide one BFF for creators and one for listeners, as these user groups also get separate apps. This is the path that SoundCloud also decided on."
• "Now the BFFs at SoundCloud obviously grew over time. Apps got new features, which requested new BFF functionality. This horizontal growth doesn't cause any headache. But the BFFs also grew in depth (vertically) and that exposed some duplication and resulted in extracting new services or parts into core libraries. The question is when something should become a new service or a library. A guiding rule could be: use a shared library if the functionality being extracted doesn't have to be updated at the same time, but if it does, then use a service."
• "Talking about duplication and reuse, don't try to make everything generic from the beginning. If you try, and it is used across the organization, it will cause friction, as a lot of people will want to contribute. Concentrate on your feature and specific usecases, before thinking about generic usage. The 'particular feature first over generic usage' strategy works far better. And don’t forget about the helpful ‘rule of three’ when thinking about extracting code."
• "BFF offers a good way to enable teams building different client-facing apps to be in charge of their own destiny. This autonomy is crucial to iterate quickly on the client apps and deliver good experience/features fast. By supporting change, BFF supports evolutionary design and moves the whole system into a better, less-coupled state and then a big single purpose API."

• All quotes are attributed to this article: BFF @ SoundCloud