Then it would certainly have more to do with specific implementations, not GQL over all REST implementations.
REST is after all, just a set of concepts. I'd a well designed RESTful service is faster than 90% of all GQL APIs.
If you put a well designed GraphQL API against a well designed REST API:
They probably tie overall. Sometimes they would be equal, sometimes each one would be faster.
Ideally, if I was debating between a new application and needed to decide between a webAPI and REST, vs GraphQL I'd consider:
Industry Support
Readability
Maintainability
Performance
RESTful APIs win 3/4 of those IMO. If performance became my only concern, I'd grab a demo database and do some hard testing. If GraphSQL won, but within a margin of error: I'd still pick REST because of it's other strengths.
I mean, I've recommend changes on tech stacks because of performance before.
EF 6 to EF 7: reduced queries by 50%.
EF 7 to Dapper: 75% reduction.
Those are huge performance gains. If GraphQL could do that for a given design, I'd be on it.
In fact, I am a little curious what I could do with it. But I suspect I can keep a RESTful service, using Dapper (I am a fullstack .NET guy) more performant than a graphql API...
Faster how? And faster than what exactly?
Faster than REST through EF 4? Maybe, possibly, even probably.
Faster than REST using Dapper or EF 6/7? Likely not. Assuming similar scope and queries.
I would be interested to see how some problems are solved in GraphQL, vs more traditional solutions.
Most of my original comment was also towards Ivan, and agreeing with his comment.
When I say faster I mean
data fetchingandlow bandwidthThen it would certainly have more to do with specific implementations, not GQL over all REST implementations.
REST is after all, just a set of concepts. I'd a well designed RESTful service is faster than 90% of all GQL APIs.
If you put a well designed GraphQL API against a well designed REST API:
They probably tie overall. Sometimes they would be equal, sometimes each one would be faster.
Ideally, if I was debating between a new application and needed to decide between a webAPI and REST, vs GraphQL I'd consider:
Industry Support
Readability
Maintainability
Performance
RESTful APIs win 3/4 of those IMO. If performance became my only concern, I'd grab a demo database and do some hard testing. If GraphSQL won, but within a margin of error: I'd still pick REST because of it's other strengths.
I mean, I've recommend changes on tech stacks because of performance before.
EF 6 to EF 7: reduced queries by 50%.
EF 7 to Dapper: 75% reduction.
Those are huge performance gains. If GraphQL could do that for a given design, I'd be on it.
In fact, I am a little curious what I could do with it. But I suspect I can keep a RESTful service, using Dapper (I am a fullstack .NET guy) more performant than a graphql API...
It always depend on the kind of project you're building. But still at the end of the day you find both REST and GraphQL to be good.