
This time let’s take a look at another important aspect of [GraphQL](https://graphqleditor.com/) vs REST discussion - the PERFORMANCE.


## GraphQL = performance vs REST = reliability 

The main GraphQL quality is being less loquacious than traditional [REST API](https://www.restapitutorial.com/lessons/whatisrest.html).  GraphQL treats performance as its top priority while REST is focused on keeping services reliability as their main objective. Even if a REST API returns only a basic partial, it is still transferring more data, while GraphQL is always aiming for the smallest possible request. In an example, if the client needs a field, they request it, and if the API adds a new field, clients don't get it, unless it's being added into the GraphQL query.


## No wasted bits over the wire

You all have seen APIs where you need to `GET /author` first and then fetch each book individually via `GET /author/:id/books/:id` endpoint. This result in n+1 queries, a  well-known performance issue face in REST APIs.  While REST API calls are chained on the client side before the final representation can be formed for display, in GraphQL its simplified by enabling the server to combined all the data for the client within a single query which results in less bits being transferred over the wire.

```gql
{
  author (id: "1") {
    name
    book (id: "5") {
      title
    }
  }
}
```
```ts
{
  "data": {
    "author: {
      "name": "George R.R. Martin",
      "book": [
        {
          "title": "A Dance with Dragons"
        }
      ]
    }
  }
}
```

## Conclusion

[GraphQL](https://graphql.org/) is faster than [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) because as you can pick the fields you want to query, so the request will always be the smallest possible. Additionally, with GraphQL, you can enquire multiple entities in one request,  and because less bits will be transferred over the wire so your projects will perform faster than while using [REST](https://en.wikipedia.org/wiki/Representational_state_transfer).





GraphQL vs REST Performance

GraphQL is a query language for APIs and a runtime for fulfilling these queries with your existing data. The technology makes it possible for clients to request data that they exactly need, nothing more. GraphQL queries not only have access to the properties of a single source but also easily track references between them. While typical REST APIs require loading from multiple URLs, GraphQL APIs get all the data your app needs in a single request, making applications using GraphQL a lot faster, even on mobile network connections.

As you already know [npm Inc.](https://www.npmjs.com/) claims that the [GraphQL is going to be a tech force to reckon in 2019](https://graphqleditor.com/blog/javascript-predictions-for-2019-by-npm/). There is no better way to start your journey with GraphQL than use the most popular client library which is [Apollo GraphQL](https://www.apollographql.com/).

## What’s Apollo GraphQL?

Apollo is an implementation of GraphQL created to address the specific needs of modern development teams building data-driven applications. It adopts an agile, scalable approach that takes extra care not to modify existing APIs and services. The library puts an emphasis on tooling and workflows. The Apollo GraphQL platform is a stack of open source components, commercial extensions, and cloud services.

![structure.webp](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/structure.webp)

Source: [Apollo Docs](https://www.apollographql.com/docs/)

## Most of the core components are open source

Apollo is an open source company, focused on what developers really need, and with a clear mission which is providing a better GraphQL experience for everyone. The collaboration of hundreds of developers working on Apollo Client, Apollo Server, as well as other components of the Apollo platform, makes it an industry-leading solution for GraphQL implementations.

Source: [Apollo](https://www.apollographql.com/)

[Apollo Server](https://github.com/apollographql/apollo-server) is a JavaScript GraphQL server for defining a schema and a set of resolvers that implement each part of that schema. An Apollo Server is extensible which means plugins can hook into each stage of the request pipeline. This is a great feature that allows implementing custom behaviors as add-on packages. Apollo Server works with any GraphQL schema built with GraphQL.js, serverless environments such as AWS Lambda and is open source and community-maintained.

[Apollo Client](https://github.com/apollographql/apollo-client) is a full-featured GraphQL client that manages data and state in your app. It enables a declarative programming style that allows developers to define queries as part of UI components while the client manages all query binding, manages consistency, caching, and much more.  Apollo Client includes integrations with the most popular View lawyers such as React, React Native or Vue.

[Apollo iOS](https://github.com/apollographql/apollo-ios) is a strongly-typed GraphQL caching client for iOS written in Swift. It allows the execution of queries and mutations on a GraphQL server and returns the results as query-specific Swift types. This means that you do not have to deal with parsing JSON or making the client to cast values to the right type manually. Model types are generated from the GraphQL definitions your application's UI.

[Apollo Android](https://github.com/apollographql/apollo-kotlin) is a GraphQL client for generating Java models from GraphQL queries, giving you a typesafe API to work with your GraphQL servers. Although it’s designed mainly for Android, you can use it in any Java/Kotlin app.

[Apollo CLI](https://github.com/apollographql/apollo-tooling) is a simple command line client that merges your GraphQL clients and servers with features such as validation of your GraphQL schema, securing compatibility of your server operations, or generating static types for client-side type security.

## A solution for development teams

GraphQL is all about collaboration. Development teams that work collaboratively on their GraphQL API achieve the best results. To facilitate this collaboration Apollo team created some useful solutions such as:

* Schema Registry - a registry for GraphQL schemas that functions as a central source of truth for a schema, enriched with additional metadata such as field-level usage statistics.
* Client registry — a registry to track each known schema user, both pre-registered and ad-hoc consumers.
* Operation registry — a registry of all the known operations against the schema
* Trace warehouse — a data pipeline that stores a detailed log of every operation performed against your schema. All these registries work collectively to give your development team a good understanding of the API.
* Safelisting - locking your API down to trusted, pre-registered operations. Apollo CLI extracts all the queries from a client codebase and stores it in the operation registry. Separately, an Apollo Server plugin synchronizes the list of pre-registered operations to the server, which then rejects queries that aren’t present in its local copy.
* Schema validation - which tests a proposed schema against the known set of operations observed in production, returning a list of affected clients for each breaking change.
* GraphQL Gateway - a configuration of Apollo Server, along with some add-ons that functions as a GraphQL Gateway. The gateway composes separately deployed “micro-schemas” that reference each other into a single master schema, which looks to a client just like any regular GraphQL schema. To answer queries, the gateway builds a query plan, fetches data from each upstream GraphQL service, and assembles it all back together into a single result.

![graphql.webp](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/graphql.webp)

Apollo GraphQL - a short overview


## Fields 

At its purest, GraphQL is about asking for specific fields on objects. Let's start by looking at a very easy query:

```gql
{
  user {
    name	
  }
}
```
```gql
{
  "data": {
    "user": {
      "name": "James"
    }
  }
}
```

You can see quickly that the query has the same shape as an output. This is fundamental to GraphQL, because you always get back what you expect. 

The field name returns a String type. The query above is interactive. That means you can change it as you like and see the new result. Try adding an appears. In field to the user object in the query, and see the new result.

In the previous case, we just asked for the name of our user which returned a String, but fields can also commit to Objects. In that case, you can get a sub-selection of fields for that object. GraphQL queries can cross related objects and their fields, allowing customers to get lots of associated data in one request, instead of making many round trips as one would need in a classic REST architecture.

```gql
{
  player {
    name
    # You can add comments!
    friends {
      name
    }
  }
}
```
```gql
{
  "data": {
    "player": {
      "name": "James",
      "friends": [
        {
          "name": "Adam"
        },
        {
          "name": "Paul"
        },
        {
          "name": "Chris"
        }
      ]
    }
  }
}
```

Note that in this sample, the friends field returns an collection of items. GraphQL queries look the same for both individual items or lists of items, however we understand which one to expect based on what is indicated in the schema.

## Aliases

If you have a fine eye, you may have discovered that, since the result object fields match the name of the field in the query but don't include arguments, you can't directly query for the same field with various arguments. That's why you require aliases - they let you rename the result of a field to anything you want.

```gql
{
  bluePlayer: player(team: BLUE) {
    name
  }
  blackPlayer: player(team: BLACK) {
    name
  }
}
```
```gql
{
  "data": {
    "bluePlayer": {
      "name": "Superman"
    },
    "blackPlayer": {
      "name": "Batman"
    }
  }
}
```

In the previous instance, the **player** fields would have clashed, but since we can alias them to different names, we can get both results in one request.

## Arguments

If the only thing we could do was traverse objects and their fields, GraphQL would already be a beneficial language for data fetching. But when you add the ability to pass arguments to fields, things get much more impressive.

```gql
{
 player(id: "1") {
    name
    weight
  }
}
```
```gql
{
  "data": {
    "player": {
      "name": "James",
      "weight": 80
    }
  }
}
```

In practice like REST, you can only pass an individual set of arguments - the query parameters and URL segments in your request. However, in GraphQL, every field and a nested object can get its set of cases, causing GraphQL a total replacement for doing many API fetches. You can even pass arguments into scalar fields, to complete data transformations once on the server, alternately of on each client separately.

```gql
{
 player(id: "1") {
    name
    height(unit: CM)
  }
}
```
```gql
{
  "data": {
    "player": {
      "name": "James",
      "height": 180
    }
  }
}
```


Arguments can be of many various types. In the above sample, we have adopted an Enumeration type, which describes one of a finite set of options (in this case, units of length, either METER or FOOT). GraphQL comes with a default set of types, but a GraphQL server can also declare its own custom types, as long as they can be serialized into your transport format.

## Fragments

Let's say we had a moderately complex page in our app, which let us look at two players along with their friends. You can imagine that such a query could quickly get difficult because we would need to repeat the fields at least once - one for each side of the comparison.

That's why GraphQL covers reusable units called fragments. Fragments let you create collections of fields, and then add them in queries where you need to. Here's a sample of how you could solve the above situation using fragments:

```gql
{
  leftComparison: player(team: BLUE) {
    ...comparisonFields
  }
  rightComparison: player(team: Black) {
    ...comparisonFields
  }
}
fragment comparisonFields on Character {
  name
  friends {
    name
  }
}
```
```gql
{
  "data": {
    "leftComparison": {
      "name": "Superman",
      "friends": [
        {
          "name": "Lois Lane"
        },
        {
          "name": "Martha Kent"
        },
      ]
    },
    "rightComparison": {
      "name": "Batman",
      "friends": [
        {
          "name": "Joker"
        },
        {
          "name": “Catwoman”
        },
        {
          "name": "Leia Organa"
        }
      ]
    }
  }
}
```


You can see how the above query would be much repeated. The concept of fragments is usually used to split complex application data requirements into tinier pieces, especially when you need to join lots of UI components with different fragments into one initial data fetch.


## Operation name 

Until now, we have been practising a shorthand syntax where we omit both the query keyword and the query name, but in live apps, it's useful to use these to make our code less ambiguous.

Here’s an example that includes the keyword query as operation type and operation name:

```gql
query PlayerNameAndFriends {
  player {
    name
    friends {
      name
    }
  }
}
```
```gql
{
  "data": {
    "player": {
      "name": "James",
      "friends": [
        {
          "name": "Adam"
        },
        {
          "name": "Paul"
        },
        {
          "name": "Chris"
        }
      ]
    }
  }
}
```


The operation type is either query, mutation, or subscription and defines what kind of operation you intend to do. The operation type is required unless you're using the query shorthand syntax, in which case you can't supply a name or mutable definitions for your operation.

The operation name is an important and explicit name for your operation. It is demanded in multi-operation documents, but its use is encouraged because it is beneficial for debugging and server-side logging. When something runs crazy either in your network logs or your GraphQL server, it is easier to identify a query in your codebase by name somewhat of trying to decipher the contents. Think of this just like a function name in your desired programming language. For example, in JavaScript we can easily work only with anonymous functions, but when we give a function a name, it's easier to track it down, debug our code, and log when it's called. In the same way, GraphQL query and mutation names, along with fragment names, can be a useful debugging tool on the server side to identify different GraphQL requests.



GraphQL Tutorial - Queries and mutations Part 1

npm, Inc., which runs the world’s biggest software registry and maintains the ‘npm’ software development tool has shared some very interesting read about insights and predictions about JavaScript for 2019 and it's going to be a great year for GraphQL!

The co-founder and Chief Operating Officer of npm during his lecture at the Node+JS Interactive 2018 event made some predction about there direction the web development sector is heading, the future of JavaScript and more. He also covered some development tools used within the npm community, discussed best practices, rising-star frameworks and those fading into oblivion. The predictions were made based on insights reflect feedback from 16,000 developers on JavaScript usage trends and best practices and the top four predictions are:

## 1: You will abandon one of your current tools

Nothing lasts forever and this is very true for frameworks and tools in JavaScript. The average peak phase of popularity lasts from three to five years and is followed by a slow decline, as organizations have to maintain their existing applications, but have already moved to newer frameworks for new projects. For developers, this basically means that it is better to learn new frameworks than to stick to their current tools too hard.

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

## 2: Somebody on your team will bring in TypeScript ...

... And you should be thankful! A survey of more than 16,000 developers showed that 46% of respondents used Microsoft's TypeScript - a proprietary JavaScript superset that compiles to regular JavaScript. The main reason for this conversion rate by enthusiasts may be the additional security TypeScript provides by type-checking. Adopting TypeScript in 2019 can give you real value, especially if you are a member of a larger team.

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

## 3: React will be the dominant framework in 2019; you’ll need to learn GraphQL

Despite the fact that React’s growth has slowed down during 2018, it still continues to dominate the web scene. The 60% of npm survey respondents said they are using React. The npm predicts that in 2019 more people will use React for building web applications which will lead to more tutorials, cases and bug's being fixed.

![](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/react-1730830642187.webp)Source: This year in JavaScript by npm

## 4: You’ll need to learn GraphQL

The 2019 will be the year of GraphQL. There is a strong likelihood that developers will use it in new projects in 2019 and afterwards. GraphQL, tracked by its most popular client library Apollo, continues to explode in popularity. GraphQL it’s going to be a technical force to reckon within 2019.



![](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/graphql-1730830678050.webp)
Source: This year in JavaScript by npm

## Tl;dr

GraphQL, React and TypeScript are the three technologies you will need to learn in 2019!

JavaScript predictions for 2019 by npm

## Is GraphQL a nail to the REST coffin or a tool to empower your REST APIs?

REST has become the standard for designing web APIs. It introduced some great ideas like stateless servers or structured access to resources. Over the past years REST API was the best (only) available solution but due to the rapid evolution of web development REST wasn't able to keep up with changing requirements of the clients that access them.

In 2012  the GraphQL was developed. The main goal for GraphQL was to solve many of the shortcomings and inefficiencies that developers were experiencing while working with REST APIs.

## Data Fetching with REST vs GraphQL

When using a REST API you would gather the data by accessing multiple endpoints. In the example, you would first call endpoint to fetch the initial user data, then make a sperate call to fetch its all properties.

![](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/rest-1730821347944.webp)
Source: [howtographql.com](https://www.howtographql.com/basics/1-graphql-is-the-better-rest/)

In GraphQL it’s handled totally different. The specification for queries is encoded in the client rather than on the server side. You would simply send a single query to the GraphQL server that includes the concrete data requirements and the server will respond with a JSON object where it will returns exactly what you required, nothing more.

![](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/gql-1730821359471.webp)
Source: [howtographql.com](https://www.howtographql.com/basics/1-graphql-is-the-better-rest/)

## Nothing is perfect

New approach definitely has its pros and fixed many issues that developers complained about while working with REST, but there are some issues that trouble both technologies and on some fields REST is still a better solution. To summarize cons and pros take a look at below juxtaposition.

|                                    | GraphQL | REST API |
| ---------------------------------- | :-----: | :------: |
| No Over/Under Fetching Problem     |    +    |     -    |
| Easy Fetching of Related Resources |    +    |     -    |
| Great Client Performance           |    +    |     -    |
| Easy Caching                       |    -    |     +    |
| Scoped Includes                    |    -    |     -    |
| Easy Deprecations                  |    +    |     -    |

GraphQL vs REST

2019 is going to be a good year for [GraphQL](https://graphql.org/). A lot of new tools to bridge the implementation gap, hundreds of interesting meetups across the whole globe and a couple conferences you can not afford to miss like the [GraphlQL Conf  in Berlin](https://graphql.org/conf/).

### **GraphQL Conf**

The [GraphlQL Conf](https://graphql.org/conf/) is the biggest, non-profit GraphQL conference in Europe. Speakers from all around the world are coming to talk about GraphQL best practices and the latest trends. GraphQL Conf Berlin is the best place to meet industry experts and become part of the rising GraphQL community. The last year edition gathered \~270 attendees and 19 speakers from across the world.

###### Source: [https://graphql.org/conf/](https://graphql.org/conf/)

### **Confirmed Speakers for 2019**

The line up for the upcoming year is not fully confirmed yet.  So far we have three speakers and it looks promising, just take a look!

**Lee Byron**
Ex-Facebook, [GraphQL](https://graphql.org/) co-creator
Currently responsible for designing, building software and teams at Robinhood - the app that lets you invest in the stock market for free, directly from your phone or desktop.

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

###### Source: [https://graphql.org/conf/](https://graphql.org/conf/)

**Dan Schafer**
[Facebook](https://developers.facebook.com/), [GraphQL](https://graphql.org/) co-creator
Dan Schafer is a software engineer at Facebook and a co-creator of GraphQL. He worked on the implementations of both GraphQL Mutations and Subscriptions.

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

###### Source: [https://graphql.org/conf/](https://graphql.org/conf/)

**Mirela Iclodean**
Software Engineer at [Twitter](https://twitter.com/)
Mirela is a software engineer at Twitter, working on TweetDeck. In the last year, she worked closely with Twitter’s GraphQL team to build the new Tweets streaming service using GraphQL Subscriptions.

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

###### Source: [https://graphql.org/conf/](https://graphql.org/conf/)

### **How to register?**

Viist the link below for more details on how to praticipate as a atendees or a speaker. See you in Berlin!

**GraphQL Conf Berlin 2019**
Date: June 20-21, 2019
Location: Berlin, Germany
Organizers: [Prisma](https://www.prisma.io/) and [Honeypot](https://www.honeypot.io/)
Link: [https://graphql.org/conf/](https://graphql.org/conf/)

The GraphQL conference you cannot miss

Hello This is third article of advanced typescript tutorial series. Today I'll cover basic usage of generic functions

```ts
type Point = {
  x?: number
  y?: number
  z?: number
}
const myFunc = <T extends Point>(args: T): T => {
  return args
}
```

As arguments I'll provide object containing Point properties. This function will only return Partial of `Point` based on provided paramaters in `args` argument;

```ts
const result = myFunc({
  x: 1,
  y: 1,
})
```

And the intellisense for such function is
![Typescript return correct args](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/tsreturnargs.webp)

As you see there is no `z` property here. Typescript aleready knows we provided these 2 args and it should return only them!

This part is super short as I can provide infinite number of generic functions usages. Thank you for your support on \`/r/typescript/ reddit ! It gives me power to write blog-post-a-day!

Advanced typescript tutorial - return based on args

Hello, This is the second article of the advanced typescript tutorial series. Today I'll cover the basic usage of

```ts
extends
```

keyword and conditional types. How does conditional type looks like?

```ts
type StringOrArray<T> = T extends string[] ? 'array' : T extends string ? 'string' : never
const a:string = "hello"
const b:string[] = ["hello","world"]
const c:number = 1

const d:StringOrArray<typeof a> = "string"
const e:StringOrArray<typeof b> = "array"
let f:StringOrArray<typeof c> 
```

So let's analyze this code:

1. We check if our generic Type is a string array
2. If it is array make type as string constant 'array'
3. If it does not check the type. If it is string make type as string constant 'string'
4. Else the type is never

To be the truth this code is useless but can give you some scope how `extends` keyword works. Next example will be a real-world example where we determine the type of the form field to give the user correct options.

```ts
type FieldType = "string" | "float" | "date"

type BaseField = {
    name:string
}

type Field<T extends FieldType> = BaseField & {
    value: T extends "string" ? string : T extends "float" ? number : T extends "date" ? Date : never
}

const stringField:Field<"string"> = {
    name:"myfield",
    value:"aaa"
}
const floatField:Field<"float"> = {
    name:"myfield",
    value:1.0
}

const dateField:Field<"date"> = {
    name:"myfield",
    value: new Date()
}
```

This is a little bit more advanced. What's going on with FieldType? It just checks the string converted to generic type to return correct type.

```ts

type FieldType = "string" | "float" | "date";
type BaseFieldExtended = {
  name: string;
  type: FieldType;
};
const FieldExtended = <T extends BaseFieldExtended>(
  baseField: T & {
    value: T["type"] extends "string"
      ? string
      : T["type"] extends "date"
      ? Date
      : T["type"] extends "float"
      ? number
      : never;
  }
) => baseField;

FieldExtended({
  name: "a",
  type: "string",
  value: "bbb"
});

FieldExtended({
  name: "a",
  type: "float",
  value: 12
});

FieldExtended({
  name: "a",
  type: "date",
  value: new Date()
});

```

And this is what typescript is made for. To provide complicated autocompletion stuff :). Wait for the next series of advanced typescript tutorial.

Advanced typescript tutorial - conditional types

## What is GraphQL?

GraphQL is an open-source data query and manipulation language for APIs.
In general, GraphQL is a syntax that describes how to ask & fetch the data from the server to the client. The response format is described in the query and defined by the client rather than the server. There are two basic types of queries in GraphQL:

- to fetch data from the server side (_get_)
- to manipulate you data (_create_,_update_,_delete_)

## The key concepts (principles)

GraphQL is not language specific, it's just a specification between the client and the server. Any client should be able to communicate with any server as long as they both speak GraphQL.

- **Hierarchical:** Most of today's product development work involves creating and manipulating view hierarchies. To achieve compatibility with the structure of the applications, the GraphQL query itself is a hierarchical set of fields. The query has a shape similar to the data it returns. It is a very natural way for product engineers to describe data requirements.

- **Product‐centric:** GraphQL is a product-oriented, driven by the demands of the views and front-end developer who write them. We begin with their way of mind and their requirements, and then build the language and runtime necessary for this purpose.

- **Strong‐typing:** GraphQL is strongly-typed. For a particular query, the tool can ensure that the query is both syntactically correct and correct in a GraphQL-type system before execution, i.e. at the time of query creation, and the server can have some guarantees as to the shape and nature of the response. This makes it easier to build high quality client applications.

- **Client‐specified queries:** In GraphQL, the query specification is encoded in the client and not on the server. These queries are defined at the detail level at field level. In the vast majority of applications written without GraphQL, the server specifies the data returned at various script endpoints. A GraphQL query returns exactly what the client asks for and nothing else.

- **Introspective:** GraphQL is introspective. Clients and other tools can query the type system using the GraphQL syntax as such. It is a powerful platform for building tools and client software, e.g. automatic processing of incoming data into strongly-typed interfaces.

## GraphQL vs REST

The common opinion is that GraphQL is a replacement for REST. Nothing more incorrect. Although GraphQL is a newer concept, it’s totally different from REST. GraphQL definitely isn't a nail in the REST coffin, nor is it better than it. GraphQL definitely can help you optimize your project.

Imagine having one GraphQL API acting as a gateway to your other REST APIs. How cool is that?

## GraphQL Example

In GraphQL structure of the data is not hardcoded as in traditional REST API, which this makes retrieving data from the server more efficient and a lot easier for the client. In general, GraphQL is about asking for specific fields on objects:

```ts
{
    product {
        name
        flav {
            name
        }
    }
}
```

and the respone would like like this:

```ts
{
    "data": {
        "product": {
        "name": "Cola",
        "flav": [
            {
            "name": "Cinamon"
            },
            {
            "name": "Cherry"
            },
            {
            "name": "Vanilla"
             }
          ]
        }
    }
}
```

Getting Started with GraphQL

The recent rise of GraphQL popularity created an ecosystem of different supplementary tools having one idea in common - making GraphQL easier to adopt for more and more developers by bridging the implementation gap which is still a big issue.

If you have heard about GraphQL but still haven't decided to undergone the REST API to GraphQL transformation this tools will make a decision a lot easier.

### [Hygraph (formerly GraphCMS)](https://hygraph.com/)

A tool which allows you to define your GraphQL API. Create structures, relations, powerful permissions and manage your content at ease. So, in general, you can build a hosted GraphQL backed for your web project along with tooling to manage its content.

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

### Tipe

Tipe allows you to build your apps without managing the content. Just create a GraphQL schema file and Tipe will generate your API, content model and the editor UI. Thanks to Tipe you can prototype locally.

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

### [GraphQL Docs](https://github.com/2fd/graphdoc)

GraphQL Docs will generate simple static documentation for your GraphQL schema in couple seconds giving you an option to keep your API documentation private or make it publicly available.

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

### [[GraphiQL](/graphql-playground)](https://github.com/graphql/graphiql)

An easy to implement  React-based IDE tool for testing and documenting GraphQL APIs. [GraphiQL](/graphql-playground) provides a graphic interface for your GraphQL API that takes performing queries and mutations to a new level.

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

### Apollo Launchpad

A tool take makes GraphQL code very accessible. Apollo Launchpad makes it possible to write a GraphQL schema example in JavaScript and create a serverless GraphQL endpoint.

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

The best tools and extensions for GraphQL APIs

This is a part of a series documenting our startup story. Check more on “My-saas-story.”

Last month it was the first month we entirely used OKR method to focus our growth. I am pleased regarding our results and how we communicate between team members. We had finalized our roadmap and posted in on a website. Also, we added consulting tab (hopefully we’ll start earning some money - fingers crossed). At the end of the month, I’ve found about growth teams and theories from Sean Ellis. I’ve introduced the team to work in agile experimenting mode, and they seem to like it!

The upcoming month we’ll focus on testing new ideas for growth like viral sharing, launching first paid features (backend faker front end queries) and many other small updates ;]

## Development:

We've developed frontend queries to enable fronted users autocomplete query in typescript and receive typesafe response. On backend side we deployed project API and faker Service which soon will be available to all of you. Stay Tuned!

## Blog posts of the month (views)

[/GraphQL-newbie-tutorial-Schema-Definition-SDL/](https://graphqleditor.com/blog/GraphQL-newbie-tutorial-Schema-Definition-SDL/) 1,282
[/levensthein-algorithm-for-better-faker-experience/](https://graphqleditor.com/blog/levensthein-algorithm-for-better-faker-experience/) 404
[/Marketing-automation-From-800k-to-130m-impressions-in-3-months](https://graphqleditor.com/blog/Marketing-automation-From-800k-to-130m-impressions-in-3-months/)/ 307
[](https://graphqleditor.com/blog/power-of-typeof-and-typestyle-in-react-apps/)[/power-of-typeof-and-typestyle-in-react-apps/](https://graphqleditor.com/blog/power-of-typeof-and-typestyle-in-react-apps/) 253
[/graphsourcing-new-way-to-build-systems/](https://graphqleditor.com/blog/graphsourcing-new-way-to-build-systems/) 228

## OKR’s update

OKR’s seems to be a good foundation for the small team to maintain focus. This month we added a minor tweak to precise few positions and to measure many experiments.

|                             | **oct** | **nov** |
| --------------------------- | ------- | ------- |
| github faker stars          | 19      | 24      |
| github diagram stars        | 54      | 219     |
| github graphql-editor stars | 2550    | 2675    |
| blog views (users)          | 1500    | 4153    |
| website views (users)       | 1000    | 2131    |
| blog articles               | 8       | 16      |
| mailchimp subscriptions     | 16      | 147     |
| demo runs (users)           | 0       | 781     |
| outreach to developers      | 700     | 2700    |
| slack users                 | 10      | 14      |
| quality calls/conversations | 10      | 15      |
| experiments                 | -       | -       |



My saas story nov18 growth team foundation

Hello, this is starting the article for advanced typescript tutorial series. Today I'll cover basic usage of:

```ts
infer
```

For me, it was hard to understand at the beginning what I can really do with `infer`. Let's start with a really basic example.

```ts
type FlattenIfArray<T> = T extends (infer R)[] ? R : T
```

So let's analyze this code:

1. We check if our generic Type is the array
2. If it is array extract the real type from it
3. If it does not leave it as is

Still, it is not clear what infer is doing, so let's proceed with another example

```ts
type Unpromisify<T> = T extends Promise<infer R> ? R : T
```

This one looks more clear as it doesn't have parenthesis:

1. We check if type extends Promise
2. If it does we extract the type from the promise
3. If it does not leave it as is

See? If you use extends only just to check if the type is a promise you would use

```ts
type Unpromisify<T> = T extends Promise<any> ? T : never
```

And in infer instead of any keyword, you infer the value from type. Let's try with more advanced types then:

```ts
type FuncWithOneObjectArgument<P extends { [x: string]: any }, R> = (
  props: P
) => R;

type DestructuredArgsOfFunction<
  F extends FuncWithOneObjectArgument<any, any>
> = F extends FuncWithOneObjectArgument<infer P, any> ? P : never;

const myFunction = (props: { x: number; y: number }): string => {
  return "OK";
};

const props: DestructuredArgsOfFunction<typeof myFunction> = {
  x: 1,
  y: 2
};
```

Intellisense for props works like this:
![intellisense.webp](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/intellisense.webp)

You can make use of it inferring React Component props for example or another function that uses destructured params.