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?

Unlocking the Power of React 19

Welcome to a short post about a recent quality of life update to GraphQL Zeus. If you're not familiar with GraphQL 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.


Zeus update - GraphQL spread operator

GraphQL Zeus is codegen which, with the use of just one command, generates Typescript types for your GraphQL schema. From there even a junior frontend dev can easily handle writing type-safe requests to the backend, and do so without asking backend devs or even looking at the schema. To showcase how easy it is lets go over the installation and some basic use cases.

### Installation and example query

1. Obviously first we need to install it in our project using `npm i graphql-zeus`.
2. Once it finishes installing we need to point it to our schema url using the command `zeus http://example.com/your-schema-url/`. Zeus will then generate types for everything in that schema and put that in a file in its folder so that you can easily import it across your project.

### Queries

Now we can begin writing type safe requests. Lets say our example will be a simple query which fetches reviews which we then put into a table, list, carousel or whatever else on our website:

```ts
const reviews = await Chain('http://example.com/your-schema-url/')('query')({
  listReviews: [
    {
      author_name: true,
      rating: true,
      content: true,
    },
  ],
});
```

That will give us all the reviews as an array, we can then easily map over it to create some simple component like this:

```ts
{
  reviews.map((review, idx) => {
    return (
      <div key={idx} className="flex flex-col">
        <h3>{review.author_name}</h3>
        <div>{'★'.repeat(review.rating)}</div>
        <p>{review.content}</p>
      </div>
    );
  });
}
```

Queries follow a simple structure: we use square brackets for their contents and then:

- in the first curly brackets we put the query payload ie. what we're sending to the backend (for example the id of the item we want to get, the locale or the access token for a login query)
- in the second curly brackets we specify which fields we want to receive

Following our example lets say we're interested in getting our reviews in only one language - then we would have to specify that in the query payload(autocomplete is your friend here and will tell you exactly what you can input there):

```ts
const reviews = await Chain('http://example.com/your-schema-url/')('query')({
  listReview: [
    { locale: 'pl' },
    {
      author_name: true,
      rating: true,
      content: true,
    },
  ],
});
```

### Mutations

With mutations instead of retrieving data, we're sending it to the backend to make changes. The structure is the same as with queries, two sets of curly brackets:

- in the first brackets one we include the inputs ie. what we want to change (like add a new review or modify an existing one by id)
- in the second brackets we specify what we want to get back after the mutation runs, which is usually a confirmation that the mutation was successful

Sticking with our previous example we can create a mutation to submit reviews:

```ts
const newReview = await Chain('http://example.com/your-schema-url/')(
  'mutation',
)({
  createReview: [
    { input: { author_name: 'John', rating: 5, content: 'Great product!' } },
    {
      id: true,
    },
  ],
});
```

This will only create a 5 star review by John with that content. Most likely you'd want to link that to some small form component which lets users write reviews and sends that mutation with the data on submit or something similar.

### Use with CMS (Hygraph)

If we're reusing queries or mutations across our project it makes little sense to keep writing them out like that. It makes more sense to put them in a specific file and then import them as needed. For this example lets say we're pulling data from a CMS like Hygraph, we can create a file called `requests.ts`. Then at the top of it we can create a custom Chain which will handle the url and authorization (we'll be using it for all our queries and mutations since Hygraph wont let us through otherwise):

```ts
export const chain = Chain(process.env.CMS_URL!, {
  headers: {
    Authorization: `Bearer ${process.env.CMS_TOKEN}`,
  },
});
```

Now we can create a query to get all our blogposts from the CMS and even limit those to only the ones in English and only those in the Published stage o that we avoid getting drafts and such:

```ts
export const getPosts = async () => {
  return await chain('query')({
    posts: [
      {
        stage: Stage.PUBLISHED,
        locales: [Locale.en],
      },
      {
        title: true,
        author: true,
        coverImage: true,
        publishedAt: true,
        slug: true,
        content: { markdown: true },
      },
    ],
  });
};
```

From here using it in our component is a simple as doing a const and then putting the data in a map, list, carousel or whatever we want.

```ts
const blogposts = await getPosts();
{
  blogposts.map((blogpost, idx) => {
    return <BlogCard key={idx} />;
  });
}
```

GraphQL's core concept is getting only what you request without overfetching so if we want to get just one blogpost we'll need a specific query for that. Lets say we want to make dynamic pages for our blogposts using slugs, for that we'll need to pass that to the CMS in the payload and then we'll receive only the post we asked for. We also need to throw an error in case an incorrect slug was provided or something else went wrong, so lets use a simple try catch:

```ts
const getPostBySlug = async ({ slug }: { slug: string }) => {
  try {
    const result = await Chain('query')({
      post: [
        {
          stage: Stage.PUBLISHED,
          locales: [Locale.en],
          where: { slug: slug },
        },
        {
          title: true,
          author: true,
          coverImage: true,
          publishedAt: true,
          slug: true,
          content: { markdown: true },
        },
      ],
    });
    return result;
  } catch (error) {
    console.error('Could not get post, error:', error);
    throw error;
  }
};
```

### Zeus Selectors

Writing out all the fields we want returned every single time would be cumbersome, and that's where Selectors come in. Since Zeus generates types for the entire schema it makes writing Selectors much easier with the use of autocomplete and type-safety. As we were querying for blogposts it makes the most sense to go with a Post Selector as an example:

```ts
export const postSelector = Selector('Post')({
  title: true,
  author: true,
  coverImage: true,
  publishedAt: true,
  slug: true,
  content: { markdown: true },
});
```

Thanks to that instead of writing out all the fields we can just use a selector like this:

```ts
export const getPosts = async () => {
  return await chain('query')({
    posts: [
      {
        stage: Stage.PUBLISHED,
        locales: [Locale.en],
      },
      postSelector,
    ],
  });
};
```

And that's all for the basic use cases, hopefully this guide was simple enough to follow and now you're ready to use Zeus for your projects and find out yourself how handy it is for working with the backend. I can say it definitely worked wonders for me as a very junior frontend dev. If you have any questions or want to know more, feel free to reach out and stay tuned for the next post, where I’ll dive into a recent update to Zeus and how it can make things even easier!


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