The quiet, pervasive devaluation of front end

Re:The quiet, pervasive devaluation of front end by karmakaze on Friday March 08, 2024 @09:53AM (#39641562)

I also see the opposite where a company has a web app product and a public API. The API is also a product. Some front-end developers think the API is the webapp's API and they shouldn't have to make any tradeoffs.

My suggestion in these cases, is to give the front-end devs a node/express server where they can compose the API calls the way they like and consume that from the webapp. But... they have to own it.

[ Parent | on HN ]

Re:The quiet, pervasive devaluation of front end by nerdix on Friday March 08, 2024 @10:44AM (#39642109)

This is also known as BFF (Backend For Frontend). Every client gets it's own API tailored for it's use case that will mostly just aggregate/orchestrate calls to the general purpose API.

https://samnewman.io/patterns/architectural/bff/

[ Parent | on HN ]

Re:The quiet, pervasive devaluation of front end by DanielHB on Friday March 08, 2024 @08:23PM (#39648517)

Some companies take this even further with a BFF for web, another for Android and another for iOS

[ Parent | on HN ]

Re:The quiet, pervasive devaluation of front end by cqqxo4zV46cp on Friday March 08, 2024 @09:14PM (#39648842)

I’d still put that in the same bucket really. It’s implicitly “a back end for a front end”

[ Parent | on HN ]