GraphQL
The DataLoader concept has become popular with GraphQL, combining batching and caching of database requests, API calls, and any other resource fetching implementation. Usually, DataLoader instances are used to fetch entities from a database, using one or more keys. Some DataLoaders receive a single key and return a single or
Systems Architecture
In my guide on designing scalable APIs, I emphasized implementing strict limits to how many entries are sent back for endpoints that return multiple items. The idea was that as long as you’re not completely sure that the data to be returned is limited to a small number of
GraphQL
DataLoader is an elegant solution for batching access to your application data layer, and optionally caching it for subsequent access. With the rise of GraphQL, DataLoader has grown in popularity too, as it can be used for accessing data in multiple layers, caching it the first time, and returning the
Evergreen
In the era of Software-as-a-Service products, we have seen a transition from interacting through user interfaces to interacting through APIs. Some products are available mainly through such a communication layer, enabling automation, and seamless integration between services. Whether you use Stripe for billing, Shopify for commerce, AWS for a variety
GraphQL
When you build a service focused around a GraphQL endpoint, you might think of testing strategies that can make use of it. After all, your resolvers will contain large parts of the actual business logic, otherwise, exposing an API wouldn't be useful, would it? Once you reach the
GraphQL
When building user-facing API products and services, validating inputs and enforcing limits is hugely important. Often, this involves repeating similar steps to check given parameters and arguments. Since you can't really trust user-supplied data until it is validated, you're usually required to validate arguments and then
GraphQL
🎉 As this post is a collaboration between Sentry and me, it was also published to the official Sentry blog, check it out! As the adoption of GraphQL is rising steadily, teams often come across the natural question of how to deal with errors that pass service boundaries and propagate from
GraphQL
Setting up the groundwork for querying your backend APIs should be a quick process, not fiddling around with configuration. Often it can be intimidating to integrate libraries to manage connectivity, caching, and other important features your application is going to benefit from, which is one of the reasons for the
GraphQL
Last Friday marked the first-ever edition of southern Germany's only GraphQL conference held yet, GraphQL Day Bodensee. Taking place in beautiful Konstanz, the one-day conference was hosted by Honeypot and Hygraph and offered a variety of amazing talks focused on GraphQL and its ecosystem, ranging from the adoption
GraphQL
Achieving consensus in open source projects can be a long-winded process, especially when there's room for numerous implementation directions. To make it clear from the beginning, the process of finding the best solution through consensus in working groups or steering committees is, although tedious, the best way to
GraphQL
I initially planned on writing this post to be about benchmarking and comparing implementations of GraphQL libraries and servers in Go vs. the popular JavaScript & Node.js alternatives like Apollo Server, etc. After delving into the Go ecosystem however, I've found myself switching between a couple of
GraphQL
After doing some cleanup on my projects list, I found a nearly-forgotten tool that I wrote a few months ago, and with some polishing and overhaul done, I'm happy to present to the world: aqueduct. To put it simply, it's a proxy service for GraphQL applications,
GraphQL
After releasing the post about tracing basics with an example of setting up tracing with a GraphQL service, I thought of a solution to make the development of tracing features for this kind of services even easier - the result of that effort is called graphql-middleware-jaeger. The simple functionality of
GraphQL
Tracing has emerged as one of the most widely-used techniques to monitor the performance and health of your services and applications, from development to production. Due to this heavy usage, a large amount of tooling is published and improved constantly, focusing on features related to distributed systems and recent industry