Hacker News Reader

Comment by hot_gril | Hacker News Reader

Not sure what a BFF is, but having separate frontend and backend development doesn't mean you have 20 microservices.

I think BFF might stand for Backend For Frontend in this context

"A BFF layer consists of multiple backends developed to address the needs of respective frontend frameworks, like desktop, browser, and native-mobile apps."

Ok. Yeah that's only for huge scale things.

I don’t find that to be an accurate representation of BFF. I’ve used BFF with a browser FE to simply weave several microservice endpoints into a tailor-made api for the frontend. This reduces the burden on the microservices by removing the need to make many endpoints for clients and helps reduce network calls on the FE

Most of the time time BFF just means that instead of having the frontend call endpoints A, B, and C. It calls a single endpoint D, which calls A, B, and C and handles aggregating and transforming the data into the specific form the frontend needs.

Eh, I just call that "good design" under most circumstances.

A BFF is just an API gateway that is tailored to a single frontend. It's especially helpful if the frontend is a native application as opposed to a web application, hence why it was a pattern championed by Netflix. If you have some native client out there and you can't guarantee that the user will update it, it's helpful for it to only talk to a single service so in case you want to evolve your backend architecture, you can update the BFF implementation and the existing native app won't be broken by your backend changes.

Having a native app out there in the wild on customer computers that is coupled to a bunch of different microservices is hell for when you want to change your backend without breaking your customers' experience and forcing them to update.

The backend-per-frontend thing makes sense for Netflix. They're huge scale like I said, plus they've been around a while, so a lot of backwards compatibility issues will arise. I can't see that being a default pattern to jump to, though.

Backend that handles all the microservices so the frontend isn't doing that job, sure. I didn't even consider doing it differently than that.

Huge scale typically leads to the opposite: more backend generalization, not catering to a specific front-end. That's why Facebook built GraphQL — because they run on anything, like fridges, TVs. That's specifically an attempt to avoid tailoring a backend to a frontend. The article argues that at small scale you shouldn't try to build a generalized backend for any imagined frontend. It's exactly how you would get unnecessary performance and complexity bottlenecks, when you really just need to serve your data the 1 or 2 ways that your front demands.

Yeah, our org has a big problem with over-generalization in our internal services that I've been pushing back on. Due to the large size of our org, they're under the false impression that our services are large-scale, but they're actually very small compared to anything external-facing.

When a partner team filed a feature request on our team, and I gave them an API that just does exactly what they need, they were like "that's it? No 1GiB graph response to DFS through?"

Reply on news.ycombinator.com