4 ms·

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 m

by vore 4y ago

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.

jjzhiyuan 4y ago
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).
- doctor_eval 4y ago
  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.
  - eurasiantiger 4y ago
    If you’re writing resolvers manually for something like this, your stack sucks. Use federation.
  - doctor_eval 4y ago
    Edit: I meant to say "can't" change.
bbatha 4y ago
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.
randomdata 4y ago
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.

4 ms·

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 m

by vore 4y ago

jjzhiyuan 4y ago
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).
- doctor_eval 4y ago
  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.
  - eurasiantiger 4y ago
    If you’re writing resolvers manually for something like this, your stack sucks. Use federation.
  - doctor_eval 4y ago
    Edit: I meant to say "can't" change.
bbatha 4y ago
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.
randomdata 4y ago
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.