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.
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.
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?
Top comments (30)
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?
Maybe Rest can't rise su much VC. π€
VC what is that?
VC = Venture Capital
(γ»oγ») (ββΠβ)β彑β»ββ»
Some of the mains benefits are:
The GitHub Graph API is a great example of these two benefits. I strongly recommend reading their announcement post.
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
I think this is the official answer to that.
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
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.
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.
And what doesn't fits?
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.
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.
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
I'm using it for a project where I track land/mineral ownership leasing. It's great for complex relationships like that.
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
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?
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?
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.
This is a really helpful answer, thank you.
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)
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.
I think it does mean that the contracts are no so strict and have a dynamic part. Is it?
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
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.
I don't know one.
Apollo is list of tool to be implementd in the server-side and client-side
This article explains very well the why and and when of graphql: dev.to/sadarshannaiynar/graphql-or...