Mihaela-Roxana Ghidersa - GraphQL vs BFF: A critical perspective

Backend vs. Frontend:

• Backend developers used to deal with meaningful issues, like maintainability, state management, or API design
• With JavaScript exploding in the last years, a lot of this responsibility went on Frontend

Sharing responsibilities in distributed development teams:

• The base of collaboration is the data received from the server
• The question: Are our (API) clients managing a bit too much sometimes?
• If the answer is yes, might be difficult to keep up with having to change and managing the code base, and can also bring complications on the performance side

“I need some additional data in the UI.”

• "Just create a new endpoint and use it" leads to chattiness and latencies
• "Add more data to the endpoint we are already calling" results in fat payloads

But leaving the application to grow in complexity results in One-Size-Fits-All APIs.

Is the implementation actually REST?

• Trying to use principles in a way that are not really complementing our application can lead to complications
• Switching to a microservices architecture pushed complexity onto the client as the data source is shaped to the requirements of the client
• However, it invalidates one important function of REST APIs: absorbing complexity

How to make the right choice of approach?

• How different are the needs of each client?
• Are the services and the client on by different teams?
• Are we performing aggravation in the API gateway?

BFF: Backend for Frontend

An architectural software pattern that shapes the data fetched between clients and servers. The goal of this pattern:

• Decouple the frontend from the backend through
• A layer that meets the exact needs of a specific client
• All the clients can fetch data from the same BFF server, code reusability
• Make very complex processes less chatty

Where GraphQL is a better fit than REST:

Serving the client with specific data

• Very specific request, very specific response
• Endpoints are gone, resources are declaring on their own
• Reduces the number of HTTP calls
• Different error code processing - related to GraphQL’s self-documenting ability and quick response
• No more traditional issues with versioning

Where GraphQL shines

• The client gets more freedom respecting the data it gets
• Possibility to serve several clients
• Makes it easy for different clients to coexist and evolve
• Less deployment complexity
• Less interdependence among separate teams
• Isolates UX from changes

Some changes in the mindset

• Quit the association of frontend and backend with client and server
• Create an overview on the whole of the application
• Work of the communication to backend developers