The web experience through a mobile device with its smaller screen, limited data plans and need for fewer requests differs in many ways from a desktop web browser. A mobile device requires less but often also different data and may provide other interactions, e.g. through a bar code reader. This means we need to add additional functionality to our API backend to support mobile devices, Sam Newman explains in a blog post describing a pattern for API backends dealing with this mismatch between devices for different types of user experiences.
One solution Newman, developer at Thoughtworks, describes is to build a general-purpose API backend serving all types of user interfaces. Due to the very different needs though this will in practice mean adding functionality and complexity to the backend. It may also become a bottleneck by slowing down the deployment process due to all the changes needed in supporting all devices. When working with a general-purpose backend sometimes a special team is created especially for the backend which in Newman’s experience can increase the problem, now a front-end team has a separate team to negotiate with, a team that has to prioritize requirements from other teams as well.
Another solution Newman have seen in use is to have one API backend for each user experience. Conceptually a user-facing application then consists of two components, one on the client side and one on the server side, a Backend For Frontend (BFF, a term coined by Phil Calçado when working for SoundCloud).
When working with a BFF it’s normally tightly coupled to a specific user interface, both maintained by the same team. When dealing with the same type of user interface but on different platforms, e.g. Android and iOS, Newman describes two approaches, with one BFF for each platform and with a BFF for each type of interface.
Newman prefers a strict model with a BFF for each platform, i.e. one for Android and one for iOS. One concern with this approach is the risk of ending up with lots of duplication between the BFFs with e.g. the same types of aggregation or similar code for interfacing with downstream services but he is not really disturbed with this duplication since it’s across process boundaries. Merging towards a general-purpose aggregating Edge API service is something he warns against noting that such a model has proven time and again to lead to highly bloated code.
Using one BFF per type of type of client, i.e. one for both Android and iOS, is an approach he has seen in use at SoundCloud. His concern with this approach is that with more types of clients the risk of bloating the BFF increases.
Lukasz Plotnicki, also working for Thoughtworks, writes in a recent blog post specifically about SoundCloud’s work with BFF during their move from a monolithic Rails application towards use of microservices.
In Thoughtworks latest Technology Radar BFF is mentioned as a technique worth pursuing.
Community comments
Vertical Slice
by Jean-Jacques Dubray,
Dev-op aspect pattern
by Chris Emery,
Vertical Slice
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
ThoughtWorks had a different name for this pattern a decade ago. It was called "Vertical Slice" pattern and that pattern is your worst enemy, it failed many of their clients because services sprawl like wildfire leading to massive duplication of code (versions, platforms, languages, ...).
The bottom line is that you cannot apply a "monolithic" mindset to a microservices architecture. Unfortunately, many experienced devs and architects seem to ignore that truism.
Dev-op aspect pattern
by Chris Emery,
Your message is awaiting moderation. Thank you for participating in the discussion.
It seems an area that aspect oriented programming and/or CDI and/or metaprogramming may be of aide in.
The allowance for selectable enhancements and the proper management of them should be matter for Dev-ops management and IDE operations.