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.
In this post, I'm going to use some features of TypeScript that are often considered "advanced". In the first section, I'll mention most of the TypeScript features I'm going to use and also point to their documentation for references. The post is about how we can get stricter types for Object Paths for different use-cases.
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.
This post is about how do we detect some of the cases where we have possibly repeated code in the same project or across multiple projects. This code if necessary can be extracted into a common module so as to avoid fixing bugs multiple times.