DEV Community

Cover image for Is GraphQL the future of APIs?
Tomek Poniatowicz for GraphQL Editor

Posted on • Updated on • Originally published at blog.graphqleditor.com

Is GraphQL the future of APIs?

Developing APIs has always been a crucial task for any project. A well-designed API must be flexible and scalable as it always evolves with time. The urge for improvements led to the explosive growth of the data graphs popularity in the last years. This is great news for GraphQL as a lot of companies have started adopting it in their projects. To not be groundless:

  • Audi's e-tron car with a data graph
  • The front page of NY Times is based on a data graph
  • Airbnb uses data graph across all their apps both web & mobile

... the list goes on and on.

The benefits of data graph

Graphs are everywhere! So what are the main benefits of the data graph structure? First of all, it provides easier access to the date, by better, more clear structure.

Graphs are everywhere

This leads to another huge benefit of using data graphs which is a better data understanding which effect in faster project onboarding and more efficient collaborations overall as we can clearly see a cause-effect relation. It's worth mentioning that graph structures are a lot easier to visualize, especially with modern tooling available on the data graph/GraphQL market like GraphQL Birdseye or GraphQL Editor.

GraphQL schema visualized with GraphQL Editor

The benefits don’t stop there and go further beyond to faster development, higher code automation, more consistent user experiences across multiple apps and a lot more.

A bright future

There is no doubt that people in Apollo, the most popular GraphQL implementation, fully understand the benefits of the data graph structure. Fortunately, more and more people start to see qualities offered by data graphs. Recently, the big news has seen the daylight, the information that "Apollo raised $22 million", this shows that also VCs' noticed a business opportunity in GraphQL technology which gives more confidence that GraphQL might be the future of APIs. What do you think?

Apollo raised $22 milion

Top comments (30)

Collapse
 
mandaputtra profile image
Manda Putra

I think you should add why and when to use GraphQL. Tools created to solve problem right? Why should I use it when I'm not encounter the same problem like that big company? I'm not Facebook, nor NY Times, maybe sometimes I am, but when?

What REST API cant do and graphQL can? with example?

Collapse
 
yucer profile image
yucer

Maybe Rest can't rise su much VC. 🤔

Collapse
 
mandaputtra profile image
Manda Putra

VC what is that?

Thread Thread
 
pramanadiputra profile image
Ida Bagus Gede Pramana Adi Putra

VC = Venture Capital

Thread Thread
 
mandaputtra profile image
Manda Putra

(・o・) (┛◉Д◉)┛彡┻━┻

Collapse
 
byrro profile image
Renato Byrro

Some of the mains benefits are:

  • reducing the number of times you need to hit an API endpoint
  • ability to request only the data you need

The GitHub Graph API is a great example of these two benefits. I strongly recommend reading their announcement post.

Collapse
 
bolt04 profile image
David Pereira

I think a RESTful API can also reduce the number of API calls in some scenarios. It's not just GraphQL that enables that imo

Collapse
 
yucer profile image
yucer

I think this is the official answer to that.

Collapse
 
mandaputtra profile image
Manda Putra • Edited

Yeah it is, but I dont know when to use GraphQL I still dont know why should I add it, I tried once though. But that not a big webapps simple one company profile.

So I really dont know why should I use it. Maybe in big apps thats make difference

Thread Thread
 
yucer profile image
yucer

I guess when the entities evolve quickly and are interrelated.

Few isolated entities might work better with rest.

I guess it might be also better when you integrate data from different services.

Collapse
 
dorshinar profile image
Dor Shinar

I've been working on GraphQL based interfaces for the past 6 months or so, and I think it has a lot of potential. It is not a one-size-fits-all solution, but there is a lot of room to evolve and I think GraphQL is a step in the right direction.

Collapse
 
yucer profile image
yucer

And what doesn't fits?

Collapse
 
dorshinar profile image
Dor Shinar

I find the biggest down side to GraphQL to be the cachability of it. REST is much more developed in this area. GraphQL is still rather new so you don't have mature platform do much as with REST.

