
The ‘Backends for Frontends’ Pattern at SoundCloud - sgeb
https://www.thoughtworks.com/insights/blog/bff-soundcloud
======
cdnsteve
I actually found the article from Sam Newman went into greater depth:
[http://samnewman.io/patterns/architectural/bff/](http://samnewman.io/patterns/architectural/bff/)

Interesting to see this creates new problems, such as blocking calls to
dependant services downstream, and what services you declare as critical or
not. Also duplicate code is unavoidable. So if you're attempting this pattern,
keep those things in mind since you will have limited technology choices.

Sound Cloud is using Scala here.
[https://developers.soundcloud.com/blog/building-products-
at-...](https://developers.soundcloud.com/blog/building-products-at-
soundcloud-part-3-microservices-in-scala-and-finagle)

Edit: Found their mention of technology

~~~
zappo2938
Isn't this the same problem Facebook is solving with GraphGL and Netflix with
Falcor? Doesn't it also make sense to use node.js and express where the front
end meets the back end for two reasons; one, javascript is asynchronous in
nature, and, two, javascript is the language used by frontend developers?

~~~
herval
By "frontend", you might have ios or android apps, for instance (the case in
this study).

~~~
zappo2938
Touche!

I'm just so used to this discussion managing microservices and APIs coming out
of the Facebook and Netflix camps I had to stop and think, oh, not everybody
is using React wrapped in a native app. Woosh, right over my head.

It is possible this approach by SoundCloud is more of a solution to developer
teams not communicating. I reread OP's article and the question I'm asking now
is why wouldn't they want a consistent API across all platforms? I think that
it is BS that Andriod and iOS apps for the same product require a different
backend API. That makes no sense! This seems like symptom of the Andriod group
doing whatever they want and the iOS group doing whatever they want.

~~~
herval
What if the products have different sets of functionality? (Which is the case
for soundcloud's app). Also, there's more platforms out there - eg embedded
players (sonos, etc). It's hard to keep parity. In fact, both apps used to
consume their public API before this BFF model came along... And it's now
theoretically easier to evolve each individual app. That said, the _actual_
show-stopper in those architectures is the microservice constellation behind
it, so I'm yet to see a case where BFFs add anything other than redundancy and
more complexity to the mix.

------
andrewingram
This pattern is essentially what technologies like GraphQL or Falcor make
super easy. My GraphQL server talks to a bunch of microservices and presents a
simple clean API for my web application, largely freeing the front-end from
years worth of bloated APIs.

~~~
bsaul
I don't think having a single entry point aggregating micro-services to
provide a unified API for all your front-ends is what this pattern is about.
Actually pretty much the opposite, but maybe i'm missing something...

~~~
kapad
It isn't really a unified API for all front ends, but a separate API for each
front end. And sometimes that really makes sense.

------
bshimmin
I love the diagrams on this blog post. Does anyone know if they're hand-drawn
or if there's a tool that produces them?

~~~
lplotni
Thanks. The diagrams are hand-drawn and scanned :)

------
lmm
This is true at every interface though. Better to have the same people working
on the backend for the backend for the frontend. Better to have the same
people work on the database as the thing that queries it.

Ultimately you should separate teams by the functionality they're supporting,
not by which part of the stack they're notionally in. One interesting approach
is to pair-program at each step - designer and frontendey dev do the page,
frontendy dev and backendy dev do the front half of the backend, backendy dev
and DBAey dev do the data access layer.

------
drudru11
I like the solution.

It is a classic solution too.

A famous aphorism of David Wheeler goes: "All problems in computer science can
be solved by another level of indirection";[1] this is often deliberately mis-
quoted with "abstraction layer" substituted for "level of indirection". Kevlin
Henney's corollary to this is, "...except for the problem of too many layers
of indirection."

[https://en.m.wikipedia.org/wiki/Indirection](https://en.m.wikipedia.org/wiki/Indirection)

------
PaulHoule
Since communications overhead is so large in internet applications,
particularly on mobile devices, there really has to be "one mind" in charge of
both the front and back end of an app. That "one mind" can be a consensus in a
bunch of people's minds -- in fact it really should be.

My experience is that most programmers don't have a complete set of skills and
attitudes to optimize distributed systems. From the systems programmer who
writes mad C++ but can't understand why David Fielding hasn't won a Fields
Medal to the application programmer who has never heard of O(N^2) and doesn't
care, or the machine learning genius who is oblivious to locks and race
conditions in development and seems to fix them by patching the production
system directly multiple times over the course of a nail biting week for
customers, management and staff. (Somehow planning to take 2 or 3 days of one
person's time to understand the problem is a "waste of time")

Anyway, the key to this is working as a team that is closer to the sum of the
parts rather than the difference.

------
kapad
I'd read a very similar article from back in 2013 that spoke about the same
concept without really calling it "BFF". The article in question actually
talks about just using nodejs, but what we implemented from that at my company
was really what "BFF" is, and I really think that every microservice
architecture needs the backed for front end layer. Here's the link:
[https://www.nczonline.net/blog/2013/10/07/node-js-and-the-
ne...](https://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-
front-end/)

------
leonardinius
I see SoundCloud brand appearing more and more frequently in my blog/news
feeds.

Are they in the "search for the developers" /quick grow phase?

~~~
dominotw
doesn't look like it
[https://soundcloud.com/jobs/product_design_engineering](https://soundcloud.com/jobs/product_design_engineering)

------
hackercomplex
I don't get it.

Why is this so complicated when we have nginx and consul-template ?

------
dominotw
why is this on thoughtworks website when sound cloud has their own dev blog
([https://developers.soundcloud.com/blog/](https://developers.soundcloud.com/blog/))

------
corsibu
I am really curious how is this different to a hexagonal architecture

