Notes and Scribblings from a web developer with unhealthy interests in JavaScript, GraphQL, and others
Persisted query overrides let us re-route a query ID to a different compatible query in production, without changing the client.
In this post, I talk about an approach to memoizing a n-ary function in JavaScript / TypeScript preserving the flow of types.
This post gives an introduction to GraphQL directives, how to create custom ones, explains the different locations where directives can be used, and goes over some use-cases of directives.
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 cover the topics — GraphQL persisted queries at Zalando and how we define and think about different levels of stability of our GraphQL schema.
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 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.
If you've some file committed to a git repository, and you'd like to remove it, simply deleting the file and committing it again will not remove the file completely. It still lies in the git history. If you want to remove a file from git history, the history needs to be re-written. This post is about exactly doing that - rewriting git history such that the file to be removed stays removed.
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.
This post is about how to effectively model timers for the web and go through the shortcomings of each of those models.
At Directi, we use graphite as one of our principal monitoring tools. This is a post about how we improved the Graphite setup at Directi.
