The [npm Inc. was right](https://graphqleditor.com/blog/javascript-predictions-for-2019-by-npm/), 2019 was a great year for GraphQL.
Let's take a look at the all good things that happened for GraphQL in 2019.

## January

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

![GraphQL Inspector CLI](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/inspector.webp)

## March

[AWS](https://aws.amazon.com/blogs/opensource/aws-joins-the-graphql-foundation/) **&** [IBM](https://developer.ibm.com/blogs/ibm-joins-the-graphql-foundation-to-push-for-open-source-adoption/) **joins the GraphQL Foundation!** - GraphQL Foundation is the GraphQL community aiming to enable widespread GraphQL adoption. AWS & IBM joining it is a strong signal that GraphQL has a bright future.
![GraphQL Foundation](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/foundation.webp)

[Apollo Client 2.5 was launched](https://www.apollographql.com/blog/announcement/announcing-apollo-client-2-5-c12230cabbb7) - a new version of Apollo Client was launched which merges local state management into the core library which has enabled a lot of cool features.

![Local state management with Apollo Client](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/apollo.webp)

## June

[Postman v7.2 Supports GraphQL](https://blog.postman.com/postman-v7-2-supports-graphql/) - Postman joined the group of companies acknowledging the GraphQL qualities and has recently announced the support for GraphQL in their service. The latest release of Postman v7.2 enabled sending GraphQL queries in the request body, GraphQL variables & GraphQL query autocompletion.

[Apollo Raises $22 Million](https://www.apollographql.com/blog/announcement/apollo-raises-22-million-to-simplify-app-development-ee30502c81b3) - Apollo raised a nice amount of $22 million to continue its mission to give a GraphQL-based data graph to every app developer in the world

[GraphQL Conf Berlin](https://graphql.org/conf/) - GraphQL Conf is a non-profit GraphQL conference organized by Prisma and Honeypot where industry experts from all around the world present GraphQL best practices and many more. In case you missed it, talks from GraphQL Conf 2019 are available on [Prisma's YouTube channel](https://www.youtube.com/playlist?list=PLn2e1F9Rfr6kChXoURShhO3A-4r8FLYsO)!

![GraphQL Conf](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/conf.webp)

**GraphQL: The Documentary** - the story of why and how GraphQL came to be and the impact it's having on big tech companies worldwide, including Facebook, Twitter, Airbnb & Github.

[https://www.youtube.com/watch?v=783ccP\_\_No8](https://www.youtube.com/watch?v=783ccP__No8)

## July

[Dgraph raises $11.5 million](https://dgraph.io/blog/post/how-dgraph-labs-raised-series-a/) - Dgraph is a horizontally scalable and distributed graph database, with a goal to provide enterprise-level scale and throughput, with low enough latency to be serving real-time user queries. Dgraph supports GraphQL-like query syntax, responds in JSON and Protocol Buffers over GRPC and HTTP.

![Dgraph](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/dgraph.webp)

## August

[Apollo Client supports React Hooks](https://www.apollographql.com/blog/announcement/frontend/apollo-client-now-with-react-hooks) - React 16.8 introduced a new way to write stateful components while avoiding the pitfalls of classes - the Hooks. Apollo Client now includes three hooks that you can implement in your app where corresponding higher-order component being used or render prop component: `useQuery`, `useMutation` &`useSubscription`.

## October

[Apollo Client 3 Beta](https://www.apollographql.com/blog/announcement/previewing-the-apollo-client-3-cache-565fadd6a01e) - Caching is considered by many developers as one of the GraphQL weaknesses. The Apollo team is on a mission to change that. New released Apollo Client 3 Beta contains some serious cache improvements.

[Graphql Editor 2.0](https://graphqleditor.com/blog/graphql-editor-new-release/) - a new version of GraphQL Editor packed with many micro-features to help developers save a lot of time & effort creating their GraphQL based APIs.

[![GraphQL Editor](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/graphqleditor.webp)](https://graphqleditor.com/)

[GraphQL Summit 2019](https://summit.graphql.com/) - GraphQL Summit is event of the year in GraphQL world. It's a world's largest conference dedicated to GraphQL, this year's edition featured over 60 technical talks across 3 tracks. Conference recordings are available here:

[https://www.youtube.com/watch?v=EDqw-sGVq3k\&list=PLpi1lPB6opQyraZSmwFre\_FpL00\_3nTzV](https://www.youtube.com/watch?v=EDqw-sGVq3k\&list=PLpi1lPB6opQyraZSmwFre_FpL00_3nTzV)

2019 in a summary - GraphQL perspective

Ready for take-off?

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 cache: using LRU cache with GraphQL Zeus

Unlocking the Power of React 19

Welcome to a short post about a recent quality of life update to [GraphQL Zeus](/docs/zeus). If you're not familiar with [GraphQL Zeus](/docs/zeus) go ahead and read my [earlier post which breaks down its basics](/what-is-graphql-zeus). If you are lets go ahead and talk about the update!

### Graphql Fragments

GraphQL has long supported reusable fields natively with the use of fragments. If you're not familiar with them basically if you had the same fields in multiple queries you could define a fragment - a set of fields, and then reuse it instead of repeating all the fields every time. Lets say you had a user with some fields like name, email, address. Then you could use a fragment like this:

```ts
query getUser {
  user(id: 4) {
    ...userFields
  }
}

fragment userFields on User {
  name,
  email,
  address,
  avatar
}
```

For reusability you could put all your fragments in a fragments.js file and then use them across a project. Zeus already had a solution like Selectors (which work a bit similarly to that) but with the latest update it can now go a step further! :)

### Zeus fields - GraphQL spread operator

For our example lets say we need to get the posts data for our blog page where we display them in a grid, usually the query that would look something like this:

```ts
const posts = await Chain('http://example.com/api/graphql')('query')({
  posts: [
    {
      title: true,
      coverImage: true,
      publishedAt: true,
      slug: true,
      content: { markdown: true },
    },
  ],
});
```

With Zeus 6.0.0 you can simply use a spread operator `...fields` with the TypeScript type from the schema (eg. `Post`) to simply get all the fields available for that type:

```ts
const posts = await Chain('http://example.com/api/graphql')('query')({
  posts: [
    {
      ...fields('Post'),
    },
  ],
});
```

### Never go full REST

With this, we now have a convenient quality-of-life improvement for cases where you just want to quickly retrieve all the fields for a type. That said it's important to remember what GraphQL is all about - getting exactly what you requested without overfetching. So don't just use `...fields` everywhere or you'll defeat the entire purpose of using GraphQL in the first place and turn it into REST, always pulling way more data than necessary.


2019 in a summary - GraphQL perspective

January

March

June

July

August

October

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