Mohamad Ashraful Islam

Posted on Jul 8, 2019

Introduction to GraphQL

#beginners #graphql #api #webdev

What is GraphQL?

GraphQL is a query language for API. It fulfils the client's need on runtime. It gives the client power to decide the API data format, dataset.

History behind the awesome GraphQL

The awesome GraphQL was invented by Facebook in 2012. At that time Facebook internally used it. Later on, 2015 Facebook decided to make it open source. Now it's maintaining by GraphQL community.

Props

* Single endpoint API service

GraphQL is capable of serving huge data in single endpoint. For example, you need a list of all users and all products of the system. In REST you need atleast two endpoint to achieve this. But in GraphQL it just in one API.
A basic GraphQL query example:

query getCustomData {
  getUsers {
    name
    username
  }
  getProducts {
    name
  }
}

* Control data fetching

From the last example you already aware about data query. In GraphQL we can let server know what I really needed.
Let's modify the query

query getCustomData {
  getUsers {
    name
    username
    email
    ... anything you have
  }
}

* Modern Design

GraphQL has very much modern design of API making. It helps development easy and less maintaining for different different client software. For example, You have a desktop client, a mobile client and a web client obviously for a product name "x". Mobile app doesn't need all the data that your web client and desktop client needed. In that case, either you needed to expose different API each client or serialize all the fields. Then, you one of the client will fetch extra/unnecessary data. Now think about very slow network. I hope you understand the pain of slow loading. So, the primary and smart solution is writing GraphQL API.

Cons

* No built-in caching support

Unfortunately or fortunately GraphQL doesn't have caching support. As REST api have multiple endpoints. So, traditional http call caching works well. Unlike REST it has single endpoint to fetch data. Data depends on query. So, there is no way to cache from http request.

* No specific error code

This is not a big issue. We can backdoor the problem. Unlike REST it doesn't have different error codes. It always returns 200. The way to indentify an error is the key errors in response data.

Conclusion: My personal opinion GraphQL is awesome, smart and modern. But don't use it unless you need it.

Top comments (14)

Matt Erman • Jul 8 '19 • Edited

Cons: you have to write complex resolvers to "tell" it what to return even when you are writing a basic query and it should already know what you want back. Why would I want to write a query and then have to tell the database what to send me back?? It would be like if I went to a restaurant and ordered food and then had to tell the chef how to make it. How is this even remotely acceptable??

Cons: Does not support Aggregates in many cases. Want to use COUNT, MIN, MAX? Sorry you are SOL...

Cons: You will spend hours trying to figure out how to get the data back you need when you could have gotten it back in 5 seconds by writing a SQL query you already know.

Pros: connect your graphQL DB to Rockset and run native SQL Queries on it at lightning speed. No i don't work for Rockset but i use it a lot with Dynamo DB.

Miles • Jul 9 '19

I highly recommend trying out Postgraphile, especially if you are already familiar with RDBMSs and SQL.

graphile.org/postgraphile/

Aggregates and pagination also included out of the box with no configuration. If you've defined your data model, you've got your graph. Smart comments allow renaming and omitting certain tables and columns as well.

Performance with it is not an issue. Quite the contrary.

I do not contribute to the project, but I'm a big fan.

Laurin Quast • Jul 9 '19 • Edited

The intension of GraphQL is not exposing a full-featured query language like SQL, but instead exposing an object graph that is easily understandable and serves as a contract between frontend and backend developers. Ideally that graph is modeled with the frontend in mind, which means the queries are one to one mappable to your UI components and not a representation of your database relationship model.

IMHO it would be a huge security/performance concern by exposing an SQL like API to the public. Malicious and really unperformant queries could be sent.

You can also have aggregated values, you will just execute the right SQL queries in your resolvers.

Mohamad Ashraful Islam • Jul 9 '19

Thanks for such a nice explanation. I am trying to learn graphql and share the basics for beginners.

Laurin Quast • Jul 9 '19 • Edited

Instead of using the errors array of your response you can also model your schema to represent expected errors. That way you will know which error you need to handle while also having full type safety.

One great approach for achieving that is by using unions:

type User {
  id: ID!
  name: String!
}

type NotFoundError {
  reason: String!
}

union UserResult = User | NotFoundError

type Query {
  user(id: ID!): UserResult!
}

Sample Query:

query {
  user(id: "1") {
   type: __typename
    ... on User {
      id
      name
    }
    ... on NotFoundError {
      reason
    }
  }
}

@sachee did a great talk about this: youtube.com/watch?v=GYBhHUGR1ZY

Mohamad Ashraful Islam • Jul 9 '19

Thank u so much for nice explanation

Hugo • Jul 9 '19

We were thinking about using GraphQL, GraphQL-yoga, and Prisma.

I'll give you a little context. It is a system to deliver medicine. Currently, the system consists of a mobile app for distributors made in react-native, an API in laravel and a dashboard to track orders, generate reports and some other stuff.

We use AWS S3, FTP, and an endpoint to receive orders. We also use WebSockets to have synchronized information between the mobile app and the dashboard. The reasons why we consider graphQL is that we currently have overfetching in the application and because graphql offers a solution through subscriptions for the parts of the system that need real-time updates.

Laurin Quast • Jul 9 '19

Regarding the Memory Leak: Have you tried building a minimal reproduction repository and filed in a bug report? I am sure that the apollo team and other contributors would appreciate that.

I also agree that modeling good GraphQL APIs is an art form, however basic things like only mutations should create/change stuff can be vague. What if you want to increase a counter each time an user visits a site that fires a certain query? We can either increase the counter as part of the query execution or as a separate mutation aka an additional request.

Furthermore, in my 3 years of working with react-apollo, I have not experienced the not update the data or pass malformed information into the component errors yet. As with the SSR issue it could be valuable if you can submit a minimal reproduction repository to the apollo team!

While there might be some issues with apollo-client, we should also keep in mind they started making GraphQL easily usable. When they started the only react client with a comparable feature set was relay classic. Today we have a wider variety and I encourage you to try Relay Modern or URQL. I personally really like the features of Relay Modern. However, for now I will stick with apollo.

Hugo • Jul 9 '19

How difficult is it to start with GraphQL? We are about to start a redesign of a project that is currently in laravel and Vue to GraphQL and React + Apollo, the main problem is that nobody from the team has experience working with GraphQL and I was wondering how much that can affect