What is GraphQL? GraphQL is described as ‘a query language for your API’. It was created by Facebook back in 2012 for use in their mobile applications, but was made open source in 2015 and has grown in popularity ever since. GraphQL is an alternative to REST architecture and allows users to specify the data they would like to receive, rather than a REST endpoint simply returning everything. An endpoint returning unnecessary data is known as ‘overfetching’ and results in requests which are larger than they need to be, the frontend needing to parse data it won’t use, and potentially a client having to perform multiple network requests until it has all the information it needs. For example, compare these two queries: REST Query GET /users/1
{
  name: ,
  email: // ...more user information
} "John Doe" "john@test.com" Now if we also wanted to retrieve the comments of this user, we may need to perform query before we can get all the information we need. Something like: another GET /users/1/comments
{
    {
        title: body: },
    {
        title: body: }
  // ...more user comments
} "I really don't like too many requests" "REST is great but sometimes makes me have to fetch a lot of data" "I wonder if there's another way of doing this?" "Surely this is a problem people have encountered before?" GraphQL Query In GraphQL, things are much simpler. We can just do: query {
  User(id: ) {
    name
    email
    comments {
      title
      body
    }
  }
} "1" The above would return a single object containing all the information in just one request. It’s far more efficient and we don’t have to receive all the fields that we would otherwise need to discard had we queried a REST endpoint. Conversely, we don’t either. This is when an endpoint doesn’t give us enough information so we have to make additional requests to get hold of everything that we need. For example, we may retrieve a list of 100,000 users but then need to separately request their comments. underfetch n This would be an expensive operation (and probably bad design regardless of whether you’re using REST or GraphQL). GraphQL is a specification Many people imagine GraphQL to be like an ORM or a replacement database. This is not the case. It’s merely a specification that can be implemented in any language and describes a way to relate to your data. The spec is easy to read and can be checked out . here Pros of using GraphQL No Overfetching As described above, the client does not receive data that it won’t use. Instead we simply request what we need and GraphQL returns the appropriate data. This means that we have smaller payloads, more efficient use of resources, and more flexibility on the frontend. Modern This matters more to some people than others, but it’s undeniable that GraphQL is on the ‘cooler’ end of the developer spectrum. It is an interesting technology that has a lot of potential. In the survey, GraphQL won the ‘Highest Interest’ category with a staggering of developers who have heard about GraphQL wanting to learn it! State of Javascript 2018 87.7% Strongly Typed GraphQL uses a strong type system which maps the API. Everything exposed in the API is contained in the GraphQL schema using a schema definition language. Once the schema is created, there is a single souce of truth for both the backend and the frontend and no need for translation between the two. This allows for fewer errors, validation at compile-time, and you can be certain of what you are passing to the API and receiving from it. Flexible By allowing the client to dictate the data it requires, your frontend can move a lot faster without tying up a great deal of backend resources. This is significantly better than a 1:1 matching of endpoint to request where the frontend needs to normalize a great deal of data in order to present the correct values to the end user. Cons of GraphQL It’s New This isn’t necessarily a bad thing, but the ecosystem is - while growing - less mature than what is available should you choose to go with a standard REST setup. For many companies choosing the ‘boring’ option makes far more sense. There’s nothing wrong with that! For others, then GraphQL is an exciting new way to do things. Complex Queries This is something of a ‘solved’ problem in GraphQL but it can trip people up. For example, what happens if a user (perhaps maliciously) makes a request like this: query {
  User(id: ) {
    name
    email
    about city
    zip
    country
    comments {
      title
      body
    }
    pictures {
      url
      order
    }
    likes {
      website {
        title
        url
      }
    }
  }
} "1" address This is a bit of a trivial example, but you get the idea. A query can rapidly bloat and consume a lot of server resources. In a REST API you could potentially tweak each endpoint to retrieve its specific data in the most specific way. In GraphQL you can use tools like to handle your requests via batching and caching to reduce the load on your server. DataLoader Additionally you can limit the complexity of queries through Query Cost Analysis. There are a few packages which make this easier such as which computes the cost of the query and optionally blocks it if over a certain threshold. GraphQL-Cost-Analysis Learning Curve As GraphQL is quite new, it may take you time to get up to speed with it and figure out if its a good fit for you. Also, there are a few ‘gotchas’ that you may be unfamiliar with compared to REST. There are many resources covering these however. My experience with GraphQL At we’re using GraphQL to power our new API and my experience has been largely very positive. Although it presented a bit of a learning curve, it has allowed for very rapid development and a much quicker integration between the backend and the frontend. BeatGig It’s not a silver bullet but when it comes to needing a very flexible way to query and subscribe to our data, it works well for us. There were some initial pains in the setup and understanding exactly how to map our existing functionality to GraphQL but this has gone fairly smoothly so far. Something that has benefitted us hugely however, is using , and which gives us a lot of the CRUD features out of the box, and has pre-configured an express server with Apollo in the case of GraphQL-Yoga. GraphQL-Yoga Prisma This allowed us to get up and running very quickly and development has been a very enjoyable experience since! Conclusion GraphQL isn’t going to be for everyone, but it’s a very interesting technology that reduces some of the frustrations you may feel (particularly on the frontend) when you’re using REST endpoints. It has an intial learning curve but allows for rapid development and flexible access to your underlying data. The ecosystem is growing very quickly and a large number of developers are interested in learning it, so that ecosystem should continue to grow. Overall it’s a useful tool in any developer’s arsenal and definitely worth trying out!

Facebook

Fetch

My Experience with GraphQL

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Big O for Beginners

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

Big O for Beginners

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps