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...
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...
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.