> The front end service is a service that runs server-side, and assembles data from all the back end services so the client can render. And the front end service is owned by the front end team.
Congratulations, you reinvented GraphQL. /s
Jokes apart, I don’t care much about the technology, but what exactly are we optimizing here? Does this BFF connect directly to the (relational/source of truth) DB to fetch the data with a massaged up query, or it just uses the REST API that the backend team provides? If the latter, we’re just shifting complexity around, and if the former, even if the it connects to a read-replica, you still have to coordinate schema upgrades (which is harder than coordinating a JSON endpoint).
Just let the session-dependent endpoint live in the backend. If data structure needs changes, backend team is in the best position to keep it up to date, and they can do it without waiting for the front end team to be ready to handle it on their BFF. A strong contract between both ends (ideally with an OpenAPI spec) goes a really long way.
Congratulations, you reinvented GraphQL. /s
Jokes apart, I don’t care much about the technology, but what exactly are we optimizing here? Does this BFF connect directly to the (relational/source of truth) DB to fetch the data with a massaged up query, or it just uses the REST API that the backend team provides? If the latter, we’re just shifting complexity around, and if the former, even if the it connects to a read-replica, you still have to coordinate schema upgrades (which is harder than coordinating a JSON endpoint).
Just let the session-dependent endpoint live in the backend. If data structure needs changes, backend team is in the best position to keep it up to date, and they can do it without waiting for the front end team to be ready to handle it on their BFF. A strong contract between both ends (ideally with an OpenAPI spec) goes a really long way.