Why Mobile + Swift = BFFs
The Swift programming language from Apple is the strategic direction for developing applications for iOS devices. Swift will ultimately replace Objective-C, so it could be argued that Swift and mobile are best friends forever. In this context, though, “BFF” refers to the “back end for front end” (BFF) architecture pattern developed by ThoughtWorks and used at SoundCloud and Real Estate Australia (REA).
The BFF pattern
User-facing applications need to support a number of different clients, which will typically include both desktop web and mobile devices. In most common scenarios, the applications provide a general-purpose API provided on the server, which both the web and mobile clients interact with.
This presents some challenges as the needs of desktop web and mobile clients can be very different. For example, desktop web applications are concerned with the first paint time (the amount of time it takes between a user initially visiting a website to receiving usable information). Mobile clients, on the other hand, already contain the majority of the user interface and indeed usually need to be able to handle offline use.
Mobile clients have concerns about the size and frequency of data connections, as well as CPU, memory and battery usage. Desktop web, on the other hand, can be assumed not to have these resource constraints. Additionally, mobile clients may provide additional functions to the user, taking advantage of location awareness or mobile payment capabilities.
In order to deal with these different requirements from the clients of the server APIs, the “back end for front end” pattern was created, with one back end created for each front-end user experience.
Breaking down the silos
One of the advantages of the “back end for front end” pattern is that as the server API back end is specific to the front-end user experience, it can (and should) be owned by the front-end team. This provides huge advantages in terms of productivity and agility.
The front-end team contains all the developers needed to add features that require new or updated server APIs, without needing to hand off to a separate team that may have different priorities, ensuring they don’t become blocked and they have more rapid development and test cycles. Additionally, release cycles can be aligned with client and server components updated at the same time based on client needs rather than being blocked until the back-end team makes the server API available.
The introduction of the front-end team owning its own back-end server API does introduce its own challenges, particularly for smaller teams. For example, building resilient and scalable server APIs is an additional skill set that has to be learned. Using the same programming language for the client and the server can minimize this, making the cross-skilling much easier and indeed providing additional advantages in being able to share source code between the client and the server.
This has not been possible in all cases in the past. While desktop web could be backed by Node.js and Android could be backed by Java, iOS clients needed to be backed by a server API created in another language. With the arrival of Swift on the server, front-end iOS teams can now easily take ownership of end-to-end features.