GraphQL better than the REST? It's time for a replacement

Aug 14, 2020

|

development

How did GraphQL let us overtake the REST

Iteo

Marcin Janiak

.NET developer

Would you like to ascend your development process to the next level? Is GraphQL another buzzword or will it replace REST like REST replaced SOAP?

What GraphQL is.

The most important thing to mention is that GraphQL is not another framework! It’s a query language and execution engine created in 2012 by Facebook. GraphQL’s specification (in short: description of behaviors, data format, etc.) became an open standard in 2015.

One can even boldly say that this is the way we think of creating applications.

Making it simple, a typical GraphQL API consists of the following components:

  • Schema – core, it describes types and capabilities of API
  • Query – root type for queries (data fetching)
  • Mutation – root type for mutations (modifying data)

We are constantly using GraphQL on both client and server sides.

For .NET projects, we use HotChocolate (https://hotchocolate.io/) framework with all .NET features cooperating greatly with the GraphQL.

For node and frontend projects – we get well along with Apollo (https://apollographql.com/).

You may also be interested in:
GraphQL on Android with Apollo Client
Is mobile development ready for graphQL
Why you should consider .NET Core for your next project

Top reasons to use it in your next project

Strongly typed schema

For me, a long-time C# veteran, the coolest thing is a type system. It’s a lot less error-prone compared to the classic REST approach, and fewer bugs means less time spent on fixing them.

API straightforwardly defines allowed operations and data models.

The type system allows us to generate some parts of code, letting the development team focus on your specific problems (not infrastructure ones), and further increase development speed.

What you query for is what you get

Let’s assume that we are creating another blogging application. Imagine that we have a page which displays multiple blog entries and the respective author’s name.

In classic REST API we would have some set of endpoints, e.g.:

GET posts

GET author?{id}

Frontend will request for a list of posts and for each post’s author respectively.

In this case, the so-called underfetching occurred. It means that one endpoint cannot supply us with the required amount of data and it leads to performing additional, unnecessary requests (in our case – querying for author’s name).

However, at the same time, the so-called overfetching occurred because we have transferred all the author’s data, including those currently redundant (the author may have such things as a photo, description, etc.)

graph-ql-why-use-it

What could a similar graphql query look like?

  query GetPostsWithAuthorNames {
    posts {
      title
      content
      author {
        name
      }
    }
  }

We are explicitly declaring what we want to receive from API.

graph ql authors name

Better overall performance

Performing one round trip to a server, in most scenarios, is much more performant than doing multiple requests. Not to mention that less data is transferred over the network. 

In REST api you could have something like user/basicdata and user/details to preserve some transfer but due to REST API nature – it leads to code bloating.

Hosting GraphQL API in the cloud might be cheaper than its REST equivalent!

Versioning

In REST APIs versioning is based on duplicating the code and endpoints (v1/users, v2/users etc.).

GraphQL API is backward compatible. You can freely expand it as you wish because API consumers can query what they would like to get.

It requires a lot less effort to evolve your GraphQL API which basically means a faster development process.

And after some time, you can freely drop the deprecated field.

Documentation

Thanks to the strongly typed schema, we are able to generate documentations with “one click”.

Existence of tools like GraphiQL or GraphQL Playground grants us a possibility to write queries with autocomplete help, view schema, and docs.

On the other hand, GraphQL Voyager generates a beautiful schema visualization/map.

Simpler and more beautiful code

Code, on both server and client-side, is much more brief and simple which in consequence means it’s easier to maintain and modify. Simple code is also a morale booster for the development team.

…And there are no endpoints so frontend and backend devs aren’t fighting for API structure (that much). 

Flexibility

Still, remember the blog posts with the author’s name example? What if we would additionally display the author’s description and his few top-rated posts?

In GraphQL, we might be able to do this without touching a server-side, while in classic REST approach it would probably end with expanding one endpoint (which might be inappropriate) or adding another one.

Making changes is just easier and faster.

Let’s assume we would like to rebuild the whole app layout. Due to the flexibility of GraphQL and it’s queries – probably we might be able to avoid complex works on the server-side.

This basically means that frontend work can start right away!

Rapid MVP development

Taking into account the flexible nature of GraphQL, it fits well with rapid MVPs development, where many requirements may change during the work.

Microservices…

This is where GraphQL shines brightly! Thanks to so-called schema stitching (or Apollo Federation for node implementation) – we are able to simplify communication with server-side applications by joining services into one.

This basically means that the frontend apps are querying data from one API.

Schema stitching allows us to stitch a legacy API and hide it behind GraphQL schema too!

If you’re curious about other insights from our team of developers, check the Development section in our blog.