BFF Dilemma - GraphQL - part 3
So this is 3rd part of the series of BFF Dilemma. If you did not read part 1 and part 2 I highly recommend read them before continuing with this one. GraphQL is a kind of BFF I would say. BFFs then to be more flexible and allow all sorts of programming models and techniques. GraphQL is Data-Driven and has fewer options in a sense of flexibility. However, GraphQL is an interesting solution that could be used as a BFF solution or in conjunction with a standard BFF solution. Several people wonder if GraphQL is the natural replacement of REST. There are all sorts of comparisons with SOAP vs REST vs GraphQL. IMHO GraphQL is not the REST replacement I would not expose APIs only with GraphQL ONLY for all sorts of reasons.
A Tale about Joins
Before Microservices monolith applications used to have a single Relational Database for all Storage. That approach had all sorts of issues and problems however there were benefits like much more simple code reuse, dependency management was mich more simple, deployment complexity was much smaller, and in regards to Data access, you could fix almost any problem by doing a query. Right now with lots of microservices However on the classical 90s style monolith architecture, there were lots of abuses in sense of queries. NoSQL raised a strong, scalable, and better design for some uses cases. However besides the abuses was pretty awesome to be able to run a query to answer any question for several reasons like:
* SQL is known by everybody
* Tooling around SQL is really good
* It's possible to share the queries with other analyses, users and also do discovery.
Often microservices are exposed via REST or gRPC with no common language to query things. That's is one of the many benefits of GraphQL, being able to run queries across all microservices. So Let's talk more about GraphQL.
Before we go down the rabbit hole I just want to say that there are other solutions for "Queries" such as Streaming(Spark, Flink, Sanza) and if we look into the Analytical world there is even the Data Meshes solution. But letś focus on GraphQL and BFFs for now.
Enter The GraphQL
GraphQL is a query language created by Facebook in 2012 but it was only open source in 2015. Later on, the coded moved away from Facebook into a Foundation called GraphQL Foundation. GraphQL works by Schema definition where you define your data with proper typing. After defining your schema you need to work on your Resolvers in order to fetch the data. Resolvers allow you to talk to any microservice with any data storage behind it. Since Resolvers are done programmatically you literally can integrate with anything.
Sample of Query and Resul from GraphQL site
GraphQL has clients for many languages such as nodeJs, Java, Rust, and many more. GraphQL also has a UI with autocomplete (similar to a SQL Explorer tool) where you can run your queries. GraphQL also allow mutations(in order to insert/update data).
GraphQL Benefits
GraphQL has many benefits such as:
* Reduce latency for the Web or Mobile being fetching several services at once
* Avoid loading data that the UI or Mobile dont need(get exactly what you want).
* Have a common schema across your whole business (DDD Obictus language)
* Decouple the Data from the Schema (depending on how you do it)
* Fast Reuse and increase time to market
Developer experience using GraphQL us much better. Also, GraphQL is contract first by nature which is something highly desirable when working with REST. GraphQL makes fetching data much more fun and fast. However, like anything in technology, there are drawbacks. Let's explore some of the issues and challenges.
GraphQL Drawbacks
It's possible to fix some problems by having smart services which you reduce the load and make aggregation easy on the UI / Mobile by:
* Make your services smart by letting the consumers pick watch fields you will return.
* Have Aggregation Services or use classical BFF to reduce the load and do smart aggregation
* Relly on REST Network transparent caches (huge advantage of REST).
Graphql has limitations. Like any technology. If you are working with a Tree for instance the query syntax is a bit ugly and you need to say all levels you want to return. It's harder to cache and require your resolvers to be smart and use external caches explicitly.
There is a limited number of media types you can use. REST is much richer in the sense of media types and also standard BFF can deal with more things(SSR) than just Data. Finally, the biggest issue could be Performance and Scalability. REST is distributed and GraphQL centralizes things by nature. Resolvers can be run in parallel, use external caches and pre-load data, use smart batch calls when needed. So It will all depend on your implementation.
GraphQL & BFFs
GraphQL is a form of BFF. It's possible to use GraphQL and BFF together if BFF is more towards UI Logic or SSR. However, there is an overlap between both. If your BFFs just call services and dont have any extra logic you might be better off by using GraphQL. However, if your Services are smart services and you can choose the fields you want to return you also might not need GraphQL at all. Your Resolvers implementation could be brilliant or a disaster but for sure it will be more complex and thats fine you just need to understand complexity need to live somewhere.
IMHO is important to focus on what is your use cases and what exactly you trying to archive. As you might realize by this series of posts, there are so many options and different problems for different IT areas of interest. IMHO BFFs are here to stay either via NodeJs or Robust languages like Java, Go, and Rust or via Data/Queries using GraphQL we have a rich set of power options that can be explored.
Cheers,
Diego Pacheco
