Diego Pacheco Tech blog

GraphQL makes a lot of sense for mobile applications. Especially when we consider poor networks. Aggregating data in one call is very powerful and makes a lot of sense for mobile. GraphQL allows a single interface for all operations for reads and writes. GraphQL is not that different from an API gateway or aggregation service. Selecting only the fields you need allows you to reduce the payload of requests, and latency resulting in improvements in the user experience via the mobile app. GraphQL has a lot of power and flexibility, which requires lots of attention to detail as well. Understanding the tradeoffs is important, one thing you are giving away by using only GraphQL is the ability to make multiple service calls in an asynchronous fashion, GraphQL is synchronous. GraphQL performance will have penalties . GraphQL never will be as fast as a modular monolith doing proper queries in the database. We can mitigate some performance issues by doing pre-loading, batching, or just caching ...

NetflixOSS Released a pretty interesting new solution. A framework for GrpahQL fully integrated with Spring Boot. DGS is super easy to use. You basically have zero effort to use it with Spring boot applications. DSG works with Maven or Gradle, Java, or Kotlin. Some time ago I made some posts about GraphQL and BFF you might want to check it out here and here . You compare with this other approach(also with a video) available here . Without further due, let's get started.  The Video The Code https://github.com/diegopacheco/java-pocs/tree/master/pocs/dsg-fun Cheers, Diego Pacheco

GraphQL it's an interesting approach for Data Aggregation. GraphQL is a query language API for existing data. You can leverage all your REST APIs and existing data sources. GraphQL it's mobile-friendly and you can ask literally just the fields you need. GraphQL also allows you to share queries and there are clients for pretty much all languages. GraphQL allows you multiplex and de-multiplex multiple requests in one, being really great for tail latency and nice for data-intensive applications. However, not everything in graphql is flowers and I dont want to paint a rosy picture. There are issues and tradeoffs you need to take into account. I highly recommend you read these 3 series of posts I made comparisons with other approaches like BFs. BFF and GraphQL Dilemma part 1 , part 2 , and part 3 . Today I want to share a video I made where there is a GraphQL Server written in Java and we have 2 clients one Written in Go Lang and the other written in Rust. So Let's get started....

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.