Collapse
 
muddybootscode profile image
Michael Porter

If you’re also using a graph DB like Neo4j there’s a lot more functionality you can get into as well. The GRANDstack.io is a very easy frame work to get started with it.

Collapse
 
rickssss profile image
Rick

Great! I actually studied graph theory pretty heavily during my math degree but haven't found a practical use for Neo4j for a personal project. this may change that

Collapse
 
muddybootscode profile image
Michael Porter

I'm using it for a project where I track land/mineral ownership leasing. It's great for complex relationships like that.

Collapse
 
marek_mosiewicz profile image
Marek Mosiewicz

What is forgotten, that graph representation on client can be achieved with many queries. Maintaining consistent view of data on client is achieved by ORMs in case of RDBMS. Same thing would be necessary for graph databases

Collapse
 
gypsydave5 profile image
David Wickes

Interesting. I'd like to see somethibg of a like for like comparison - can GraphQL map to HTTP methods like POST and DELETE? Can we transition application state with HATEOAS in GraphQL?

Can GraphQL work under REST, complementing it? Could all the GET requests be fed through the GraphQL API? Are the two mutually exclusive?

Collapse
 
katylava profile image
katy lavallee

I get using GraphQL for GETs. But what are its advantages over REST for POST/PUT/DELETE? Is it appropriate to use both in one API?

Collapse
 
shadowimmage profile image
Chase Sawyer

GraphQL can be as complex or simple as you design it to be. The benefit is when you start getting into a situation where you have a very complex data model, say 20+ related tables. In this case, if you want to load and then modify a bunch of interrelated tables all in one network round-trip, a mutation can do that. And the return data can include all the potentially derivative changed data, IDs, etc. in the returned query which nicely keeps the client cache up to date.

Now, if I only had one or three tables or a NoSQL data back end, a REST API might be faster / simpler to implement.

Collapse
 
katylava profile image
katy lavallee

This is a really helpful answer, thank you.

Collapse
 
negue profile image
negue

POST / PUT / DELETE actions are handled by mutations in GraphQL

there you can also (if you want) only pick your needed result values like:

"add a message, but only return the created ID" (or anything else you need)

Collapse
 
katylava profile image
katy lavallee • Edited

Yeah but they just seem way more complex with GraphQL. I would prefer doing "mutations" the RESTful way if I don't need that feature of only returning part of the response. But still keep GraphQL for the GET endpoint.

Thread Thread
 
yucer profile image
yucer

I think it does mean that the contracts are no so strict and have a dynamic part. Is it?

Collapse
 
audacioustux profile image
Audacious Tux

the one major problem I see with graphql is its complexity. yah you can use libraries like apollo to abstract away those but tooling, rate limiting, role-based routing with graphql is still not quite convincing. in a microservice architecture, graphql might become a bottleneck in performance-wise. only apollo (js) supports federation, and it's not in graphql spec. so authors of graphql libs in other languages not much interested to implement it.
There's so many protocols with different wire format like protobuf, flatbuf, capnproto, avro, json, xml... so many language... so many infra tools like istio, nginx, etc...
graphql isn't flexible enough, and unfortunately, there's no other better solution yet. openapi can't solve all the problems with REST. but if someday anything new comes, switching from REST might be easier than graphql

Collapse
 
mehdiraash profile image
Mehdi Raash

I'm not sure about the goal of this article, If it was about Graph in computer world, Neo4j would be a better example for that( completely implemented for graph use not mimicking it like other tools)! but somehow this article's about GraphQL comparing with REST. quite irrelevant.

 
yucer profile image
yucer

I don't know one.

Thread Thread
 
rebaiahmed profile image
Ahmed Rebai

Apollo is list of tool to be implementd in the server-side and client-side

Collapse
 
napicella profile image
Nicola Apicella

This article explains very well the why and and when of graphql: dev.to/sadarshannaiynar/graphql-or...