BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News A Pattern for API Backends Serving Frontends

A Pattern for API Backends Serving Frontends

Bookmarks

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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • 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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT