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

Popular posts from this blog

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all language...
Keep reading

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail...
read more »