13. Adopt GraphQL as Webapp BFF

• Date: 2020-11-27
• Driver: Wisen Tanasa
• Contributor: Harsh S. Kulshrestha
• Approver: Wisen Tanasa

Status

Accepted

Context

We are about to implement our shortlist page, which means we'll have 4 consumer points where they require different form of data:

• shortlist page
• building page
• search page
• shortlist flyover content

The shortlist page is particular will draw data from all of our bounded contexts, while the shortlist flyover content in contrast would draw data in a very minimum way.

We are also planning for the shortlist page to show even more entities data than what we currently have. On top of our building, space, nearby places, and masked number, we are also planning to introduce new data that we haven't even modeled like reviews, meeting room prices, internet packages, etc.

Decision

Adopt GraphQL as the BFF for our Webapp

Consequences

The shortlist page has brought a new level of complexity with it with the amount of entities that we are planning to support. In a combination with the other use cases that we have, the problems that we are facing at the moment are what GraphQL is aiming to solve.

This decision may sound a bit premature as we'll be introducing a new complexity to our architecture, but we think that the amount of complexity that it brings are not massive. Even though our team does not have the experience with GraphQL, we had managed to expose our Inventory and Comms data via AWS AppSync within one day, which proves that the ecosystem is mature. In terms of its maturity, GitHub has adopted GraphQL as a their main API endpoint since 2016. There also many other adopters that can be seen here.

Even still, 4 consumer endpoints may still sound a bit premature and we could have stayed with REST API to support those use cases and build our own BFF in REST. Unfortunately, carefully crafting our APIs to support each of the page itself would also incur some cost and effort to us. For example, we may or may not fetch multiple listings from the shortlist page, and amount of multiple listings we fetch is something that we may want to flex. It will take us some time to design such API, while GraphQL will give us such flexibility out of the box. The additional reason is we think that there's a valid opportunity (on-going conversation) for the providers to consume our API endpoint. Taking our journey now and learn a technology that is not complex, on a bite-size approach, will make sure that we'll be ready when we want to open this up publicly.