Using GraphQL as BFF Pattern Implementation

Introduction

We are in the age of RESTful APIs, I could say these kind of API architectural style are on plateau of productivity. A lot of platforms supports the REST style, also the community and the most developers are familiarized with the concepts and tools.

So, why some part of community are moving on to other architectural style or patterns ? In my opinion, all architectural styles has some drawbacks, there is no free lunch! I believe REST architectural style are organized around business model in order to provide strong reuse. It's seems to be wonderful, but someone needs to pay the lunch!?!

As we can guess, the frond-end layer is even more dynamic and agile in terms of business requirements, the back-end layer where APIs lives are more bureaucratic and process oriented. So who need to be more adaptable ? The front-end off course!

In technical terms, the front-end need to understands the APIs and usually make too many requests and hide or transform fields to delivery an good performance (off course I mean a better user experience). Front-end developers suffers with these scenario, so it is normal to reach for others alternatives. Here is where GraphQL really fits well!

Backend For Front End (BFF) Pattern

And how about BFF ? In order to fix the problem related before the BFF (Backend For Front End) pattern already exists and could be used to fix this situation. In most of cases, the REST architectural style was used extensively. However, it makes sense, if my Enterprise (General-Purpose) APIs are REST, why not my Front End APIs can not be ?

One important thing to consider is the Front End APIs must support other protocols rather than only HTTP. Other asynchronous protocols such as WebSocket or messaging protocols are heavily used in web and mobile applications and GraphQL can be used with those protocols.

But let's back to the definition of BFF pattern, according with Sam Newman and Phil Cal?ado [1], The BFF is tightly coupled to a specific user experience, and will typically be maintained by the same team as the user interface, thereby making it easier to define and adapt the API as the UI requires, while also simplifying process of lining up release of both the client and server components.

Let's see now a graphical representation of this pattern:

As we can see on the picture above, we have iOS API and Android API using the pattern BFF. The Inventory, Wishlist and Catalog are Enterprise (General Purpose) APIs . Note that each front end application has your own APIs to delivery better experience.

GraphQL

GraphQL’s [2] power comes from a simple idea — instead of defining the structure of responses on the server, the flexibility is given to the client. Each request specifies what fields and relationships it wants to get back, and GraphQL will construct a response tailored for this particular request. The benefit: only one round-trip is needed to fetch all the complex data that might otherwise span multiple REST endpoints, and at the same time only return the data that are actually needed and nothing more.

Let's see the representation below:

How we can see, the front end as API client needs to handle the complexity of make several API calls and select which fields to show to the user.

The Proposed Solution

Our proposed solution here is join the existing BFF pattern using GraphQL as main API technology. Let's see how should be a high level architectural big picture:

As we can see on the picture above, the front-end applications consumes the Front-End APIs using GraphQL technology. In order to implement the translation from REST to GraphQL, a GraphQL Engine is used here as key component.

All Enterprise APIs are available in REST architectural style and can be reused to others client applications.

But the main component in this big picture is the API Platform which can be used here to:

• Manage and Expose the Enterprise APIs (REST)
• Manage and Expose the Front-End APIs (GraphQL)
• Implement and Run GraphQL Engine

Conclusion

Our proposed solution here is using GraphQL as Front-End APIs, but why ?

1. Works on multiple communications protocols such as WebSocket!
2. Hides complexity to handle RESTful Enterprise APIs

And how about BFF Pattern, why to use ?

1. Create Experience APIs for each communication channel.
2. The development team works on front-end and also back-end. The complexity to handle Enterprise APIs can be applied on backend layer and it can also be reused.

But drawbacks always exists! So, what would you consider:

• GraphQL has issues to handle such as not having built-in cache mechanism. In RESTful APIs, the HTTP protocol handles it natively.
• When using BFF your codebase might increase exponentially, once you may create custom behavior for each device.

Finally, if you want to use this kind of architecture, we strong recommend to use an API Platform [3] which can help you to handle both GraphQL and REST architectural style.

References and Further Reading

[1] Backend For Front-End Pattern Definition - https://samnewman.io/patterns/architectural/bff/

[2] GraphQL in the Age of REST APIs - https://medium.com/chute-engineering/graphql-in-the-age-of-rest-apis-b10f2bf09bba

[3] Sensedia API Platform - https://sensedia.com/en/api-platform/