[GraphQL](https://graphql.org/) is really about collaboration, and the teams that get furthest are those who can work seamlessly together on their GraphQL API.

This idea is well-known for the members of [The Guild](https://github.com/the-guild-org) know from open-sourcing amazing graphql tools. Its members work constantly on new solutions aiming to automate & increase the type-safety of our GraphQL projects. After open-sourcing such tools as [GraphQL Code Generator](https://the-guild.dev/graphql/codegen) or [GraphQL Modules](https://the-guild.dev/graphql/modules), their next work seen daylight - the [GraphQL inspector](https://the-guild.dev/graphql/inspector)

[GraphQL Inspector](https://the-guild.dev/graphql/inspector) is a tool published by [Kamil Kisiela](https://github.com/kamilkisiela/), that detects changes, similar or duplicated types, validates documents against a schema and looks for deprecated usage.

![](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/inspector1-1730752662320.webp)

**Key features/commands:**

* [diff](https://the-guild.dev/graphql/inspector/docs/commands/diff) - that detects breaking or dangerous changes,
* [validate](https://the-guild.dev/graphql/inspector/docs/commands/validate) - validates documents against a schema & searches for deprecated usage,
* [similiar](https://the-guild.dev/graphql/inspector/docs/commands/similar) - lists similar types in order to find duplicates,
* [coverage](https://the-guild.dev/graphql/inspector/docs/commands/coverage) - finds unused parts of GraphQL Schema based on clients’ fragments & operations.

The tool is available as:

* [CLI tool](https://the-guild.dev/graphql/inspector/docs/installation)
  ![](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/inspector2-1730752756946.webp)
* [Github Application](https://github.com/apps/graphql-inspector)![](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/inspector3-1730752769833.webp)

##### Source: [GraphQL Inspector](https://the-guild.dev/graphql/inspector)

There is also a [programmatic API](https://the-guild.dev/graphql/inspector/docs/api/schema) available in case you want to build something on the top of it on your own.

GraphQL Inspector

Ready for take-off?

In the evolving landscape of front-end development, state management libraries are at the heart of building robust, scalable applications. Over the years, developers have had a plethora of tools to choose from, ranging from the classic Redux to newer contenders like Zustand, Recoil, and Jotai. Yet, as the front-end ecosystem has grown, many developers have labeled Redux as "outdated" or "too complex" and opted for seemingly simpler solutions. But is Redux really obsolete, or is it simply being misused?

Let’s take a closer look at the state of state management, the reasons behind Redux’s diminishing popularity, and how you can use it effectively without falling into common pitfalls.

## **The Current Landscape of State Management Libraries**

State management has never been a one-size-fits-all scenario. As applications grow in complexity, developers often face challenges in maintaining state consistency, scalability, and performance. Modern libraries like Zustand, Recoil, and Jotai have gained traction because they offer:

1. **Simplified APIs:** These libraries reduce boilerplate, making it quicker to implement and manage state.
2. **Fine-grained reactivity:** Zustand and Jotai, for instance, allow for selective updates, ensuring only components dependent on specific pieces of state re-render.
3. **Modern React paradigms:** These libraries align closely with React’s modern features, such as hooks, context, and concurrent rendering.

In contrast, Redux’s verbose syntax and perceived complexity have led developers to dismiss it as antiquated. However, this perception is often rooted in misapplication rather than inherent flaws.

## **Why Redux Fell Out of Favor**

1. **Boilerplate Overhead:** Early Redux implementations required a significant amount of boilerplate code for actions, reducers, and selectors. This led to frustration, especially for smaller projects where such structure felt over-engineered.


2. **Misuse as a Global Store:** Many developers adopted Redux to manage all application state, including local UI state, which added unnecessary complexity. Redux is best suited for managing **global state** that spans across components, such as authentication, user settings, or shared data between distant parts of an application.


3. **React’s Built-in Solutions:** React itself has evolved to include excellent solutions for state management. With tools like **useState,** **useReducer,** and **useContext,** many state management needs can be addressed natively without requiring additional libraries. These solutions are often simpler and more aligned with React’s core principles.
4. **Slow Adoption of Modern Features:** For a time, Redux lagged in adopting modern React patterns. With the advent of hooks and functional components, other libraries integrated these paradigms more seamlessly.
5. **Lack of Guidance:** Redux’s flexibility is both its strength and its downfall. Without clear guidance, developers often misuse it, leading to poorly structured and hard-to-maintain applications.

## **Making Redux Work for You**

Redux remains a powerful and viable state management solution when used correctly. Here’s how to make the most of it:

### **1. Embrace Redux Toolkit**

Redux Toolkit (RTK) addresses many of the issues developers faced with vanilla Redux. It simplifies common patterns, reduces boilerplate, and includes utilities like:

* **createSlice:** Combines actions and reducers into a single definition.
* **createAsyncThunk:** Streamlines async operations and side effects.
* **immer:** Handles immutable updates without the complexity of writing pure functions manually.

By adopting RTK, you can achieve the same structure and scalability as classic Redux with a fraction of the code.

### **2. Focus on Global State**

Reserve Redux for managing state that truly needs to be global. Use React’s **useState** or **useReducer** hooks for local component state. By compartmentalizing state management, you can reduce unnecessary complexity and improve maintainability.

### **3. Leverage Modern React Features**

Take advantage of React’s concurrent features and hooks. For example:

* Use **useSelector** with memoization libraries like Reselect to optimize component re-renders.
* Combine Redux with context selectively for specific use cases, such as sharing theme settings or locale data.

### **4. Keep Middleware Lightweight**

While tools like Redux-Saga and Redux-Thunk are powerful, they’re not always necessary. Consider simpler alternatives, such as RTK Query, for managing API calls and caching. This reduces complexity and keeps your codebase lean.

### **5. Measure Before You Replace**

Switching to a new library often introduces a new learning curve and technical debt. Evaluate whether the benefits of moving away from Redux outweigh the cost. In many cases, optimizing your existing Redux implementation can yield better results than migrating to a new solution.

## **Conclusion**

Redux isn’t dead - it’s **evolving**. The introduction of Redux Toolkit has made it more accessible and efficient, ensuring it remains a relevant option for state management in modern applications. The key is to use it wisely, reserving it for scenarios where its architecture truly shines. By adopting best practices and leveraging modern tools, you can harness the power of Redux without falling into the traps that give it a bad reputation.

So before you declare Redux obsolete, take a step back and ask: Am I using it correctly?

Redux Isn’t Dead, You’re Just Using It Wrong

For GraphQL cache can significantly improve performance and reduce redundancy, particularly when the same data is queried multiple times within a short timeframe. In this post, I'll go over implementing caching using [GraphQL Zeus](/docs/zeus) to fetch data from our custom CMS. No worries this can also be applied just as effectively to other GraphQL APIs, such as Hygraph or Hasura. Whether you’re working with a headless CMS, an e-commerce backend, or any other GraphQL-powered service, caching is just as important in every scenario and the implementation should look very similar.

## Why Add Caching?

Caching provides a number of advantages like:
 -  Reduced Server Load: By serving repeated requests from the cache, you avoid making unnecessary calls to the GraphQL server, which can be essential for scaling applications with high traffic.
 - Improved Performance: frequently requested data can be served directly from memory, reducing query response time significantly
 - Cost Efficiency: if your GraphQL API usage is metered (e.g., cloud-based APIs), caching significantly reduces the number of queries made, saving on usage costs

## [GraphQL Zeus](/docs/zeus) query example

Let’s start with a simple query I made using [GraphQL Zeus](/docs/zeus), which fetches homepage data from our CMS:

```ts
export const getHomepageData = async () => {
  try {
    const result = await chain('query')({
      onehomepageBySlug: [{ slug: 'home' }, HomepageDataSelector],
    });
    return result;
  } catch (error) {
    console.error('failed to fetch home data', error);
  }
};
```

This query retrieves all the homepage data at once and passes it to the relevant components. This allows users to update the homepage content directly through the CMS without needing to modify any code. Currently, this function is called in server-side props, meaning it triggers an API call every time the page is refreshed or visited.

To optimize this and reduce redundant API calls, we’ll implement caching by using the [node-lru-cache](https://github.com/isaacs/node-lru-cache) library.

## LRU cache

LRU stands for "Least Recently Used," a caching strategy that automatically removes the least recently accessed items when the cache reaches its limit. The node-lru-cache library offers several configuration options, but in our case to set up a basic GraphQL cache, we only need two key settings:

 - `ttl` (Time to Live): This setting defines how long an item stays in the cache before it’s considered expired, specified in milliseconds.
 - `ttlAutopurge`: When enabled, this option automatically deletes expired items from the cache. Without it, expired items are only purged when the cache is next accessed which can potentially lead it to grow unbounded.
 
```ts
import { LRUCache } from 'lru-cache';

const cache = new LRUCache({
  ttl: 1000 * 60 * 5, // Set time to live to 5 minutes
  ttlAutopurge: true,  // Automatically clean up expired entries
});
```

## Caching the query

To cache the query I mentioned earlier, we need to do three simple things:
1. Set up a cache key: This helps the cache know which entry to return when the same data is requested. You can name the key however you like, but it has to be unique to avoid conflicts.
2. Check if the cache contains the result: If the cache has the entry for that key, return the cached result.
3. Store the query result in the cache: After fetching the data, save the result in the cache for future use.

```ts
export const getHomepageData = async () => {
  const cacheKey = 'homepageData'; // Cache key for this entry
  if (cache.has(cacheKey)) { // Check if the cache contains this key
    return cache.get(cacheKey) as { onehomepageBySlug: HomepageDataType }; // Return cached result
  } 
  try {
    const result = await chain('query')({
      onehomepageBySlug: [{ slug: 'home' }, HomepageDataSelector],
    });
    cache.set(cacheKey, result); // Store query result in the cache
    return result;
  } catch (error) {
    console.error('failed to fetch home data', error);
  }
};
```

This approach results in two scenarios:

 - First visit: The query runs, fetches the data, and caches it for future use.
 - Subsequent visits (within the TTL): The cached result is returned, avoiding the need to make a new API request.

## Query with params (slug, locale)

As mentioned earlier, the cache key must be unique to avoid conflicts. This is especially important for queries that include parameters, such as `locale` (for localization) or `slug` (for specific blog pages). Without unique cache keys, you may end up with the same content being served for different locales or blog pages. To avoid this, it's best to use a dynamic cache key based on the query parameters.

```ts
export const getBlogpostBySlug = async ({ slug }: { slug: string }) => {
  const cacheKey = `Blogpost:${slug}`; // Unique cache key based on the slug
```

By using this dynamic approach, we ensure that the correct data is returned for the given slug. If you were to use a static cache key like 'blogpost', you'd always get the first cached blog post, regardless of which slug is provided. The same issue would arise with localization: without unique keys, you'd end up serving the wrong content for different locales.

## Its all about performance

GraphQL is all about efficiency — retrieving only the data you need (unlike REST). It makes sense to take that a step further to further enhance performance. With a GraphQL cache setup like this we can reduce redundant API calls and significantly speed up queries, especially for frequently accessed data like homepage content or blog posts. Dynamic cache keys based on query parameters ensure that the data is correctly localized or filtered according to specific slugs and [GraphQL Zeus](/docs/zeus) and selectors keep everything type-safe. Together this solution can greatly improve your app's speed and scalability. As mentioned, even if you're not using [GraphQL Zeus](/docs/zeus), the implementation should still be very similar to the above, so give it a try!
  

GraphQL Inspector

Source: GraphQL Inspector

Check out our other blogposts

Ready for take-off?

Elevate your work with our editor that combines world-class visual graph, documentation and API console