There are two difficult problems in computer science: naming, caching, and off-by-one errors.
(More introduction needed)
This post will explore multiple caching strategies in a federated GraphQL system, from local caching and memoization to distributed caching.
You can find the code describing each strategy here.
Our initial architecture is pretty simple:
Before there was GraphQL, there was REST.
In recent years, REST has become the dominant API style for building backend web services. With REST, you could signal the type of request we want to make (ex: GET, POST, PUT, or DELETE) and the resource we’d like to fetch or interact with (ex: /api/pets/1) using an HTTP method and a URL.
It’s a great approach — one we initially used at StockX for several years — but REST comes with some downsides:
At StockX, our engineering team had to move quickly to build out the systems required to support our rapidly expanding business. When you’re in that mindset of build build build, you can forget to take the time to look at your architecture holistically. For each new use-case, we had to support, our engineering team built custom RESTful API endpoints with particular functionality. …