Metrics, Logging, and Tracing are some primary forms of monitoring we use in our services. In this post, I talk about how we can leverage the power of GraphQL to prevent sensitive information ending up in these monitoring tools.
GraphQL excels in modeling data requirements. Modeling errors as schema types in GraphQL is required for certain kinds of errors. In this post, let's analyze some cases where errors contain structured data apart from the message and the location information.
In previous posts, we saw how to optimize data between GraphQL Server and a backend server using the concepts of lookaheads and field filtering. In this post, we are going to leverage look aheads for other forms of optimization - especially prefetching resources.
In the previous posts, we saw how to optimize the data transfer between the GraphQL server and a data provider - backend server. In this post, I'm going to talk about how we can handle the complexities we discussed in previous posts with a Dataloader
In this post, we are going to take a look at one of the primary optimizations we can achieve by using GraphQL Lookaheds - Field filtering. We will dive deep into what the different complexities are for applying lookaheads to optimize data between GraphQL server and a backend server.
GraphQL offers a way to optimize the data between a client and a server. We can use the declarative nature of a GraphQL query to perform lookaheads. Lookaheads provide us a way to optimize the data between the GraphQL server and a backend data provider - like a database or another server that can return partial responses.