Hacker News Reader

Comment by vore | Hacker News Reader

I feel like another alternative in this space is to use GraphQL: while it does introduce complexity in terms of query handling, it does allow each frontend to more precisely query the data model and avoids having to tightly couple the frontend data model to the backend data model.

View on HN

GraphQL is practically designed to support this pattern. Facebook was one of the early proponents of this architecture and GraphQL was a product of that. The federation features allow individual teams to maintain their slice of the pie and communicate with the real backends over RPC.

GraphQL was explicitly designed for querying the service model. I’m not sure that makes it an alternative, but rather and early advocate and adopter of BFF, promoting the BFF approach that worked for Facebook.

It has been used to query the data model by some. Data is data at the end of the day. But that is not where it really shines and misses some of its advantages when the service layer is skipped.

Yes, by using GraphQL's Query DSL, the client can control what to fetch :) From my opinion, the mainly difference is API Gateway can filter requests and protect the upstream services (GraphQL can't).

GraphQL can totally do these things, with an appropriate resolver. I mean, in the end, anything you can do using REST can be achieved with GraphQL.

But shouldn’t the individual services be protecting themselves?

That said, I think there’s a case for BFFs - even ones implemented in GQL - when there is a need to support devices or customers which you can change, and which may live longer than your API.

If you’re writing resolvers manually for something like this, your stack sucks. Use federation.

Edit: I meant to say "can't" change.

Reply on news.ycombinator.com