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

21–26 of 26 posts

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#21

Post by Raphmedia »

[deleted] wrote: post #16
herval wrote: post #13

Earlier quoted context omitted.

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

[deleted]

I'll speak as a frontend dev and say that it's not about the languages but about the final objective. I'll use "backend languages" as needed to get the job done.

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#22

Post by zappo2938 »

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

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.

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#23

Post by herval »

zappo2938 wrote: post #22
herval wrote: post #13

Earlier quoted context omitted.

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

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 cons…

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.

Re: The ‘Backends for Frontends’ Pattern at SoundCloud

#25

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

Post reply on HN