Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The ‘Backends for Frontends’ Pattern at SoundCloud

thoughtworks.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#11

Post by zappo2938 »

cdnsteve wrote: post #8

I actually found the article from Sam Newman went into greater depth: 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. S…

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?

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#12

Post by herval »

andrewingram wrote: post #2

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.

These sorts of overarching architectures always leave me scratching my head too. IMHO a combination of a graph layer (eg the two you mentioned) and an scs architecture (scs-architecture.org) allow teams to remain largely independent and productive. That might sound superficially similar to "BFFs" as in "each team owns the client + api", but shifts the responsibility for larger units of work and away from individual microservices (which becomes a huge pain when you start to have dozens of BFFs interfacing with hundreds of microservices maintained by independent teams).

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#13

Post by herval »

zappo2938 wrote: post #11
cdnsteve wrote: post #8

I actually found the article from Sam Newman went into greater depth: 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. S…

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?

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

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#16

Post by [deleted] »

herval wrote: post #13
zappo2938 wrote: post #11

Earlier quoted context omitted.

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?

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

[deleted]

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#17

Post by bsaul »

andrewingram wrote: post #2

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.

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

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#18

Post by 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...

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#19

Post by kapad »

bsaul wrote: post #17
andrewingram wrote: post #2

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.

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

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.

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#20

Post by 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.

Post reply on HN