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!
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.
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.
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:
Our proposed solution here is using GraphQL as Front-End APIs, but why ?
And how about BFF Pattern, why to use ?
But drawbacks always exists! So, what would you consider:
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.
[1] Backend For Front-End Pattern Definition – http://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
Do you want to know more? Talk to one of our specialists, just fill the form below and soon we will get in touch ;)